ERROR on proc 0: Non-numeric atom coords - simulation unstable (../domain.cpp:551)

LAMMPS LAMMPS General Discussion
, ,
1

Dear Lammps Developer and users,
I am writing to you today to express my concern about the Non-numeric atom coords error that I am encountering when applying external electric field in reaxff.

I have been working with different electric field intensities, and the system responds to some of the efield, while gives the Non-numeric errors for others. The only difference in all the input scripts is just the efield magnitude value.

I am considering that there isn’t any problem with the geometry because I’m running the delete overlap command as well. No atoms were deleted. So the system working for few magnitudes and not having any atoms overlapping, what can be the issue ?

I am concerned that this error may be preventing me from accurately simulating the effects of external electric field on my system. I would be grateful if you could provide any suggestions on how to troubleshoot this issue.

Thank you for your time and consideration.

2

This probably means your simulation exploded due to bad dynamics. First I would double check your units of the electric field.

3

This is my efield command in input script, I’m only changing the magnitude of z direction. Here it is 25MeV/cm. It doesn’t work. For 5, 10, 20 MeV/cm, I’m not having any issues.

fix 3 efieldapply efield 0.0 0.0 5.755 region efieldarea # conversion 0.2302*MeV/cm ## Change This ##

4

That’s 575.5 MV/cm (MeV/cm isn’t a unit of electric field).

5

But according to the fix_qeq_reaxff.cpp, the MeV/cm is suppose to be converted to kcal/mol/Angstrom.

image
image1358×306 15 KB

And the reaxff_defs.h states that following about conversion rule:
image
image1166×107 5 KB

Isn’t reaxff using different unit for efield ?
I’m currently replicating the simulations of H. DorMohammadi et al. / Computational Materials Science 145 (2018) 126–133 in “Atomistic simulation of initial stages of iron corrosion in pure water
using reactive molecular dynamics”.
Can you help with this ?

6

That’s a (very poorly) written comment about how the code works internally (I should know, because I worked on this very function recently), and not about how the end-user is meant to interact with the code.

Efield internal conversions

Lines like lammps/src/fix_efield.cpp at dc3c8da52b3ee985cac04f5b8c908d8b2dcebf0a · lammps/lammps · GitHub or the function starting lammps/src/fix_efield.cpp at dc3c8da52b3ee985cac04f5b8c908d8b2dcebf0a · lammps/lammps · GitHub show that we expect the user to supply electric fields in electric field units, but that they are then internally stored in force-per-charge units using qe2f – thus for real or metal electric fields are input as V/angstrom and stored as kcal/mol-e-angstrom. ReaxFF expects potentials in V (implicitly; explicitly it stores all energies as eV and charges as e), so values from efield are “back-converted” in the code you’re looking at. This is all about internal representations, not user input expectations.

The documentation for fix efield clearly states to supply the electric field corresponding to the units setting, which is volts per angstrom for both real and metal. LAMMPS does many unit conversions on the back end to make that work.

2 Likes
7

Thank you for the clarity. So for confirming, if I want to create a effect of 25MeV/cm, what should be my input magnitude in V/angstrom ? Since former is energy and the later is charge.
The attached image is from the paper that I’m using as a source.

image
image458×524 141 KB

8

Again, MeV/cm is a unit of force, not electric field. You will have to find out whether the authors actually meant MV/cm, and you should be able to replicate their results qualitatively (for example simulating 10, 15, and 20 MV/cm, maybe using fewer Ni layers and a smaller simulation box to speed up your simulations).

Straightforwardly, 1 MV/cm = 1e8 V/m = 1e-2 V/angstrom. You should double-check this calculation for yourself.

2 Likes
9

Thank you for all the information. I will start working on this.

10

@srtee, thanks for the guidance. The system is now behaving as it should be.

1 Like