The code files are all in the FOORT/src subfolder.
The executable can be built with CMake, which should be installed first (for regular Makefiles, see further). The advantage of this method it that, in principle, CMake will automatically detect your relevant compilers. Furthermore, it will enable you to generate the automated documentation and run the tests, if needed.
One can then run
cmake -S . -B build
cmake --build build
which will cause the executable to be stored in the FOORT/bin subdirectory. CMake can be cleaned by simply removing the relevant folders
rm -rf build
Typically, compiling with CMake on an HPC-cluster requires loading the relevant CMake module. This code has been succesfully compiled on CSD3 (Cambridge) and Cosma7 (Durham) using the latest CMake modules.
One could get an error if the version of CMake is not recent enough. Alternatively, gcc version 7.5 (and presumably lower) raised an issue of not finding the filesystem header. If this problem is encountered, one should change this header to <experimental/filesystem>. With this one change, the code also compiled on Fawcett, a smaller cluster (DAMTP, Cambridge).
Recent versions of MacOS may encounter issues with CMake. The following seems to resolve current issues. (Found in this issue)
export CC=/opt/homebrew/bin/gcc-14
export CXX=/opt/homebrew/bin/g++-14
export FC=/opt/homebrew/bin/gfortran-14
export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/
For convenience, this is stored in alternative_builds/MacOS_workaround.sh, which should be executed with source \the\path\ in the terminal in case issues are encountered. You may need to rm -rf build in order to start clean. In case this doesn't work (which is not unlikely - some of it is black magic), one can also revert to the makefile_mac as described below.
Alternatively, old Makefiles can be found in alternative_builds/old_makefiles. These can be system dependent, however, but should be adaptable to your needs. If the user wants to use these, the relevant makefile should be copied into the src folder, in which
make -f <makefile>
should be run, where <makefile> should be replaced with the name of the relevant file.
Use the alternative_builds/Foort.sln Visual Studio solution file and compile the FOORT project therein.
See in the output file for sample output files and Mathematica notebooks that process (and plot) this output. (The documentation will also have more information in the future.)
A small example notebook is provided to visualize specific examples of the Kerr and Johannsen metric. These examples first need to be run: first, compile the FOORT binary as per the instructions above. Then, from the root directory, do
cd FOORT
bin/FOORT cfgs/KerrExample.cfg
bin/FOORT cfgs/JohannsenExample.cfg
This populates the necessary output files in the Output subfolder. A Python environment for the post-processing scripts and notebook is provided in PostProc/environment.yml. Create and activate it, e.g., using conda
cd PostProc
conda env create -f environment.yml
conda activate foort-postproc
See the Documentation for more information on configuration options, how to add your own Metric, Diagnostic, or Termination, and how to process output.
You can consult the doxygen created documentation to find out more about the structure of the code.
If you have downloaded the repository, you can achieve this by opening docs/html/index.html in a browser.
A PDF version of this documentation is also available in docs/latex.
The doxygen documentation can be generated by running
cmake --build build -t doxygen
This updates the html documentation right away. To update the LaTeX documentation, one also need to
cd docs/latex
make
The doxygen documentation for the files pyFOORT.py and PhotonRingInterferometry.py can be generated by running doxygen in the PostProc subfolder. This will only generate html documentation, in docs/postproc/html, which can be consulted by opening docs/postproc/html/index.html in a browser.
The tests can be run with
ctest --test-dir build
and should all pass.