Compatibility of Qeq methods with GCMC or atom/swap

Is it possible to use the new GCMC or atom/swap fixes with the Qeq Methods implemented in LAMMPS? I could imagine that there are problems with the charge equilibration method when molecules are added, since then, if the full_energy option is used, the charges have to be readjusted or perhaps added molecules will even have no charge. Is the charge equilibration invoked after/with every MC step?

Regards
Robert

Is it possible to use the new GCMC or atom/swap fixes with the Qeq Methods implemented in LAMMPS? I could imagine that there are problems with the charge equilibration method when molecules are added, since then, if the full_energy option is used, the charges have to be readjusted or perhaps added molecules will even have no charge. Is the charge equilibration invoked after/with every MC step?

i don't know for certain, but this would be something that could be
easily answered empirically by constructing and running a small test
system and perhaps using an executable with a few strategic print
statements added. :wink:

axel.

Robert,
Although I am not going to answer directly your question because I don’t know if lammps allows for that, I would like to provide some comment for you to consider. I have used and implemented several of the QEq & Co approaches in the past but I wonder how effective can they be in the context of GCMC simulations. Many of these methods have built-in shielded Coulombic interactions via Slater orbitals or gaussian orbitals or any other scheme one can choose to eliminate the 1/r singularity at the origin that arises from the Coulomb potential and proves to be highly problematic when atoms get very close. I wonder thus how numerically stable these methods are in the context of GCMC when one is generating configs that include overlapping atoms all the time. Perhaps the QEq & Co won’t even converge regularly in this framework. I have never tried this type of simulations myself but that is a hunch I have.
Carlos

I haven't tried using the GCMC or atom/swap fixes with Qeq methods. It might just work when using the full_energy option, but you'd need to do your own verification testing to make sure you get something useful out.

Note that in the current version of fix GCMC with the full_energy option, "pre_force" is called every MC step, which I think should invoke the necessary charge equilibration machinery in fix qeq. The current version of fix atom/swap with the full_energy option does not include a call to "pre_force", so it looks like there would be no charge equilibration there on the MC steps.

Ray may wish to comment on the Qeq aspects.

Paul

Yes, fix qeq should be invoked before each MD step (after MC steps have finished), but a small test is needed to confirm this.

There is no conceptual problem of using GCMC with QEq together. In the current implementation, charge equilibration would only be called after MC steps have finished. If qeq does not converge, this just indicates some configurational problems like Carlos mentioned.

Note in a hybrid MC/MD simulation, you would need a smaller-than-usual timestep. Therefor it does not surprise me if you need a tighter-than-usual tolerance for fix qeq in a hybrid MC/MD+QEq simulation.

Ray

With the latest version of GCMC with the full_energy option, I think that Qeq would get called during the MC steps as well as the MD steps. Carlos may be right that this could cause some strange behavior if GCMC tries to put atoms of top of each other and Qeq can’t converge.

Paul

I would have guessed that the atom/swap will return an error because in the manual it is written

This fix checks to ensure all atoms of the given types have the same atomic charge. LAMMPS doesn’t enforce this in general, but it is needed for this fix to simplify the swapping procedure. Successful swaps will swap the atom type and charge of the swapped atoms.

However, when used during the run no error is produced and swaps are executed. Only at the end, when a data file of the final structure should be written out, the following error is written:

write_data final.data

ERROR: All atoms of a swapped type must have the same charge. (…/fix_atom_swap.cpp:238)

Shouldn’t appear the message earlier?

I also made the experience that in combination with fix deposit the routine will produce a segmentation fault. However, when I pre fill the box with deposit using the near keyword but without a time integrator, write out a data file and start from this data file everything works fine. I see for the hybrid nvt/deposit case a lot of nans for the charge in the trajectory although I recalculate charges with fix qeq every time step.

Actually this is not a mail where I’m asking for help, I just wrote down my experience with Qeq and MC methods. However, I would be pleased to discuss this further since I think the MC methods implemented in LAMMPS are a powerful tool. Especially, because they can be used in combination with many-body potentials.

Regards

Robert

That error message should show up right when fix atom/swap is initialized, unless all atoms of each of the given types happen to have the same atomic charges at the beginning of the run, which may be the case here. What may be happening is that the charges start out the same for all atoms of a given type, are then recalculated with fix qeq, and then the check happens again when you write your data file, triggering the error message.

Paul