Skip to content

Latest commit

 

History

History
131 lines (125 loc) · 4.74 KB

File metadata and controls

131 lines (125 loc) · 4.74 KB

Conda bugs

Occasionally, the library is installed to the wrong path[^1], in which case the output of the above command should be checked for the location and then that should be added to `$PATH`.

“`{code-block} bash meson install -C bbdir | grep libeon Installing client/libeoncbase.so to /micromamba/envs/eongit/lib Installing client/libeonclib.so to /micromamba/envs/eongit/lib “`

At which point we should add the library path:

“`{code-block} bash export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/micromamba/envs/eongit/lib “`

[^1]: Due to the [post-fix labeling](https://conda-forge.org/docs/user/faq/#why-dont-the-cc-compilers-automatically-know-how-to-find-libraries-installed-by-conda) of `conda-compilers`

What

Documentation which is still usable, but not recommended.

Nix [Deprecated]

This is preferred since it is reproducible. You will need nix.

# Debug errors
nix-build -K .
# Add to path
nix-env -if .

Development

To get a new shell to work on the packages, use the following:

# With gcc
nix-shell --pure --run bash --show-trace --verbose
# With clang
nix-shell --argstr clang --pure --run bash --show-trace --verbose
Linux

In a new sub-shell:

# On Linux machines:
cd client
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug -DUNIX=TRUE -DPACKAGE_TESTS=ON -DNO_WARN=TRUE -DFIND_EIGEN=TRUE -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -DWITH_GPRD=TRUE -DWITH_FORTRAN=FALSE -G "Ninja"
VERBOSE=1 ninja
ctest

Currently the ctests are out of date, and meson is recommended.

MacOS

In the new sub-shell:

cd client
./version.sh > version.h
meson setup builddir -Dwith_ams=true -Dwith_gprd=true --buildtype=release
VERBOSE=1 meson compile -C builddir

All the options are documented in meson_options.txt. Occasionally, when the installation is not done, there may be some linking errors. These can be fixed by:

# In a conda environment
cd builddir
export LD_LIBRARY_PATH=$CONDA_PREFIX/lib64:$LD_LIBRARY_PATH
export PATH=$(pwd):$PATH

Dependencies can be obtained via:

micromamba env create -f environment.yml
micromamba activate eongit

Testing

Once eonclient has been built following the instructions above, we can run integration tests (AKMC) in the development environment.

nix-shell
# In the root directory
pytest

Simplify

  • [ ] Make a default.nix
    • [ ] Build tsase
    • [x] Build eon
      • Currently works from nix-shell invocations
    • [x] Build eonclient

Cmake

The following will suffice:

cd client
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug -DPACKAGE_TESTS=ON -DNO_WARN=TRUE
# cmake --build . -- VERBOSE=1
make -j$(nproc) VERBOSE=1 && make check
export PATH=$(pwd):$PATH

Tests

make check is typically all that is needed. However, the manual testing methods of the next section work as well.

Make

Old style, ugly.

cd client
make -j$(nproc) # Will break
make # Will not break now
export PATH=$(pwd):$PATH

Manual Tests

# From root repo directory
cd client/gtests/data/saddle_search/
eonclient

GPR Dimer Tests

One of make check tests will break, and this is the GPR dimer call. The tests run in the appropriate test directory; however, debugging make check is a bit annoying.

Debugging

Not the best method, but still cleaner than keeping a whole temporary run folder; we can copy the data into the build/gtests folder and then debug the test target:

make -j$(nproc) && make check
cd gtests
cp ../../gtests/data/gpr_dimer/client.log ../../gtests/data/gpr_dimer/config.ini ../../gtests/data/gpr_dimer/direction.dat ../../gtests/data/gpr_dimer/displacement.con ../../gtests/data/gpr_dimer/mode.dat ../../gtests/data/gpr_dimer/pos.con ../../gtests/data/gpr_dimer/results.dat .
gdb gprdimereon # or lldb

Usage for GPRD

Included is the eonc.rb helper in tools/gprdimer/, which can be used with any of the gtests/data/systems and a suitable configuration file.

Development Rosetta

Machine Learning Concepts

eOn Concepts

We will establish some terminology to begin with.

Free Atoms
These atoms are moved by the client
Fixed Atoms
These are the atoms which are indicated in con files generated by the eon server to not be moved by the eonclient binary
Frozen Atoms
These are defined in the GPR to be those atoms which do not move; so they are equivalent to eon’s fixed specification
Active Frozen
A GPR only restriction, due to the poor scaling of the high dimensional observations