Changes for lammps integration

[agoscinski]

A PR to discuss required changes for the integration of rascal as pair potential into lammps. Please also check out the changes made on the lammps side agoscinski/lammps#1 You should be able to use the lammps draft by just cloning this repo with this branch within lammps src folder. There is an examples/rascal/in.lammps file you can use. It should at least run one compute iteration (loading model, computing forces with it) and then crash.

With the current code I get a memory error after the compute step in the pair potential has finished. I think it is related to the destruction of the structure manager. A detailed trace of the debug log can be found here https://github.com/agoscinski/lammps/files/6726135/log.txt

---

Minor changes have been done

• some format changes in functions for models storage dumping python obj to dict/json, so the output can be similar easy read from the c++ side (Does not affect other branches, since it just changes how the spherical invariant is stored within the model storage, but does not touch model json structure)
• disabled some checks which require cell information which we do not have in the case of lammps

Changes need to be done later:

• move all code within the rascal_pairs.cpp in lammps to a general interface
• we use volume in stress calculation, again this information is not available from lammps

        json structure_copy = manager_root->get_atomic_structure();
        auto atomic_structure =
            structure_copy.template get<AtomicStructure<ThreeD>>();
        neg_stress[0] /= atomic_structure.get_volume();

[Luthaf]

Is this what you mean with the sentence below?

disabled some checks which require cell information which we do not have in the case of lammps

The periodicity of the cell should be available somewhere in lammps, it is set with the boundary command in the input.

The cell lengths can be recomputed if we want from LAMMPS xlo xhi and friends.

[agoscinski]

Yes this part is meant. Also in stress one line is commented out. Yes it should be somewhere available, it is not so urgent at the moment.

[agoscinski]

I don't know how to get the central atom tag from a ghost atom in lammps, because we use the neighbour tag of the nonghost atom when iterating through the neighbourlist. Here the comparison of the neighbourlist of lammps and how it should be

StrutureManagerLammps              StructureManagerCenter                 
pair (0, 0) global index 0         pair (0, 0) global index 0
pair (0, 38) global index 1        pair (0, 2) global index 1  
pair (0, 35) global index 2        pair (0, 4) global index 2  
pair (0, 19) global index 3        pair (0, 3) global index 3  
pair (0, 1) global index 4         pair (0, 1) global index 4  
pair (1, 1) global index 5         pair (1, 1) global index 5  
pair (1, 38) global index 6        pair (1, 2) global index 6  
pair (1, 35) global index 7        pair (1, 4) global index 7  
pair (1, 19) global index 8        pair (1, 3) global index 8  
pair (1, 0) global index 9         pair (1, 0) global index 9  

I looked where this information could be stored it in lammps in the atom.cpp and neigh_list.cpp but could not find anything.

EDIT: I think problem is solved, just found atom->tag in lammps

[agoscinski]

Seems to work now, at least no segmentation fault for the input I used (methane_pbc.lammps https://github.com/agoscinski/lammps/blob/a5e34127bd55dfedebeae510fac8b88511837067/examples/rascal/methane_pbc.lammps). The neighbourlists using StructureManagerLammps and Center have same number of pairs with same tags, order is different but that is a possible difference.

---

This is for me to remember how the neighbour list member variables in rascal work, because the doc is not expressive enough
rascal_neighbour_list_member_variables.txt

[agoscinski]

I just checked for two H atoms, the representation for the two atoms are not even the same with lammps. I will see if can get some useful information from our test framework after adapting the tests for the changes in StructureManagerLammps

It is definitely an issue regarding StructureManagerLammps, since it works with the center one (in examples/cpp/krr_model.cc)

[agoscinski]

I found the bug for the soap representation of two hydrogens (without pbc) being different: StructureManagerLammps is considered as half neighbour list in its traits. It is also written in multiple threads that lammps uses a half neighbourlist as default, but when I forward it to rascal it is a full one. I am not sure what setting I have changed or what I have misunderstood that lammps gives me a full neighbour list. Anyway the H2 representation is correct now.

Sources:
https://matsci.org/t/neigh-list-half-half-thread-full/32939
https://sourceforge.net/p/lammps/mailman/lammps-users/thread/33ea1b0a0710030810h126b6e4dr865e4b7848c90948%40mail.gmail.com/#msg8506233
https://matsci.org/t/fix-with-a-specified-cutoff-for-neighbour-list/21553

EDIT: Found the reason for the half neighbourlist, something I have copied over from quip

  int irequest_full = neighbor->request(this);
  neighbor->requests[irequest_full]->half = 0;
  neighbor->requests[irequest_full]->full = 1;

[agoscinski]

The MPI support seems to work now. There are small errors when comparing the MPI runs for different number of tasks, this however seems lammps related, since I could also observe this using QUIP. The physical properties I computed on BaTiO3 with 320 atoms were very close between different number of tasks for the first picosecond and then started to diverge from each other. Same when comparing ipi-lammps-cpprascal with ipi-pyrascal, here it is more an issue of different constants for converting to internal units in ipi and lammps. The average properties seem to be close to each other. A more detailed analysis of this for longer trajectories is currently in progress.

If we consider to merge this thing to master here is the plan for splitting this up into PRs:

• Add cpp paramaters to rascal model PR Adapt cpp representation input paramaters to the ones on the python side #376
• Make lattice information available
  • structure_manager.hh
  • lattice.hh
• StructureManagerLammps fixes + tests
  • structure_manager_lammps.hh
  • tests/test_structure_manager_lammps.cc
• domain decomposition related changes
  • sparse_kernel_predict.hh
  • domain decomposition tests
• Valgrind memory issues (optional)
  • property_block_sparse.hh
  • calculator name is now hashed (needs double check if really needed)

Adding new tests for structure_manager_lammps.hh which test the new changes and tests the additional option offered to support domain decomposition (in sparse_kernel_predict.hh) would take roughly full week of work. Everything else is just a copy paste of this branch and make things clean.