[JOSS] Install instructions

Issue #8 resolved
Andrea Zonca created an issue

Part of the JOSS review https://github.com/openjournals/joss-reviews/issues/1889

The installation instructions do not specify which version of HEALPix is required,
I am testing on Ubuntu 16.04 with healpix packages from the repository:

ii  libchealpix-dev             3.11.4-2build1     amd64              HEALPix representation of spherical data - C development li
ii  libchealpix0                3.11.4-2build1     amd64              HEALPix representation of spherical data - C shared library
ii  libhealpix-cxx-dev          3.11.2-7.1ubuntu1  amd64              representation of spherical data - C++ development library

is this version too old? should I install 3.50?

Comments (16)

  1. Gioacchino Wang

    Thanks, I’ll specify that we’re using 3.50, as you know the 3.50 replaced fftfast by pocketfft. I’ll modify the instruction now.

  2. Andrea Zonca reporter

    ok, I got it to compile with healpix 3.50.

    Is there a test configuration file I can use to test the code?
    Also, probably something went wrong in the compilation, I get core dumps:

    > hamx
    terminate called after throwing an instance of 'std::logic_error'
      what():  basic_string::_M_construct null not valid
    Aborted (core dumped)
    
    > hamx --help
    key: grid
    Segmentation fault (core dumped)
    

    Also, for the python bindings can you make a simple python package, so that it is installable?
    You could use either https://github.com/takluyver/flit (easy and quick) or https://github.com/astropy/package-template (a lot more complete)

    ldd $(which hamx)
            linux-vdso.so.1 =>  (0x00007ffca08f6000)
            libhammurabi.so => /home/zonca/p/software/hamx/hammurabi/lib/libhammurabi.so (0x00007fd29e89d000)
            libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3 (0x00007fd29e49f000)
            libfftw3_omp.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3_omp.so.3 (0x00007fd29e298000)
            libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd29df16000)
            libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd29dd00000)
            libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd29d936000)
            libcfitsio.so.2 => /usr/lib/x86_64-linux-gnu/libcfitsio.so.2 (0x00007fd29d56c000)
            libgsl.so.19 => /usr/lib/x86_64-linux-gnu/libgsl.so.19 (0x00007fd29d12d000)
            libgslcblas.so.0 => /usr/lib/x86_64-linux-gnu/libgslcblas.so.0 (0x00007fd29ceef000)
            libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd29cbe6000)
            libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fd29c9c4000)
            libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd29c7a7000)
            /lib64/ld-linux-x86-64.so.2 (0x00007fd29eb3e000)
            libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd29c58d000)
            libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd29c389000)
    

  3. Gioacchino Wang

    Thanks for the message and suggestions.

    For running the executable you need an XML parameter file, please check the templates directory, I’ll try to make a tab complete for the executable, and update the running instruction too.

    I can try to make an installable package, currently, the python wrapper creates a subprocess for executing the c++ executable, is this ok for packing it up?

  4. Gioacchino Wang

    I’ve just updated the execution instruction, now you can use “run.sh” for details, and I’ve also updated the wiki install page accordingly

  5. Andrea Zonca reporter

    ok, it works using run.sh however I think hamx should not core-dump if called with no arguments. Can you implement what you did in run.sh directly into the hamx executable?

    For packing it up, the right way of doing that would be with pybind11 or cython, but if the main interface to hamx is through the hamx executable and not much via Python, then it is ok to call subprocess. But I see the tutorials all use Python…

  6. Gioacchino Wang

    I’ve merged the run.sh into the executable.

    Yep, we thought about wrapping the c library directly in python rather than invoking the executable, the biggest advantage for doing this would be passing healpix maps directly from c to python, instead of writing and reading through the disk which is slow.

    The multi-threading routine is mainly carried out in c routine rather than in python, the python wrapper is implemented since we have another (not in this repo) Bayesian analyzing engine in python that wants to use hammurabi X as its observable simulator.

    The reason we call subprocess is that we do not know how to connect healpy array with healpix array, do you have any suggestions for this?

  7. Gioacchino Wang

    I thought about (and messed up a bit) with cython/ctypes etc., and realize that the IO of hammurabi X requires programming the main routine in python instead of link it from C. The obstacle is that we have an unfixed number of output maps before reading the parameter file setting.

    But anyway, I can now provide a very simple installation for the python wrapper without a decent interface to the C library.

    I would like to do it with SWIG, which looks feasible and nice as done in CRpropa3, but the deadline for sending back the AAS revision is before next Feb., I don’t think I could make it in a month myself.

    Let me know if the current status of the installation is acceptable, the current update has been pushed into the “fix” branch.

  8. Andrea Zonca reporter

    as “current status” do you mean the master or the fix branch?

    If you plan to merge the fix branch, please make a pull request, I can do a quick review.

  9. Andrea Zonca reporter

    can you also update the installation instructions on the wiki to say we can python setup.py install the package?

  10. Log in to comment