Enable CabanaMC functionality

ECP-copa / CabanaMD

Molecular dynamics proxy application based on Cabana

Other

19 stars 14 forks source link

Enable CabanaMC functionality #33

Open streeve opened 4 years ago

streeve commented 4 years ago

[x] Break up cmake file into library and executable (to simplify work of adding multiple executables).
[ ] Create a test for energy calculations.
[ ] Build class/template-based input method for molecular topologies.
[ ] Create simplified route to calculation of Delta E-values.

(add frobnitzem)

streeve commented 4 years ago

To continue on this, @frobnitzem, can you tell me a bit more about what you would ultimately need?

I'm close to adding unit tests, but will the lammps style data input be sufficient, or do you use other tools? And what type of force fields are you envisioning?

frobnitzem commented 4 years ago

I'm working on one of these tests now. I want to re-do the system setup into a datastructure that sets up box shape and other globals (read with yaml?) and a C++ code responsible for creating atom positions and running the actual MD steps. NAMD uses TCL scripts to write MD protocols, and LAMMPS uses its own DSL, but I say why not define a DSL-like API and just use C++ code? Eventually, I'd like to have distinct Hamiltonian and Molecule datastructures.

frobnitzem commented 4 years ago

The new branch is under development at https://github.com/frobnitzem/CabanaMD/tree/tests. Right now, the test itself isn't working, but it simplifies lattice gen. code while adding LATTICE_BCC, changes shutdown/finalize to use C++ destructors, and fixes two memory management bugs (no delete on shutdown, comm used uninitialized at one point).

streeve commented 4 years ago

Overall this sounds good to me. A few things - it's important to keep the LAMMPS compatible inputs in so far as this is a proxy app meant (in part) to represent LAMMPS and integrate improvements back and forth.

Of course I'm not opposed to added capabilities, but at some point the cutoff between a proxy app and a full-feature app has to be determined. This would probably be the point at which some specific LAMMPS style and capabilities could be safely removed.

One other note on the system setup - we're planning on merging the Cabana sister library, Cajita (particle-grid operations), into the Cabana repository to simplify things even further for CabanaMD: ECP-copa/Cabana#197

frobnitzem commented 4 years ago

IMHO, the input file was LAMMPS's worst design decision. It forces the user to write a series of updates to a bunch of undefined data structures they can't see, and proliferates command-names instead of creating a programming model. Using a LAMMPS-type input file will force this project to be monolothic and non-extensible.