[lammps-users] Making a fix work with USER-INTEL

Dear all,

In my continuing work on updating the constant potential plugin for LAMMPS, I have found that my fix behaves very differently when running a system with USER-INTEL, and I was wondering if anyone here would have general hints for where to look for a bug or unwanted interaction.

What the fix does during a run is to total up the electrostatic potential on a list of electrode atoms, and then do some linear algebra to determine the charge that equalises them and set the charges accordingly. But in my test runs with an ionic liquid-type system (with lj/cut/coul/long/intel, pppm/intel, and fix shake rigid molecules) the plug-in gives much lower charge values than it should.

My first guess to work on is that it isn’t reading in lists like atom->x and atom->q correctly — but I can’t see why from the USER-INTEL code that would happen. (My fix is already asking for the separate half / newton off neighbour list that it needs.) Might there also possibly be a problem in reading in the Coulomb cutoff from lj/cut/coul/long/intel?

Thanks in advance for any suggestions, or any previous experience of things like this happening with other fixes and USER-INTEL. I’ve already emailed Michael Brown separately asking for help, but I thought I would also try this group to see if anyone had any advice. Let me know if there’s a better place for these developer-type questions.

All the best,

it is rather difficult to give advice based on such limited and vague information.
please make certain that you are working with the latest development sources of LAMMPS so that you are not missing out on any bugfixes. please also note that some of the lesser used functionality of regular styles is not available in USER-INTEL styles. please also note that both, USER-INTEL and USER-OMP hold data like computed forces in per-thread data and only reduce that information across threads when needed (typically after the force computation is completed or when the last multi-threaded force computation is executed)

without knowing what your plugin does and how it is impossible to comment on how to avoid issues with that.


Hi Axel,

I can certainly give a lot of information after tinkering over the day (see below) but my current suspicion is that the fix fails to update charge properly. The important part is that during pre_force it sets a bunch of charges by looping over atom->q[i] = calculated_value, and I think the buffering of q[i] into subsequent force calculations has problems (see below for detailed reasoning).

Is there any precision limitation or format difference (such as double vs float) or other potential issues with trying to use USER-INTEL with per-step-updating charges?

Thanks! Lots of details follow.


Hi Shern,

USER-INTEL only updates the charge buffers it uses on neighbor build steps. As a temporary workaround, you can change the code for IntelBuffers::thr_pack() (intel_buffers.h):

  • if (ago == 0) {
  • if (true) {

and we can discuss more permanent options in the separate e-mail thread you have sent after I have more time to review (apologies – just got back from vacation so didn’t read all of your details).

Best, - Mike

Hi Michael,

That’s absolutely solved it – and with the unmodified USER-INTEL code, forcing reneighboring every step with “neigh_modify every 1 delay 0” also brings the normal LAMMPS and USER-INTEL in line with each other.

Thanks so very much!!

All the best,