-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VdW table too large ERROR #14
Comments
Let me find more specifically what's exactly promoting the error. |
It turns out that the clash is between the parameterize ligand and c36_mod.
|
Firstly, that should have terminated at the "VDW table too large" error. Did it continue past that point, or did you edit down the # of parameters and try again? |
Attached files to generate the error and the outputs. |
To update, it seems the warnings aren't causing the error. Also, it seems independent of the forcefield in this second case, as the old c36 also produced the VdW table too large error. |
It is actually a very reproducible error every time I have two large ligands, a membrane, a protein, water and ions. To me it seems something related to having too many atomtype definitions and the way acemd handles that. I have tried all the possible parameterize-cgenff combinations for the two ligands and only removing one of the two (independently of which one) solves the problem. So it seems indeed something related to the amount of atom-types. It is a rather important issue I think, as it impedes running simulations with agonists and partial agonists at the same time. |
Yes, charmm has lots of atom types, too many for a particular fixed size
|
Hi Matt, Thanks for your reply. Did you fix this yesterday in the end? Thanks, |
Hi Noelia Turns out it's not a straightforward fix. The table is as large as the GPU
|
Many thanks Matt. |
Partially fixed in the next acemd version. |
I have a similar situation. Simulations crash with the "VDW table too large" error when running in GPUGRID. But I ran a similar system not too long ago and worked perfectly. In that case we had 306 atomtypes and in the current simulations we have 299 atomtypes.... how does the VDW table get created? |
Actually it only keeps the atom types that are in the system you simulate and these are hard-coded to 54. You have 78 In [2]: mol = Molecule('./Downloads/system.psf')
In [3]: mol.atomtype
Out[3]: array(['CT3', 'HA3', 'HA3', ..., 'CLA', 'CLA', 'CLA'], dtype=object)
In [4]: np.unique(mol.atomtype)
Out[4]:
array(['C', 'CA', 'CAI', 'CC', 'CEL1', 'CG2O5', 'CG2R61', 'CG301', 'CG314',
'CG321', 'CG331', 'CG334', 'CL', 'CLA', 'CP1', 'CP2', 'CP3', 'CPH1',
'CPH2', 'CPT', 'CRL1', 'CRL2', 'CT1', 'CT2', 'CT2A', 'CT3', 'CTL1',
'CTL2', 'CTL3', 'CTL5', 'CY', 'H', 'HA1', 'HA2', 'HA3', 'HAL1',
'HAL2', 'HAL3', 'HB1', 'HB2', 'HC', 'HEL1', 'HGA1', 'HGA2', 'HGA3',
'HGP2', 'HGR61', 'HL', 'HOL', 'HP', 'HR1', 'HR3', 'HS', 'HT', 'N',
'NC2', 'NG3P1', 'NH1', 'NH2', 'NH3', 'NR1', 'NR2', 'NTL', 'NY', 'O',
'O2L', 'OBL', 'OC', 'OG2D3', 'OH1', 'OHL', 'OSL', 'OSLP', 'OT',
'PL', 'S', 'SM', 'SOD'], dtype=object)
In [5]: len(np.unique(mol.atomtype))
Out[5]: 78 |
Just for the record, a recent similar system that I simulated had 82 atomtypes (when calculating it using the same protocol) so there must be something else wrong... |
My bad, it also joins atomtypes which have same LJ parameters. In which case I cannot calculate now by hand how many are left |
Hi guys,
I have a system with two ligands. 1 of them parameterized with cgenff latest version through command line the other with parameterize. It's basically running a simulation of pdb file 4MQT.
I run this system with both par/par_all36_prot.prm and par/par_all36_prot_mod.prm.
It turns that the first works straight away the second cannot find atomtype xxxx. which is found in the cgenff ligand.
Let me know if you need all the files.
best
N
The text was updated successfully, but these errors were encountered: