Hello all,.
Is there a way to restrain impropers during minimization using the fix restrain command. There only seems to be a way to fix linear dihedrals using the fix restrain however the minimization files that charm-gui built seems to suggest otherwise.
This minimization file continues to blow up on step 0 and the output is attached below with a atoms missing on proc * error. I am using the 12 Dec 2018 version of lammps. I have no idea what the cause of this error could be except that these atoms listed are in a Y configuration instead of linear like the documentation says they have to be. However the error documentation does not list this as a source of this error. Any help is appreciated I am pretty stuck.
Philip Skeps
Undergraduate
2nd Year
(612)-346-3663
output.6154951 (13 KB)
if you get the “atom missing” error on step 0, then there is nothing blowing up, but the initial geometry/definition is flawed. it means that atoms are not present on the individual subdomain.
some observations and suggestions:
- you are running a system with only ~15000 atoms across 36 CPU cores. that is pushing the limit. this is likely not going to be efficient. running with just 1 CPU will also avoid all “missing atoms” situations that are due to a too short communication cutoff. if things still go south after that, there may be more difficult to debug problems. but essentially, you need to build a test system that is so small, that you can verify all input manually.
- you have 72 individual fix restrain instances. that is very inefficient since each will need to do collective MPI communications across the entire system. it should be possible to define all restraints in just a single fix command.
- why don’t you define those restraints not just as regular impropers in the topology? just add one more improper type for the restraints and add the definitions to the Impropers section and same for the coeffs and the number of impropers in the data file header. if you want to turn those improper restraints off, just set their force constants to zero with an improper_coeff command
axel.
Hey Axel,
Thanks a ton, changing to one CPU fixed the error, I’m glad nothing else was extremely broken!
I will also apply your other recommendations
Thanks for all the help,
Philip Skeps
Undergraduate
2nd Year
(612)-346-3663
It didn’t fix the problem. It just avoided the symptom. You still need to find out why those dihedral definitions span over a longer distance than the communication cutoff. That is rather unusual.
So your simulation may still be bogus, just in a way that doesn’t crash immediately.
Axel
Hey Axel,
Could it be my simulation box is too small. Maybe with periodic conditions my dihedral is spanning the entire cell? Would this be something to look into?
Philip Skeps
Undergraduate
2nd Year
(612)-346-3663
the size of the simulation box is irrelevant for this. the communication cutoff matters. as you can see from your output, it is 14 angstrom for your simulation.
that means the 4 atoms of your dihedral restraints would have to span more than 14 angstrom. even if you had 4 atoms in a straight line, they would have to be over 4.5 angstrom apart. that is very unusual. typical single bonds are around 1.5 angstrom, double bonds shorter. so there is a good chance that your choice of indices is incorrect.
if you look at the output and eliminate the ones listed multiple times, that makes (at least) 6 of the 72 restraints.
BTW: is there a particular reason you use the “newton off” setting?
axel.
the size of the simulation box is irrelevant for this. the communication cutoff matters. as you can see from your output, it is 14 angstrom for your simulation.
that means the 4 atoms of your dihedral restraints would have to span more than 14 angstrom. even if you had 4 atoms in a straight line, they would have to be over 4.5 angstrom apart. that is very unusual. typical single bonds are around 1.5 angstrom, double bonds shorter. so there is a good chance that your choice of indices is incorrect.
if you look at the output and eliminate the ones listed multiple times, that makes (at least) 6 of the 72 restraints.
and those are the ones extending longer than the communication cutoff. others can still have very long bonds but just don’t quite extend as much.
axel.
Hey Axel,
I noticed that if a different amount of nodes were used during the simulation, different dihedrals would be lost. What significance could this have?
Philip Skeps
Undergraduate
2nd Year
(612)-346-3663
It is only a consequence of domain decomposition and it has the same implications as not missing atoms with just one CPU. Your question indicates that you need to spend more time learning about LAMMPS’ basic methods. As discussed in the manual and in more detail in the LAMMPS paper.
Axel
Hey Axel,
Ill for sure do that as that was a section of the documentation I only glanced over. Using topo tools I inspected the original data file. Everything appears in order i.e no bonds are extremely long. I also checked to make sure that the restrained dihedrals that were throwing errors had the correct atom types listed. If the simulation never makes it to timestep 1 it means that there has to be something wrong with the initial configuration however the initial configuration does not look incorrect. What other checks should I make to help fix my initial structure?
Thanks,
Philip Skeps
Undergraduate
2nd Year
(612)-346-3663
Please note that VMD has 0 based indexing, while LAMMPS (and CHARMM) use 1 based indices.
We are now getting deep into territory that has nothing to do with LAMMPS but basic training in simulations and using software which is outside the scope of this mailing list and something you need to ask your adviser or senior group members for assistance about.
I think we have now clearly established that the problem is due to bad input. Whether you believe it or not is not my concern.
Axel
Thanks Axel,
This has been very informative and sadly this mailing list is the only help I receive as the group I am working with has even less experience than me. I just built a new topology file which seems to be working but I will run more diagnostics on it. Sorry if my lack of knowledge has been frustrating for you.
Thanks Again!
Philip Skeps
Undergraduate
2nd Year
(612)-346-3663
Hey Axel,
You are a hundred percent right, I will continue to reach out to find a suitable mentor as I really want to become an expert in the field.
Philip Skeps
Undergraduate
2nd Year
(612)-346-3663