@jalemkul After removing only those quadruplets from the lig.prm which have also been defined in the ffbonded.itp, I could move past this hurdle.
But another anomaly creeped in during the energy minimization step. I had faced this earlier too while using the Jul-2021 version of charmm36.
@Mikel led me to another similar issue. I tried reducing the em_step size, increase the box dimensions but in vain. I’m still trying out other ways to work around this issue.
@jalemkul There’s another system for which I was trying to run a MD simulation yesterday. I faced the same error as before…non-convergence of Fmax in the energy minimization step. I have faced the same error every time I tried to use the Jul2021 version of the charmm36 force field.
Here is the em.mdp file I used.
title = Minimization ; Title of run
; Parameters describing what to do, when to stop and what to save
integrator = steep ; Algorithm (steep = steepest descent minimization)
emtol = 1000.0 ; Stop minimization when the maximum force < 10.0 kJ/mol
emstep = 0.01 ; Energy step size
nsteps = 50000 ; Maximum number of (minimization) steps to perform
; Parameters describing how to find the neighbors of each atom and how to calculate the interactions
nstlist = 1 ; Frequency to update the neighbor list and long range forces
cutoff-scheme = Verlet
ns_type = grid ; Method to determine neighbor list (simple, grid)
rlist = 1.2 ; Cut-off for making neighbor list (short range forces)
coulombtype = PME ; Treatment of long range electrostatic interactions
rcoulomb = 1.2 ; long range electrostatic cut-off
vdwtype = cutoff
vdw-modifier = force-switch
rvdw-switch = 1.0
rvdw = 1.2 ; long range Van der Waals cut-off
pbc = xyz ; Periodic Boundary Conditions
DispCorr = no
I tried changing the step size and even the integration method. No luck so far.
I eagerly look forward to any experienced views.
Regards
Hemant
@heman_t this is a new problem, please start a new discussion rather than adding unrelated topics to this one.
@jalemkul Sir, I am having the same error with my unk.itp file while generating ions.tpr. I am using charmm36-july22 version and the cgenff version is 4.6. Can you please help what is the solution ?
Sorry for bringing this discussion up again, but I also get the “No default Proper Dih. types”, but in my case it is not a mistake on my part. I purposefully do not want some dihedral angles to be included in my topology (which is why gromacs cannot find them). Not to deter the discussion into whether what I am doing is “illegal”, let’s just say I need to have a very non-standard metallocofactor in my protein held with nothing else but bond forces and a couple of angles (no dihedrals). In NAMD it was super easy to do, I just write a short patch in the topology file that can be applied to participating residues deleting parasitic protons, making right bonds. The best part was, user is in a full control of what is going on, no black boxes. In the gromacs environment, I really cannot find a systematic way of doing something similar without poring hours/days of manual labor into the project. Short of writing my own pdb2gmx-like program, the best solution I could come up with was to treat metallocofactor as a ligand, create a topology file by adding my special bonds into the specbonds.dat and run pdb2gmx with “-merge all”. The problem is pdb2gmx generates heaps of angles and dihedrals that I really don’t want nor have force fields for. So, my question is, how can I control what extra angles/dihedrals pdb2gmx generates?
Any help would be appreciated here.