The C++ core of d-SEAMS, a molecular dynamics trajectory analysis engine. Deferred Structural Elucidation Analysis for Molecular Simulations
nix
build system, then please note that you must manage the dependencies MANUALLY, including the compiler versions. Optionally, use the provided conda
environment.If you use this software please cite the following:
Goswami, R., Goswami, A., & Singh, J. K. (2020). d-SEAMS: Deferred Structural Elucidation Analysis for Molecular Simulations. Journal of Chemical Information and Modeling. https://doi.org/10.1021/acs.jcim.0c00031
The corresponding bibtex
entry is:
@Article{Goswami2020, author={Goswami, Rohit and Goswami, Amrita and Singh, Jayant Kumar}, title={d-SEAMS: Deferred Structural Elucidation Analysis for Molecular Simulations}, journal={Journal of Chemical Information and Modeling}, year={2020}, month={Mar}, day={20}, publisher={American Chemical Society}, issn={1549-9596}, doi={10.1021/acs.jcim.0c00031}, url={https://doi.org/10.1021/acs.jcim.0c00031} }
We use a deterministic build system to generate both bug reports and uniform usage statistics. This also handles the lua
scripting engine.
We also provide a conda
environment as a fallback, which is also recommended for MacOS users.
Although we strongly suggest using nix
, for MacOS systems, the following instructions may be more suitable. We will assume the presence of micromamba:
Now the installation can proceed.
lua-luafilesystem
within the conda
environment because it is outdated on osx
We have opted to install into the conda
environment, if this is not the intended behavior, use /usr/local
instead.
Manually this can be done in a painful way as follows:
Or better:
Now we can build and install as usual.
Or more reasonably:
Since this project is built with nix
, we can simply do the following from the root directory (longer method):
A faster method of building the software is by using the cachix binary cache as shown:
Having installed the yodaStruct
binary and library, we can now use it.
.yml
should be relative to the folder from which the binary is called.If you're confused about how to handle the relative paths, run the command yodaStruct -c lua_inputs/config.yml
in the top-level directory, and set the paths relative to the top-level directory. This is the convention used in the examples as well.
To generate a compile_commands.json
file for working with a language server like ccls use the following commands:
Note that there is no need to actually compile the project if you simply need to get the compiler database for the language server.
Do Not commit the .json
file.
We can simply use the nix
environment:
This is built completely with nix:
To run the sample inputs, simply install the software, and ensure that input/
is a child directory.
Apart from the examples, the test-suite can be run with the yodaStruct_test
binary, which will drop into the nix
environment before building and executing gdb
:
Do note that the regular installation via nix-env
runs the tests before the installation
While developing, it is sometimes expedient to update the packages used. It is then useful to note that we use niv to handle our pinned packages (apart from the ones built from Github). Thus, one might need, say:
Test the build with nix:
While testing for leaks, use clang
(for AddressSanitizer and LeakSanitizer) and the following:
As of Mon Jan 20 15:57:18 2020, the lines of code calculated by cloc are as follows:
Please ensure that all contributions are formatted according to the clang-format configuration file.
Specifically, consider using the following:
Where some of the above suggestions are derived from this depreciated githook.
Also, do note that we have a CONTRIBUTING
file you need to read to contribute, for certain reasons, like, common sense.
Note that we expect compliance with the clang-format
as mentioned above, and this may be enforced by using the provided scripts for a pre-commit hook:
This will ensure that new commits are in accordance to the clang-format
file.
The general idea is to drop into an interactive shell with the dependencies and then use cmake
as usual.
To load debugging symbols from the shared library, when you are inside gdb
(from the top-level directory, for instance), use the following command:
Then you can set breakpoints in the C++ code; for instance:
The following tools are used in this project:
git
hooks to enforce formattingThe libraries used are:
gdb
yaml