Installation

eOn is divided up into two separate programs: a server and a client. The client does most of the computation (e.g. saddle searches, minimizations, and molecular dynamics) while the server creates the input for the client and processes its results.

Getting started

The simplest way to hit the ground running is with the conda package:

# best with pixi
pixi init
pixi add eon
# or with conda/micromamba
micromamba install -c conda-forge eon

At this point any of the many examples should be good to go.

The conda package is a maximalist build with the following potentials and features enabled:

The server is accessed through python -m eon.server, and the eonclient binary is automatically made available in the activated environment.

Changed in version 2.0: While reading older documentation, calls to eon must now be python -m eon.server.

Obtaining sources

Added in version 2.0: eOn is now developed and distributed primarily via GitHub.

Once git is present[1]:

git clone https://github.com/TheochemUI/eOn.git
cd eOn

Building from source

We provide a conda environment and pixi setup, with dependencies handled by conda-lock.

pixi shell
# or
pixi s -e dev-lite

Other environments can be found by inspecting the pixi.toml file.

This is the installation path that fails least often:

# conda-compilers may try to install to
# $CONDA_PREFIX/lib/x86_64-linux-gnu
# without --libdir
meson setup bbdir --prefix=$CONDA_PREFIX --libdir=lib --buildtype=release
meson install -C bbdir

If that meson setup stops on glibc errors raised from inside <cmath>, add --force-fallback-for=nlohmann_json and read the rolling distro section below for what causes it.

Some additional performance can be gained with ccache and mold, which can be passed with --native-file:

  • With ccache installed, add --native-file nativeFiles/ccache_gnu.ini

  • With mold installed, add --native-file nativeFiles/mold.ini

Troubleshooting: rolling distros (Arch, Fedora)

On rolling-release distributions with newer system packages, the conda-forge compiler sysroot conflicts with system headers. meson setup stops during the compiler checks with errors such as __iseqsigf128 was not declared or __fpclassify has not been declared, raised from inside <cmath>. Nothing in the output names the package responsible, so the failure reads as a broken toolchain.

By default meson prefers an installed nlohmann_json module (pkg-config or CMake, from EasyBuild and distro packages) and falls back to the wrap, the same pattern as readcon. The system CMake config for nlohmann_json exports -I/usr/include, which mixes glibc headers into the conda sysroot. Force the wrap to keep that include path out of the build:

meson setup bbdir --prefix=$CONDA_PREFIX --libdir=lib \
  --force-fallback-for=nlohmann_json

client/meson.build carries the same note beside the nlohmann_json dependency lookup.

Troubleshooting: a global cargo linker setting

readcon-core is built by cargo, which reads ~/.cargo/config.toml in addition to the environment. A rustflags entry there applies to every crate eOn builds, including inside a conda or pixi environment where the compiler is conda-forge’s rather than the system one.

The case that comes up is a linker override. -C link-arg=-fuse-ld=mold works with a system GCC new enough to resolve mold by name, but the absolute form -fuse-ld=/usr/bin/mold is rejected by conda-forge’s GCC 13:

error: linking with `x86_64-conda-linux-gnu-cc` failed: exit status: 1
  = note: x86_64-conda-linux-gnu-cc: error: unrecognized command-line option
          '-fuse-ld=/usr/bin/mold'
error: could not compile `zmij` (build script)
FAILED: subprojects/readcon-core/libreadcon_core.a

RUSTFLAGS overrides build.rustflags from the config file, so clearing it for the build leaves the global setting alone:

RUSTFLAGS= meson compile -C bbdir

The same applies to scripts/pyeonclient_build_wheel.sh, which builds readcon-core through cargo as part of the wheel.

Optional packages

The full listing of options is found in the meson_options.txt file. These can all be turned on and off at the command line. As an example see the LAMMPS integration instructions.

For optional wrapped dependencies such as ARTn and IRA, download the subproject sources before configuring:

meson subprojects download artn-plugin ira

Licenses

eOn is released under the BSD 3-Clause License.

Vendored

Some libraries[2] are distributed along with eOn, namely:

  • mcamc which contains libqd :: BSD-3-Clause license

Added in version 2.0:

  • magic_enum :: MIT License

  • catch2 :: Boost Software License, Version 1.0

  • ApprovalTests.cpp :: Apache 2.0 License

Deprecated since version 2.0:

  • Eigen 2.x :: Mozilla Public License