Increase box size and continue a run

By moving the lines. Put all the ions after the last SOL line.


Not if you just shift this block of lines down to the end of the coordinate file.

Thank you, this allowed me to appropriately adjust the system and write the ions.tpr file. I had assumed that I would then add the NA and CL lines from after genion to the original lines forming one line for each ion (as I had done with the SOL line) but this leads to an error. When I move to write the em.tpr file I get too many warnings -

(more than 20 non-matching atom names)
atom names from will be ignored
atom names from solv.ion.gro will be used

Is this just because I changed the topology and edited the solvated gro file? I see that I can overwrite this with -maxwarn, but am not sure if this is safe to do.

My advice is to never use -maxwarn. There is only one scenario in which it is useful but is otherwise a terrible idea.

Your coordinates and topology are in different orders, hence the mismatch. The full error message would be instructive (please always provide a complete error, copied and pasted from your terminal).

Apologies, the error is as follows:

I also inspected the gro file and am just not sure where I can find this numbering in the file, since it just has the number of NA and CL atoms under the number of SOL atoms. My confusion is basically on where to visualize the atom names in the topology file so that I can see exactly where the order is not agreeing. Line 52 is also just the number of CL atoms (which is the sum of the original ions and those added after genion).

When I rearrange the coordinate file, is it that I should also correct the numbering in the first column of the gro file? This was when I moved all ions below SOL in the gro file before genion. For example, if I moved atoms numbered 44012NA-59302CL to the bottom leaving a ‘gap’ in numbering in SOL.

Your ions are out of order. The order of molecules (and the number of each) in [molecules] must match the order of the molecules in the coordinate file. The individual numbering in the coordinate file is irrelevant. The order has to be the same. grompp expects sodium ions when it reaches atom 1575018 but it finds a chloride.

I now understand what this means and corrected this error in the gro file. I now have an error in energy minimization. There is another thread with a similar error but I was wondering if there were additional suggestions, or if you had additional feedback on them.

The error is:

Energy minimization has stopped because the force on at least one atom is not finite. This usually means atoms are overlapping. Modify the input coordinates to remove atom overlap or use soft-core potentials with the free energy code to avoid infinite forces. You could also be lucky that switching to double precision is sufficient to obtain finite forces.

Writing lowest energy coordinates.

Steepest Descents converged to machine precision in 15 steps,
but did not reach the requested Fmax < 500.
Potential Energy = 6.9141134e+18
Maximum force = inf on atom 98449
Norm of force = inf

No approaches received feedback from the other thread (posted below) and so I was wondering if there were additional suggestions to try.

Again, I greatly appreciate all of your guidance on this. It has been a great learning opportunity.


did you follow the steps outlined in that response? As noted in the error message and thread, an infinite force on an atom usually means that another atom has the same (or incredibly similar) position. This causes the 1/r^12 term in the Lennard-Jones potential to blow up since r is 0 (well, all 1/r terms will). Checking your configuration for atoms overlapping with atom #98449 may solve it.



I tried removing the atom since it is just a solvent molecule (in the gro file). But then I get the error:

Fatal error:
Invalid line in protein_edit.gro for atom 1594427:
21 21 21

Stopping at the line with the box size. I am also trying to see where the overlap is in vim - but am unsure of how to do so at the moment.

When I visualize, it appears that the new box is not perfectly aligned with the original. May this be contributing to the original?

Did you edit the number of atoms in the file (line #2) after removing the atoms? The message suggests to me that it is expecting to read more atoms than exist in the file, and thus expects the box size line to be for an atom.

Hello and thank you for your reply.

I did edit that as well. But because the atom overlapping (OW98449) is part of a water molecule (or so I think), it leads me to the error that the number of atoms in the topology and gro do not match. Then if I delete one SOL molecule from the topology there are 1594424 atoms, and 1594426 in the gro file. How can I determine which other atoms to delete from the gro file? I tried deleting 2 hydrogens (HW#) but then the lines are offset and atom names do not match between the topology and gro file (same error as above).

Molecules are whole in the .gro file. The OW atom is followed by its two bonded hydrogen atoms, they must all be deleted as a group.

Perfect! I understand now. And this worked perfectly for removing the first that overlapped. However, I get the same error for a different number atom that I cannot find in the gro file (when I search it in vim it is not found). Could this be an atom in the topology file and there is some mismatch between them still?

I know that I have to delete lost atoms, but cannot find a command to do so.

There isn’t a command. You delete lines using a text editor and update the atom count (and the topology). If you find yourself just chasing water molecules with bad contacts, it means you’ve done something wrong in building the system. A stray water or two sometimes happens, but usually going and deleting things is a poor idea for a fix because the problem lies elsewhere.

I have gone through the equilibration steps, but can I just run the new tpr file from the old checkpoint? Or I tried running just using -deffnm, but the error says I have to specify -s.

Thank you for your advice. I was able to fix the setup and equilibrate appropriately.

Your old system is irrelevant. The checkpoint file contains information about a totally different system. You’re running a new simulation.

I see, and I did get the output data. It still began at time 0ns. This means that I can never begin from the time where I left off, right? Even though I built the new gro file from an already running simulation.

Yes, as I’ve said a few times. You are starting a totally new simulation (because you are not preserving any velocities from the previous simulation), using only a previous starting configuration for a subset of the system (not the entire thing, because you’ve added solvent, ions, etc).