Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Revised implementation of a new atomic stress definition for correct computation of heat flux with many-body interactions #1704
This PR is a revised version of PR #1462 according to advice from @athomps. I created a new branch, as little code was shared with the previous PR.
Supersedes PR #1462
Donatas Surblys (Tohoku University) surblys.donatas at gmail dot com
By submitting this pull request, I agree, that my contribution will be included in LAMMPS and redistributed under either the GNU General Public License version 2 (GPL v2) or the GNU Lesser General Public License version 2.1 (LGPL v2.1).
Full backward compatibility.
Currently, only angles, dihedrals and impropers are implemented. This should work well enough, unless pair styles with many body interactions, such as AIREBO are used. The USER-OMP versions are also implemented. Because I needed to add an argument to the ThrOMP::ev_setup_thr, I had to update all of the pair/bond/angle/dihedral/improper files in USER-OMP, so the number of changed files is quite large.
A new compute centroid/stress/atom, that has 9 components per atom, has been constructed and is mostly identical to compute stress/atom. Compute heat/flux has been modified to accept the new centroid/stress/atom compute.
Before continuing to implement centroid virial for tersoff/AIREBO and similar, I would like to get some feedback from the developers if this approach is acceptable.
Post Submission Checklist
Please check the fields below as they are completed after the pull request has been submitted. Delete lines that don't apply
Further Information, Files, and Links
I like this a lot better. However, I am not convinced that it is necessary to add cvatom as a separate variable. Why not reuse vatom, since it is also a 3x3 array? You would just need to have switches within angle.cpp etc., to control whether the centroid or regular per-atom stress is computed.
correction. vatom is dimensioned nmax by 6.
i am in favor of having the storage separately. reusing existing storage locations for two different purposes is just asking for trouble, since we don't have proper encapsulation in LAMMPS and keeping track of what is what would become a maintenance nightmare. conserving every little byte of storage is not as much of an issue than it used to be.
@donatas-surblys i just enabled additional automated testing for this PR. it will run one set of tests, where the check is if the executable compiles with certain settings and runs over a set of inputs completes with different parallelization settings, and a second, more thorough set of tests, where also the results are compared to a reference. it roughly covers the code paths in LAMMPS for which there are example inputs and a few other basic cases. that will make sure that at least for common operations, everything will remain working.
I’ve rebased the PR to the newest master.
Missing support for angle/dihedral/improper hybrid was added.
Initial support for centroid atomic stress for pair styles has been added. A new flag “cntratmstressflag” has been added to the Pair class. Value of 1 indicates that the centroid atomic stress is identical to normal atomic stress, and the values are stored in vatom. Value of 2 indicates that centoid atomic stress has been implemented for the pair style, and that the values are stored in cvatom. Value of 4 indicates that centroid atomic stress has not been implemented for that pair style. The default has been set to 4. I initially wanted a value of 0 to indicate a lack of implementation, but it made it difficult to interact gracefully with pair hybrid. The “cntratmstressflag” might also have a value of 3, indicating to set both vflag_atom and cvflag_atom to true, as sometimes the tally functions are not called otherwise.
Initial support has also been added to USER-OMP pair styles, but unfortunately I did not find a way to access “cntratmstressflag” from inside ThrOMP::ev_setup_thr, therefore it is checked if cvatom is a null pointer instead. This has an unfortunate side effect, that USER-OMP pair styles can no-longer tell the difference between cntratmstressflag = 2 and cntratmstressflag = 3, so the current plan is to always at least allocate vatom array when centroid atomic stress is needed.
I’ve set cntratmstressflag = 1 to non-kspace pairwise-only pair styles in OPT, USER-OMP, USER-FEP and CLASS2, though I’m sure I’ve missed a few. Kspace is kind of tricky, because while it should be OK for total system heat flux, it becomes theoretically shaky when applied to a local control volume. I have some vary preliminary results that looked OK for local heat flux with kspace, but there’s no rigid theoretical or empirical work to back it up. I guess we might as well enable them, as this would be in line with compute stress/atom for pairwise interactions.
I’ve added a check to the compute centroid/stress/atom, to error out if a unsupported pair style is used when the pair virial is requested. The flag logic is set up so that if the error line was changed to a warning or deleted, then unimplemented styles would simply fallback to the old behaviour.
I’ve tried to update the documentation for compute stress/atom and compute heat/flux to include the information on the new compute centroid/stress/atom. I’ve converted all the equation images to equations and added inline math where possible. I’ve tried to keep as much of the original text and structure as possible, but had to rearrange some things. I am considering adding a warning that when computing local heat flux (or pressure), only control volumes in bulk regions are likely to give reliable results. Let me know if more clarity or details are needed.
I am also not sure about the citation policy. I’ve added our group’s paper  that gives details on the implementation to the documentation of compute stress/atom, and also added it to the documentation of compute heat/flux together with the paper by Boone et al.  inside a warning about many-body interactions, as it is closely related. I haven’t added the work by Fan et al. , as the pair styles they deal with are no yet implemented.
@akohlmey The current PR implementation allows for this. You can use compute stress/atom for the original atomic stress and compute centroid/stress/atom for the new definition simultaneously. compute heat/flux will do the right thing when passed either one of them.
@donatas-surblys Thanks for working thru the details on this, with all the feedback from the developers. It looks like a very nice addition to LAMMPS. 2 Qs/comments on the doc pages.
Thank you for the feedback.
I’ve changed the flag name.
Changed pairwise to two-body where appropriate in source code comments.
I’ve slightly modified both the compute stress/atom and compute heat/flux documentation. Basically got rid of using “many-body” to describe both bonded and non-bonded interactions, and mostly switched to simply using angle/dihedral/improper, as that is what is currently implemented. I’ve also update the restrictions section according to the advice of @sjplimp. Let me know if this is what you had in mind.
@sjplimp The EAM potential is an interesting example. It all comes down on how you distribute per-atom potential. If you assume that only atoms i and j are attributed potential energy, even though it also depends on density, then you should able to treat it as a pairwise-like potential and it will probably work out. That said, I’d like to do some testing and a more rigid theoretical checks before enabling such cases.
It seems that the “lammps/pull-requests/cmake/cmake-kokkos-cuda-pr” check failed, but looking at the logs it seems to be a timeout error? Am I reading this right?
Please note, that we just merged some changes to the EAM styles, that allow partitioning of the energy between pairs. The tricky part is the embedding energy term, which we now evenly distribute over all neighbors within the force cutoff as shown in
I will have closer look at the changes in the PR now and update it to the current master to make certain, there are no conflicts with the recent changes to the documentation.