Energies are not converging during minimization.

[Dawson Bell]

Hello,

I am attempting to equilibrate a box of 60x60x60 angstrom box of 7218 water molecules, first under nvt conditions, and then subsequently npt. The water box was generated using packmol and converted to a lammps.data file using the topotools plugin for VMD.

I submitted the job to a single node with 48 CPU cores, and after approximately 30 minutes of no intermediate output to the log.lammps file, it results in a system with gargantuan forces and pressures:

   Step         TotEng         Press
         0  -8.3552487e+55  1.0271258e+57
         1  -1.5852713e+56  1.9659323e+57
         2  -3.2093269e+56  4.0150924e+57
         3  -6.7921653e+56  8.5698929e+57
         4  -1.4767043e+57  1.8784095e+58
         5  -3.2624155e+57  4.1825143e+58
         6  -7.2810315e+57  9.4064069e+58
         7  -2.5294388e+58  3.3008025e+59
         8  -2.6697095e+58  3.4856097e+59
         9  -2.6877754e+58  3.509418e+59
        10  -2.6900421e+58  3.5124053e+59
        11  -2.6901838e+58  3.5125921e+59

Minimization stats:
  Stopping criterion = energy tolerance
  Energy initial, next-to-last, final =
    -8.35524870447692e+55 -2.69004207400907e+58 -2.6901838063289e+58
  Force two-norm initial, final = 2.282563e+56 9.8568417e+58
  Force max component initial, final = 1.0385368e+56 4.1838434e+58
  Final line search alpha, max atom move = 1.4589057e-64 6.1038331e-06
  Iterations, force evaluations = 11 49

I am new to using both MBX and LAMMPS, so I have no doubt that there is some problem with my input files, but I cannot seem to figure out what. I have already tried changing minimization parameters and MPI/OpenMP configuration, as well as regenerating my .data file from scratch. I am not sure what to try next. Any advice would be greatly appreciated.

Best,

Dawson

[Ethan Bull-Vulpe]

Hi Dawson,

Thanks for sending your input files, with them I was able to reproduce your results.

I took a peek at your waterbox.data file, and I noticed that atoms near the boundaries are often very close to atoms on the other side of the boundary. For example, see this water molecule that appears to have 3 hydrogens:

One of these hydrogens belongs to a water molecule on the other side of the box. Because these two water molecules are so close, the 2b and 3b PIPs make a large and random prediction.

I would suggest leaving a little buffer when using packmol, if your box size is 60x60x60, maybe only put atoms inside 58x58x58, and then during equilibration molecules will fill in the gap around the edges of the box.

-Ethan

[Henry Agnew]

Dear Dawson,

         I have some additional things to mention.

1. For Packmol, I would additionally looking into the "pbc" command https://m3g.github.io/packmol/userguide.shtml#pbc. This will allow packmol to take into account the periodicity when packing.
2. I see in your log.lammps that it only is using a single core. If you aren't already, make sure to use `export OMP_NUM_THREADS=48` or something similar if you want to use more cores.
3. You appear to be missing the line `compute mbx all pair mbx` in your input. This is required for your simulation to progress.

Good luck on your minimization, and let us know if there are any more issues!

-Henry

[Dawson Bell]

Hello Ethan, Henry,

I appreciate you both taking the time to look through my input files and identify potential problems. I believe you are correct, that my problem lies within my initial .data configuration, however I have still not been able to perform a successful minimization after quite a bit of playing. My first step was to regenerate the waterbox.data file using the box boundaries and the Packmol "pbc" command, as you both suggested. I ensured that there were no more problems with incorrectly bonded atoms. I was also sure to include the "compute mbx all pair mbx" command in my input script, as Henry pointed out.

Furthermore, I used the same initial water molecule geometry given in the Packmol tutorial, to rule out issues with individual water molecules. When I converted from a .pdb to a .data file, I used the "topo guessangles" command in VMD to add angles to the file, since that information was included in the .data file from the MBX tutorials folder. Finally, I noticed that my box dimensions were set incorrectly in my mbx.json file, which I've now fixed.

After taking all of these steps, my simulation is now failing differently than before. Before, the energy minimization would go to completion, but would result in unreasonably high forces that would cause the job to hang during the nvt step. Now, the job fails nearly immediately with the following error message:

"Exception: ** ERROR ** C++ Exception in function CalculateDipolesConjugateGradientMPIlocal, in line 3178 of file .../lammps/build_cpu/mbx_build-prefix/src/mbx_build/src/potential/electrostatics/electrostatics.cpp. Max number of iterations reached"

I haven't been able to find any references to this error message in this forum or elsewhere. Simply increasing "dipole_max_it" in mbx.json does not bypass this problem. Let me know if either of you have run into it before, and if the cause is still likely to be coming from a bad initial configuration.

Thank you again for the help,

Dawson

[Ethan Bull-Vulpe]

Hi Dawson,

I was able to reproduce the error, and traced it back to a problem in the ordering of the atoms in the waterbox.data file. MBX requires that the order of atoms in the .data file be the same as the order of atoms within an MBX monomer type. For water, this means the atom order must be O H H, but in waterbox.data the order is H H O. We should probably check for this on launch and print a helpful error message, as we already do for a number of other invalid inputs. Try changing the atom order to O H H (including the order of the atom IDs) and let us know if it works then. When I do that, I can run your minimization.

Also, for LAMMPS simulations, the box comes from the .data file and the one in the .json is ignored, so there is no need to put the box in the .json file and it is best practices not to.

-Ethan

[Partha Dash]

Hi Dawson,

The dipole convergence error you're now hitting is a strong sign that the initial configuration still has molecules too close together, the induced-dipole CG solver can't converge when the electrostatic environment is unphysical. Increasing dipole_max_it won't help if the geometry itself is bad.

I’ve been working something similar recently and put together a tool that might save you some time:

https://github.com/Partha-debug/mbx-slab-prep

It automates the full preparation pipeline including packing with Packmol using the pbc command (as Ethan and Henry suggested), writing a correctly formatted atom_style full LAMMPS data file with the right MB-pol charges and masses, generating a consistent mbx.json with correct box dimensions, and producing a ready-to-run in.equil.lammps. It also enforces a minimum O-O distance of 2.0 Å under full 3D periodic boundary conditions before writing out the files, which should prevent the kind of close-contact issue that was causing your original problem.

The README has all the documentation you need to get started.

Hope it helps, and let me know if you run into any issues with it.

Best,
Partha

On Mon, Mar 16, 2026 at 7:32 PM Dawson Bell <dawso...@u.boisestate.edu> wrote:

Hello Ethan, Henry, I appreciate you both taking the time to look through my input files and identify potential problems. I believe you are correct, that my problem lies within my initial .data configuration, however I have still not been able

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

--
You received this message because you are subscribed to the Google Groups "MBX-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mbx-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/mbx-users/f5184bc7-0757-478d-aa35-d079885186d5n%40googlegroups.com.

[Dawson Bell]

Hello all,

After changing the atom ordering in the .data file, everything seems to be working and I was able to run an NVT equilibration. Thank you, Ethan and Henry, for your advice, and thank you Partha for sharing the helpful tool; I'll be sure to try it out to avoid any headaches in the future!

For anyone having similar problems that finds this thread in the future, I've attached my functioning input files for you to reference, including my packmol input file and starting water molecule geometry (water.pdb).

Thank you all again!

Best,

Dawson