VdW table too large ERROR about htmd

[noeliaferruz]

Let me find more specifically what's exactly promoting the error.

[noeliaferruz]

It turns out that the clash is between the parameterize ligand and c36_mod.
The system which uses c36 runs in ACEMD.
The system which uses c36_mod produces this output: (let me know if you need files)

ERROR: file mapmdx.cpp line 751: VDW table too large
[...]
# - 
# SWAN device 0 is NVML device 2 with PCI-ID 0000:08:00.0 and serial [0321215002520] 
# NVML : 0 : PCI Width 16x/16x   Speed 3/3
# NVML : 0 : Fan 0%  Temp 27C    Mem Used 123MB Free 12164MB Total 12287MB
# NVML : 0 : Performance state 0
# NVML : 0 : Power 26.64W 
# NVML : 0 : Load 0 GPU 0 Mem 
# Configuration [Tesla K80] [370] [Linux]
#
#WARNING: warning: Conflict in redefined improper parameters for i crn1 nrn2 nrn2 nrc4
#WARNING: warning: Conflict in redefined improper parameters for i nrn2 hrm2 hrm2 crn1
#WARNING: warning: Conflict in redefined improper parameters for i crn1 nrn2 nrc4 nrn1
#WARNING: warning: Conflict in redefined improper parameters for i nrn1 cr33 crn1 hrm1
#WARNING: warning: Conflict in redefined improper parameters for i crn1 nrc4 nrn2 nrn1
#WARNING: warning: Conflict in redefined improper parameters for i nrn1 ct2 crn1 hrm1
# Topology reports 59246 atoms
# -  There are 3 long-range exceptions
# VDW table size 52

[mj-harvey]

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?
Secondly, you should see those 6 improper terms in the parameter. The error indicates that they are present multiple times, and with different values. The impropers don't get reparameterised, this must be a change between differing versions of ffs being used.
Could you show them to me, please?

[noeliaferruz]

1. I copied literally the output I got. I just removed the [...] part containing the license information.
2. Right.

Attached files to generate the error and the outputs.
files.zip

[noeliaferruz]

To update, it seems the warnings aren't causing the error.
I just run another simulation with an exact setup and although the warnings were there the error didn't raise and the simulation run.

Also, it seems independent of the forcefield in this second case, as the old c36 also produced the VdW table too large error.

[noeliaferruz]

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.

[mj-harvey]

Yes, charmm has lots of atom types, too many for a particular fixed size
data table within acemd. The good news is it should be easy to expand it.
Will try to fix it tomorrow
On 17 Apr 2016 20:04, "Noelia Ferruz" [email protected] wrote:

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 bug I think, as it impedes running
simulations with agonists and partial agonists at the same time.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#14 (comment)

[noeliaferruz]

Hi Matt,

Thanks for your reply. Did you fix this yesterday in the end?
If so, let me know and I might try to update acemd -if you tell me how-. This issue is currently hampering an important project.

Thanks,
Noelia

[mj-harvey]

Hi Noelia

Turns out it's not a straightforward fix. The table is as large as the GPU
memory it inhabits permits. I'm working on some additional code changes to
accommodate the modification. I hope to have something for you tomorrow at
the latest. I will send you an acemd by email
On 19 Apr 2016 15:37, "Noelia Ferruz" [email protected] wrote:

Hi Matt,

Thanks for your reply. Did you fix this yesterday in the end?
If so, let me know and I might try to update acemd -if you tell me how-.
This issue is currently hampering an important project.

Thanks,
Noelia

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#14 (comment)

[noeliaferruz]

Many thanks Matt.

[giadefa]

Partially fixed in the next acemd version.

[GerardBCN]

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?

[stefdoerr]

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

[GerardBCN]

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...

[stefdoerr]

My bad, it also joins atomtypes which have same LJ parameters. In which case I cannot calculate now by hand how many are left