Dear lammps users
I have a model that can run sussecfully with lammps version 23 Jun 2022 and the structure is intact. IHowever, the structure completely collapse if running with 22 Aug 2018. The input is completely same for those two runs. I have to use the 22 Aug 2018 version as some of the code developed by other group is only tested with this version. Could anyone tell me to how sort it out?
Fan
You didn’t provide any info on your model so it’s impossible to tell. If you can provide a complete set of input files (so that others can reproduce it) then maybe someone can take a look (though it’s far from guaranteed since that version is released 5 years ago).
High chance there was a bug fixed between 2022 and 2018. You’d have to figure out what part of the code is affected. Or give a small complete reproducer as mentioned above.
You are - as the saying goes - stuck between a rock and a hard place.
None of the people here will spend any time debugging issues with a 5 year old version of LAMMPS when it has been proven that the issue is resolved when using a current version.
That means, you have two choices:
The preference of the LAMMPS developers is always the second option. If the modification is useful, it can be submitted to the distribution and then others can benefit. One of the advantages of having code in the LAMMPS distribution is that you usually do not have to worry about having to make updates when internal interfaces are changed. This will usually be done by the LAMMPS developers. Also, we may be able to assist with the porting.
That said, there are also arguments for sticking to your old version. But you should remind your PI that doing simulations with an obsolete version of LAMMPS with known bugs (that are fixed in newer releases) is not always a good idea and particularly goes against the requirements that research has to be reproducible.
Hi all,
please find the attached code to add external magnetic field develpoed by Timothy Sirk based on Spreiter alorithm. From the dissussion adding external field Magnetic field, I understand why the lammps does not have such function in the official distribution. This code is only tested with old version, I think other researchers will benifit it as well if the developers can port it to new version of lammps (if there is no plan to have it the official distribution) since there is similar request from the forum.
fix_bfield.cpp (16.5 KB)
fix_bfield.h (1.8 KB)
As it turns out, the effort of porting this fix bfield code to the current version of LAMMPS was not a lot, especially when doing a side-by-side comparison with fix efield.
For a while now, we have a way to make source code available that people are using, and that is either abandoned or not ready for inclusion into the main distribution. Those can be prepared/compiled in a standalone way and then loaded into LAMMPS as a plugin.
I’ve just updated the lammps-plugin repo. I needed to add new tags to synchronize it with the 2 Aug 2023 release anyway.
Thanks you for the efforts to port the code. However, I have problem using it and I started another topic regarding this. How to use lammps plugin.
Hopefully, you could help as well.
Explanations and a suggestion for how to avoid the issue are in the other topic.
I found the new plugin requires NVE and will give an error if other ensembles are used. I wonder the NVE is required by the Spreiter alorithm or it is used for easy porting.
That requirement was in the source code. There are comments explaining it:
// order of pre_integrate fixes important
// fix bfield needs current v(t)
// so fix bfield should occur before other pre_integrate methods
int bfield = 0;
_
for (int i = 0; i < modify->nfix; i++){
if (strcmp(modify->fix[i]->style,"bfield") == 0)
bfield = 1;_
if(modify->fix[i]->time_integrate){
if(!bfield)_
error->all(FLERR,"fix bfield must be defined before nve integrator.");
if (strcmp(modify->fix[i]->style,"nve") == 0 || strcmp(modify->fix[i]->style,"nve/limit") || strcmp(modify->fix[i]->style,"nve/sphere") == 0)_
break;
else_
error->all(FLERR,"fix bfield requires fix nve or nve/limit or nve/sphere.");
}
}
You may have by accident bypassed it. But as part of the porting, I made the test simpler and more robust:
// order of pre_integrate fixes important
// fix bfield needs current v(t)
// so fix bfield should occur before other pre_integrate methods
int bfield = 0;
for (const auto &ifix : modify->get_fix_list()) {
if (utils::strmatch(ifix->style, "^bfield") == 0) bfield = 1;
if (ifix->time_integrate) {
if (!bfield)
error->all(FLERR, "fix bfield must be defined before NVE style time integrator");
if (!utils::strmatch(ifix->style, "^nve"))
error->all(FLERR, "fix bfield requires an NVE style integrator");
}
}
The problem with magnetic fields in LAMMPS is that LAMMPS uses a velocity Verlet algorithm, so you do two “half” updates of the velocity, once with old and once with new forces. However, that creates a problem, since the magnetic forces are velocity dependent. Fix bfield works around this by doing an approximate full step velocity update so you have consistent velocities (and thus forces).
The situation for DPD is somewhat similar, and there exists a fix mvv/dpd command that has a similar purpose and allows to adjust where exactly in the timestep to have the accurate forces (with a parameter you can change between full old and full new forces).
However, this will cause errors with non-nve integrators. That is not an easy problem to solve and thus nobody has dared to submit a proper implementation of fix bfield, since nobody wants to be responsible for all the people that are eager to use it, but do not know how to program it and may not know or understand the limitation (or willing to overlook it for joy of finding the command they looked for for such a long time.
BTW: did you notice that:
I understood why nve is propriate now. However, I am confused by “there is only the global energy (not per-atom) and a total magnetic force”. If possible, could you please explain a little bit more?
You need to study the source code. I was just pointing out that there is a significant risk of using “unconfirmed” source code that has not been properly vetted. It may not be fully consistent with the rest of LAMMPS.
While the LAMMPS developers cannot know all details and double/triple check every aspect of a contribution, we do check on what functionality is included (from the pure technical point of view). In this case, it is rather straightforward to compare with fix efield, for example and notice which equivalent pieces have been omitted. Fix bfield is obviously incomplete and that is the likely reason why it was never included into the LAMMPS distribution (and will not in its current shape).