Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
technical:recipes:mcfost [2023-03-03 11:33] – created frey | technical:recipes:mcfost [2023-03-24 23:03] (current) – frey | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Building MCFOST on Caviness ====== | ||
+ | Two distinct use cases are described in this document. | ||
+ | |||
+ | The second integrates the MCFOST program into a Python virtual environment (virtualenv). | ||
+ | |||
+ | The following recipes reflect a user's building and managing MCFOST in their home directory. | ||
+ | |||
+ | ===== Stand-alone ===== | ||
+ | |||
+ | The recipe begins by setting-up a directory to contain all versions of MCFOST to be built in stand-alone fashion: | ||
+ | |||
+ | <code bash> | ||
+ | $ export MCFOST_PACKAGE=" | ||
+ | $ export MCFOST_PREFIX=" | ||
+ | $ mkdir -p " | ||
+ | $ cd " | ||
+ | </ | ||
+ | |||
+ | To build from the head of the master branch of the MCFOST source, it is easier to version the software by compilation date; the actual release version can be aliased to the date-based version after the fact in the VALET package definition. | ||
+ | |||
+ | <code bash> | ||
+ | $ export MCFOST_VERSION=" | ||
+ | $ mkdir -p " | ||
+ | $ cd " | ||
+ | $ git clone https:// | ||
+ | $ cd src | ||
+ | </ | ||
+ | |||
+ | The next step is to build the program. | ||
+ | |||
+ | ==== Build Procedure ==== | ||
+ | |||
+ | MCFOST has two components to its build: | ||
+ | |||
+ | <file bash SWMGR-build.sh> | ||
+ | #!/bin/bash -l | ||
+ | |||
+ | vpkg_require intel-oneapi/ | ||
+ | |||
+ | export MCFOST_INSTALL=" | ||
+ | export MCFOST_GIT=1 | ||
+ | export MCFOST_AUTO_UPDATE=0 | ||
+ | |||
+ | export SYSTEM=ifort | ||
+ | #export MCFOST_XGBOST=yes | ||
+ | |||
+ | # Start with the library build: | ||
+ | pushd lib | ||
+ | ./ | ||
+ | if [ $? -ne 0 ]; then | ||
+ | exit 1 | ||
+ | fi | ||
+ | # Remove the HDF5 fake install root that install.sh created: | ||
+ | [ -d ~/ | ||
+ | popd | ||
+ | |||
+ | # Move to the executable build: | ||
+ | pushd src | ||
+ | make | ||
+ | if [ $? -ne 0 ]; then | ||
+ | exit 1 | ||
+ | fi | ||
+ | |||
+ | # There is no " | ||
+ | mkdir -p " | ||
+ | cp mcfost " | ||
+ | popd | ||
+ | |||
+ | # Add a symlink to the utils directory to the install prefix, too; | ||
+ | # we'll set MCFOST_UTILS to point to that: | ||
+ | ln -s " | ||
+ | |||
+ | </ | ||
+ | |||
+ | The library dependencies and '' | ||
+ | |||
+ | <code bash> | ||
+ | $ chmod +x SWMGR-build.sh | ||
+ | $ ./ | ||
+ | Adding dependency `binutils/ | ||
+ | Adding package `intel-oneapi/ | ||
+ | ~/ | ||
+ | Building MCFOST libraries with ifort | ||
+ | ~/ | ||
+ | --2023-03-03 10: | ||
+ | Resolving sprng.org (sprng.org)... 204.85.28.65 | ||
+ | Connecting to sprng.org (sprng.org)|204.85.28.65|: | ||
+ | |||
+ | : | ||
+ | | ||
+ | Compiling MCFOST for ifort system........... | ||
+ | |||
+ | ifort -fpp -O3 -no-prec-div -fp-model fast=2 -traceback -axSSE2, | ||
+ | ~/ | ||
+ | </ | ||
+ | |||
+ | If successful (as above), the '' | ||
+ | |||
+ | <code bash> | ||
+ | $ ls -l " | ||
+ | total 42 | ||
+ | drwxr-xr-x | ||
+ | drwxr-xr-x | ||
+ | drwxr-xr-x | ||
+ | drwxr-xr-x 10 frey everyone 15 Mar 3 11:26 src | ||
+ | lrwxrwxrwx | ||
+ | |||
+ | $ ls -l " | ||
+ | total 15003 | ||
+ | -rwxr-xr-x 1 frey everyone 28472712 Mar 3 11:07 mcfost | ||
+ | </ | ||
+ | |||
+ | With this version of MCFOST built, the next step is to setup a VALET package definition to manage it in the user's environment. | ||
+ | |||
+ | ==== VALET Integration ==== | ||
+ | |||
+ | For a user building and managing MCFOST on their own, the VALET package definition file should be placed in '' | ||
+ | |||
+ | <code bash> | ||
+ | $ echo $MCFOST_PREFIX ; echo $MCFOST_VERSION | ||
+ | / | ||
+ | 2023.03.03 | ||
+ | </ | ||
+ | |||
+ | With those values, '' | ||
+ | |||
+ | <file yaml mcfost.vpkg_yaml> | ||
+ | mcfost: | ||
+ | prefix: / | ||
+ | description: | ||
+ | url: " | ||
+ | |||
+ | default-version: | ||
+ | |||
+ | actions: | ||
+ | - variable: MCFOST_INSTALL | ||
+ | value: ${VALET_PATH_PREFIX} | ||
+ | - variable: MCFOST_UTILS | ||
+ | value: ${VALET_PATH_PREFIX}/ | ||
+ | |||
+ | versions: | ||
+ | 2023.03.03: | ||
+ | description: | ||
+ | dependencies: | ||
+ | - intel-oneapi/ | ||
+ | |||
+ | </ | ||
+ | |||
+ | Once created, the syntax can be checked: | ||
+ | |||
+ | <code bash> | ||
+ | [frey@login01.caviness ~]$ vpkg_check ~/ | ||
+ | / | ||
+ | : | ||
+ | </ | ||
+ | |||
+ | When additional versions/ | ||
+ | |||
+ | Finally, the package can be added to the environment and the release version can be determined: | ||
+ | |||
+ | <code bash> | ||
+ | $ vpkg_require mcfost/ | ||
+ | Adding dependency `binutils/ | ||
+ | Adding dependency `intel-oneapi/ | ||
+ | Adding package `mcfost/ | ||
+ | |||
+ | $ mcfost -version | ||
+ | You are running MCFOST 4.0.00 | ||
+ | Git SHA = fe87f0e2c32ffcc897687d1a7a9a90e3ed2f02eb | ||
+ | | ||
+ | with INTEL compiler version 2021 | ||
+ | | ||
+ | | ||
+ | | ||
+ | </ | ||
+ | |||
+ | Ah ha! Version 4.0.00, so let's add an alias to the VALET package definition: | ||
+ | |||
+ | <code yaml> | ||
+ | mcfost: | ||
+ | prefix: / | ||
+ | description: | ||
+ | url: " | ||
+ | |||
+ | default-version: | ||
+ | |||
+ | actions: | ||
+ | - variable: MCFOST_INSTALL | ||
+ | value: ${VALET_PATH_PREFIX} | ||
+ | - variable: MCFOST_UTILS | ||
+ | value: ${VALET_PATH_PREFIX}/ | ||
+ | |||
+ | versions: | ||
+ | 2023.03.03: | ||
+ | description: | ||
+ | dependencies: | ||
+ | - intel-oneapi/ | ||
+ | 4.0.00: | ||
+ | alias-to: 2023.03.03 | ||
+ | |||
+ | </ | ||
+ | |||
+ | Having done that, the versions of MCFOST available are queried by doing: | ||
+ | |||
+ | <code bash> | ||
+ | $ vpkg_versions mcfost | ||
+ | |||
+ | Available versions in package (* = default version): | ||
+ | |||
+ | [/ | ||
+ | mcfost | ||
+ | 4.0.00 | ||
+ | * 2023.03.03 | ||
+ | </ | ||
+ | |||
+ | ==== Using MCFOST ==== | ||
+ | |||
+ | With the build completed and the VALET package definition created, job scripts can now load a version of MCFOST into the runtime environment by doing | ||
+ | |||
+ | <code bash> | ||
+ | : | ||
+ | |||
+ | vpkg_require mcfost/ | ||
+ | |||
+ | : | ||
+ | </ | ||
+ | |||
+ | The program is parallelized with OpenMP, so ''/ | ||
+ | |||
+ | <code bash> | ||
+ | # | ||
+ | # If you have VALET packages to load into the job environment, | ||
+ | # uncomment and edit the following line: | ||
+ | # | ||
+ | vpkg_require mcfost/ | ||
+ | |||
+ | # | ||
+ | # Do standard OpenMP environment setup: | ||
+ | # | ||
+ | . / | ||
+ | |||
+ | # | ||
+ | # [EDIT] Execute MCFOST: | ||
+ | # | ||
+ | MCFOST_ARGS=(-tmp_dir " | ||
+ | if [ -n " | ||
+ | MCFOST_ARGS+=(-max_mem " | ||
+ | elif [ -n " | ||
+ | MCFOST_ARGS+=(-max_mem " | ||
+ | fi | ||
+ | mcfost " | ||
+ | mcfost_rc=$? | ||
+ | |||
+ | # Add any cleanup commands here... | ||
+ | |||
+ | exit $mcfost_rc | ||
+ | </ | ||
+ | |||
+ | ===== Virtualenv Integration ===== | ||
+ | |||
+ | The recipe shown here for integration with a Python virtualenv is a real-world example provided by a Caviness user. As with the stand-alone scheme, it begins with setting-up the directory that will hold the software: | ||
+ | |||
+ | <code bash> | ||
+ | $ export MCFOST_PACKAGE=" | ||
+ | $ export MCFOST_PREFIX=" | ||
+ | $ mkdir -p " | ||
+ | $ cd " | ||
+ | </ | ||
+ | |||
+ | For this recipe the new Intel oneAPI compilers will be used. As of March 20, 2023, the MCFOST code included support for the traditional Intel Fortran compiler and the GNU Fortran compiler. | ||
+ | |||
+ | <code bash> | ||
+ | $ export MCFOST_VERSION=" | ||
+ | $ mkdir -p " | ||
+ | </ | ||
+ | |||
+ | ==== Build the Virtual Environment ==== | ||
+ | |||
+ | At the very least a Python '' | ||
+ | |||
+ | The recipe presented here also requires Open MPI and HDF5 support. | ||
+ | |||
+ | <code bash> | ||
+ | $ vpkg_devrequire hdf5/ | ||
+ | $ vpkg_require openmpi/ | ||
+ | </ | ||
+ | |||
+ | The virtual environment will require a few modules that are compiled against local libraries | ||
+ | |||
+ | * mpi4py | ||
+ | * schwimmbad | ||
+ | * image_registration | ||
+ | * FITS_tools | ||
+ | * h5py | ||
+ | * DebrisDiskFM | ||
+ | |||
+ | the following (compiled) modules provided by the Intel channel | ||
+ | |||
+ | * numpy | ||
+ | * scipy | ||
+ | * astropy | ||
+ | * matplotlib | ||
+ | * zipp | ||
+ | * pluggy | ||
+ | * atomicwrites | ||
+ | |||
+ | and a few standard PyPI modules | ||
+ | |||
+ | * emcee | ||
+ | * corner | ||
+ | * pyklip | ||
+ | |||
+ | The process follows: | ||
+ | |||
+ | <code bash> | ||
+ | $ conda create --prefix " | ||
+ | $ conda activate " | ||
+ | $ conda uninstall --force-remove impi_rt | ||
+ | $ pip install --upgrade pip | ||
+ | $ pip install --no-binary :all: --compile mpi4py | ||
+ | $ pip install --compile emcee corner pyklip | ||
+ | $ pip install --no-binary :all: --compile schwimmbad image_registration FITS_tools | ||
+ | $ CC=" | ||
+ | </ | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | If successful, the DebrisDiskFM module can be built; there is no PyPI or conda channel packaging of DebrisDiskFM so it must be built from source: | ||
+ | |||
+ | <code bash> | ||
+ | $ mkdir -p " | ||
+ | $ cd " | ||
+ | $ git clone https:// | ||
+ | $ cd DebrisDiskFM | ||
+ | $ python setup.py install --compile | ||
+ | </ | ||
+ | |||
+ | At this point all of the Python components of the virtualenv have been completed. | ||
+ | |||
+ | ==== Build MCFOST ==== | ||
+ | |||
+ | Akin to the procedure outlined above: | ||
+ | |||
+ | <code bash> | ||
+ | $ cd " | ||
+ | $ git clone https:// | ||
+ | $ cd mcfost | ||
+ | </ | ||
+ | |||
+ | The procedure is again scripted: | ||
+ | |||
+ | <file bash SWMGR-build.sh> | ||
+ | #!/bin/bash -l | ||
+ | |||
+ | vpkg_require hdf5/ | ||
+ | |||
+ | export MCFOST_INSTALL=" | ||
+ | export MCFOST_GIT=1 | ||
+ | export MCFOST_AUTO_UPDATE=0 | ||
+ | |||
+ | export SYSTEM=ifx | ||
+ | #export MCFOST_XGBOST=yes | ||
+ | export SKIP_HDF5=yes | ||
+ | export HDF5_DIR=" | ||
+ | |||
+ | # Start with the library build: | ||
+ | pushd lib | ||
+ | ./ | ||
+ | if [ $? -ne 0 ]; then | ||
+ | exit 1 | ||
+ | fi | ||
+ | # Remove the HDF5 fake install root that install.sh created: | ||
+ | [ -d ~/ | ||
+ | popd | ||
+ | |||
+ | # Move to the executable build: | ||
+ | pushd src | ||
+ | make | ||
+ | if [ $? -ne 0 ]; then | ||
+ | exit 1 | ||
+ | fi | ||
+ | |||
+ | # There is no " | ||
+ | mkdir -p " | ||
+ | cp mcfost " | ||
+ | popd | ||
+ | |||
+ | # Add a symlink to the utils directory to the install prefix, too; | ||
+ | # we'll set MCFOST_UTILS to point to that: | ||
+ | ln -s " | ||
+ | |||
+ | </ | ||
+ | |||
+ | As in the stand-alone recipe, the '' | ||
+ | |||
+ | <code bash> | ||
+ | $ chmod +x SWMGR-build.sh | ||
+ | $ ./ | ||
+ | </ | ||
+ | |||
+ | If successful, the '' | ||
+ | |||
+ | <code bash> | ||
+ | $ which mcfost | ||
+ | / | ||
+ | </ | ||
+ | |||
+ | Henceforth additional Python modules can be added, either using the '' | ||
+ | |||
+ | ==== VALET Integration ==== | ||
+ | |||
+ | For a user building and managing MCFOST on their own, the VALET package definition file should be placed in '' | ||
+ | |||
+ | <code bash> | ||
+ | $ echo $MCFOST_PREFIX ; echo $MCFOST_VERSION | ||
+ | / | ||
+ | 2023.03.21 | ||
+ | </ | ||
+ | |||
+ | With those values, '' | ||
+ | |||
+ | <file yaml stellar-cooling.vpkg_yaml> | ||
+ | stellar-cooling: | ||
+ | prefix: / | ||
+ | description: | ||
+ | url: " | ||
+ | |||
+ | default-version: | ||
+ | |||
+ | actions: | ||
+ | - variable: MCFOST_INSTALL | ||
+ | value: ${VALET_PATH_PREFIX} | ||
+ | - variable: MCFOST_UTILS | ||
+ | value: ${VALET_PATH_PREFIX}/ | ||
+ | |||
+ | versions: | ||
+ | 2023.03.21: | ||
+ | description: | ||
+ | dependencies: | ||
+ | - hdf5/ | ||
+ | - openmpi/ | ||
+ | actions: | ||
+ | - action: source | ||
+ | script: | ||
+ | sh: intel-python.sh | ||
+ | success: 0 | ||
+ | </ | ||
+ | |||
+ | Once created, the syntax can be checked: | ||
+ | |||
+ | <code bash> | ||
+ | [frey@login01.caviness ~]$ vpkg_check ~/ | ||
+ | / | ||
+ | : | ||
+ | </ | ||
+ | |||
+ | When additional versions/ | ||
+ | |||
+ | <code bash> | ||
+ | python my_script.py … | ||
+ | </ | ||
+ | |||
+ | or as an executable itself should include the following hash-bang on the first line of the file: | ||
+ | |||
+ | <code bash> | ||
+ | # | ||
+ | </ |