Re: CHARMM-c36, glycans and RATTLE

From: Sunhwan Jo (
Date: Thu Aug 15 2013 - 09:31:26 CDT

Dear Tristan,

I remember I have communicated with Dr. MacKerell a while ago about missing parameter for N-terminal patch.

CT2 CT2A CT1 CD 0.2000 3 0.00

He suggested to use this parameter, which, I believe, is manifested from older FF. I think terminal residues are somewhat overlooked in c22 -> c36 transition.


On Aug 15, 2013, at 4:13 AM, Tristan Croll <<>> wrote:

Hi all,

Finding the problem with the CHARMM-c36 parameter file turned out to be a little more difficult than expected. Glutamic acid residues now contain a new atom type, CT2A. It seems that the c36 forcefield has yet to be tested with an N-terminal GLU, because the dihedral parameters for NH3 Ė CT1 Ė CT2A Ė CT2 donít exist. Easy fix on my part: since that N-terminus is unstructured anyway I just deleted that residue, and now everything is running fine. I guess Iíll send a note to the MacKerell lab tomorrow.



From:<> [<>] On Behalf Of Tristan Croll
Sent: Thursday, 15 August 2013 4:24 PM
To: Sunhwan Jo
Subject: RE: namd-l: CHARMM-c36, glycans and RATTLE

Hmm Ė I guess Iíll go back and work out the details of why the all36-prot files werenít working (undoubtedly just a few more lines need to be commented out). Incidentally (and somewhat embarrassingly) my simulation now (finally!) seems to be stably running at a 2fs timestep.

Anyway, thanks for the reality check.


From: Sunhwan Jo [<>]
Sent: Thursday, 15 August 2013 4:10 PM
To: Tristan Croll
Subject: Re: namd-l: CHARMM-c36, glycans and RATTLE

I used all36 for both protein and carbohydrates.


On Aug 15, 2013, at 1:05 AM, Tristan Croll <<>>

Hi Sunhwan,

Other than the change of forcefields, these constructs were built using a psfgen script essentially identical to that which I used to build structures that have run flawlessly for hundreds of nanoseconds. I understand the problem with missing angles and dihedrals (Iíve accidentally failed to add them myself before) Ė but usually this is obvious once you inspect the resulting trajectory. Here everything looks fine Ė it just keeps crashing out at a 2fs timestep.

Anyway, itís certainly concerning that youíve had not trouble here. I guess I should go back and check whether it will run stably at the longer timestep now that the systemís equilibrated for 1ns or so. Were you using the all36 or all22 protein files?



From: Sunhwan Jo [<>]
Sent: Thursday, 15 August 2013 3:53 PM
To: Tristan Croll
Subject: Re: namd-l: CHARMM-c36, glycans and RATTLE


I have no idea what is the problem here. I have ran simulation of glycoprotein with C36 CHARMM FF / 2fs time step before without any problem. I used c36 protein / c36 glycan force field at the time.

Again, this is pure speculation, but you may want to double check if your angles and dihedrals are all correctly setup after patch glycans together and glycans to protein side chain. I used CHARMM to prepare PSF, but I've once made a mistake and angles were not properly introduced into PSF after patching.


On Aug 14, 2013, at 11:50 PM, Tristan Croll <<>> wrote:

Hi all,

Iíve been running simulations of a glycosylated protein for some time now using the (relatively) new CHARMM glycan topologies and parameters. To date, I was using these in combination with the NAMD-supplied top/par-all27-prot-lipid-na files which, while everything seemed fine, always worried me slightly regarding a potential mismatch in forces.

In any case, I decided to upgrade to the final CHARMM-c36 release which includes the glycans as part of the official package. The strange thing is that now, in an otherwise perfectly vanilla explicit solvent simulation, my glycan atoms keep failing the RATTLE algorithm at a 2fs timestep. At 1fs everything seems fine Ė stable simulation, normal-looking glycan conformation with no strangeness in bond lengths or angles and no extreme movements. Just wondering if anyone has any ideas?

My protein/glycan structure is built against the following three topology files:
top_all22_prot.rtf -- included in the c36 package; the CHARMM documentation seems to recommend using this rather than top_all36_prot.rtf for NAMD, and my simulations crash when I try to use the latter

The simulations are run using:

I did use VMDís solvate and ionize plugins to add water and ions, which of course uses the topology file included in the NAMD distribution. I donít think this is likely to be causing the problem, though.

As I said, the simulation seems stable at 1fs timesteps. Of course, this slows me down Ė but Iím more concerned that thereís some error here that Iím not seeing, and donít want to waste a million CPU-hours on a production run without checking first. Does anyone have any ideas?



Tristan Croll
Faculty of Health
Institute of Health and Biomedical Engineering
Queensland University of Technology
60 Musk Ave
Kelvin Grove QLD 4059 Australia
+61 7 3138 6443

This email and its attachments (if any) contain confidential information intended for use by the addressee and may be privileged. We do not waive any confidentiality, privilege or copyright associated with the email or the attachments. If you are not the intended addressee, you must not use, transmit, disclose or copy the email or any attachments. If you receive this email by mistake, please notify the sender immediately and delete the original email.

This archive was generated by hypermail 2.1.6 : Wed Dec 31 2014 - 23:21:32 CST