I am having a vexing issue with a third-party potential behaving differently in 2014 and 2015 versions of LAMMPS. I am using the angular embedded atom Al-Si potential from the following source: GitHub - psaidi/AEAM: Angular embedded atom method code for LAMMPS. Two files (pair_aeam.cpp and pair_aeam.h) must be included in the src directory of LAMMPS during compilation.
A basic script that demonstrates the problem (reading the potential energy of a small Al-Si structure) is attached here. The steps to reproduce the error are as follows:
Compile lammps with aeam files in src directory
Run the script PE_calc.in
Using the 2014.06/28 version of LAMMPS, the potential energy calculation gives reasonable results. Using 2015.02/15 or later versions, the potential energy is extremely high (indicating that the simulation has blown up) despite a successful compilation on step 1.
During step 1, warning messages are generated for 2015 or later versions as attached:
They seem to be related to the syntax of the energy calculation in the potential file. Note that the compilation runs to completion and that these are just warning messages.
A separate, but possibly related issue, even for 2014 versions, is that the sum of per atom energies in a given Al-Si system is not equal to the total potential energy at 0 K (calculations only give expected results using the total potential energy). This mismatch is mysterious to me, but seems like it must be related to how the potential is coded.
I understand that this is a very specific issue to third-party lammps code, but any debugging advice or insights would be appreciated. If I can make this potential work with 2015 or later versions of LAMMPS, I will have access to other fixes that are needed for my intended simulations.
These warnings are harmless, they just warn about code not following modern programming style conventions of the GNU compilers.
I can help with that. How urgently are you looking for it. I am currently looking for external LAMMPS styles or packages that could be “modernized” and then converted into plugins so they can be compiled for and used with current versions of LAMMPS without being part of the LAMMPS distribution.
As far as urgency goes, it would be extremely helpful to have this in the short term. Specifically, I am looking for compatibility of A-EAM functionality with the fix atom/swap command which appears in 2015 first quarter and later versions of LAMMPS. The goal here is to use MC calculations for both phase diagram computation and structural optimization (on fairly large systems).
I have a version now that can be compiled as a plugin with the latest LAMMPS release.
I am noticing that the code has a bug when running in parallel and parsing the potential file.
This is very much unpolished and unfinished, but as far as I can tell it will work in serial.
So you could download the latest LAMMPS version, copy the pair_aeam.h and pair_aeam.cpp files into the src folder, build a serial executable and start testing it for what you want to use it with.
Not sure when I’ll be able to finish the porting. This will require a careful comparison with the EAM pair style (on which it is based) to port over any bugfixes and also update the potential file parsing to use the custom potential file reader class and unit conversion that we support with the current LAMMPS version.
FYI, just pushed an update into the repo.
The code now runs in parallel and has all memory leaks fixed.
Also the parser for the potential file has been modernized.
The pair style requires that newton pair is set to on (the default), so a check to enforce this has been added.
FYI, between those versions (more specifically in commit 2cca3735154884865a034c008c5bca1f6c320a5c from Aug 6 2014)
there was a change in the pack/unpack functions for the forward communication:
The functions were renamed from Pair::pack_comm() to Pair::pack_forward_comm() and correspondingly from Pair::unpack_comm() to Pair::unpack_forward_comm(). Also the meaning of the return value changed, so those functions had to be updated for that as well.
This is corrected in my updated version. However, running with different numbers of processors still produces different results. So there is likely something still amiss. I suspect that this may be an issue with the pair style itself and not due to changes in LAMMPS.
Thank you very much for implementing this. I am excited to test it, but am running into some issues learning how to use the plug-ins.
I have compiled the most recent version of lammps with cmake and have also compiled and configured the lammps/lammps-plugins using your suggested code. I am currently not able to get the aeam pair style recognized in my example PE calculation script from earlier using the lmp executable. Does this script need to be modified to load the aeam plugin? I did not explicitly include the A-EAM source code in the src directory as before.
If you are able to share your current testing script, that would be helpful.
My test input was the bundled example input with just a few small modifications (commenting out commands with full paths, making the test system smaller and the test run shorter) because I set the environment variable. But you can also just add the plugin command as documented.
I was able to test two scripts of interest for disordered Al-Si structures (PE calc at 0 K and NVT anneal) and they both appear to give consistent results compared to the 2014 version for 1-8 cores. This is good news.
You mentioned that different numbers of processors led to different results – which output parameters were you considering?
Thanks again for the help with this – I believe my issues are resolved for now.
With two runs only the first line of the log file was identical. Then it would diverge (not for all cases, it would depend on the size of the subdomains). This hints that there is something not quite correct with the computation of forces, specifically those of ghost atoms that need to be communicated and accumulated with a reverse communication. I have not made some systematic tests or reviewed the compute function itself. To minimize the source of errors, I had switched from fix npt to fix nvt (so that pressure will not have an impact).
This would likely happen also with the version included into an older LAMMPS version.
I had one final question about your plug-ins package. I am trying to install it on a cluster where I typically compile lammps using the traditional gnu make option. On 4.9. Writing plugins — LAMMPS documentation, I read that “Compilation of the plugin(s) can be managed via both, CMake or traditional GNU makefiles”. Is the latter option possible in this case?
Yes, but you will have to write your own makefile or figure out the command lines. There are traditional makefiles in the “examples/plugins” folders. But I have no idea if they still work. I have not tried them in ages. For all new projects I plan to only support CMake.
This may be a good opportunity to switch to building with CMake throughout. I only use the traditional build system when somebody reports a problem, or to test new packages or similar things. For day-to-day development, it has far too many disadvantages and by now CMake should allow to build exactly the same executable for any system as the GNU make procedure (and then some that are not possible otherwise). Eventually, the traditional build will go away. Making everything compatible with two different systems is a lot of additional maintenance effort, and if the two won’t need to coexist, the CMake scripts could be significantly simplified.
The compilation process appears to go fine on the cluster I am using, but then when I try a test script with the plug in packages I get the following undefined symbol messages:
I do not see this problem on my laptop. On the cluster, I am loading modules including CMake version (3.20.4), a recent intel compiler and mpi-hpe. I know you don’t have enough information to reproduce this error, but please let me know if you have any suspicions. I can send more detailed information if needed.
This could happen if you have inconsistent compiler settings. That can be easily avoided by not compiling the extra pair style as a plugin but copying the sources into the LAMMPS source folder and compiling them with the executable.
The primary purpose of using plugins is twofold:
binary distribution: you can build and install plugins without having to build a modified LAMMPS executable; you can distribute software as a plugin when its license is incompatible with binary distribution included a GPLv2 software.
rapid development: you can modify and rebuild the plugin very fast without having to rebuild and relink the entire LAMMPS executable.
In your case neither really applies. The main benefit for you is that within the plugin source package you have updated sources that are compatible with the latest LAMMPS distribution.
