RE: CHARMM-c36, glycans and RATTLE

From: Tristan Croll (tristan.croll_at_qut.edu.au)
Date: Thu Aug 15 2013 - 01:23:50 CDT

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.

Tristan

From: Sunhwan Jo [mailto:sunhwan_at_uchicago.edu]
Sent: Thursday, 15 August 2013 4:10 PM
To: Tristan Croll
Cc: namd-l_at_ks.uiuc.edu
Subject: Re: namd-l: CHARMM-c36, glycans and RATTLE

I used all36 for both protein and carbohydrates.

Sunhwan

On Aug 15, 2013, at 1:05 AM, Tristan Croll <tristan.croll_at_qut.edu.au<mailto:tristan.croll_at_qut.edu.au>>
 wrote:

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?

Thanks,

Tristan

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

Tristan,

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.

Thanks,
Sunhwan

On Aug 14, 2013, at 11:50 PM, Tristan Croll <tristan.croll_at_qut.edu.au<mailto:tristan.croll_at_qut.edu.au>> 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
top_all36_carb.rtf
stream/toppar_all36_glycopeptide.str

The simulations are run using:
par_all22_prot.prm
par_all36_carb.prm
stream/toppar_all36_carb_glycopeptide.str
toppar_water_ions.str

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?

Thanks,

Tristan

Tristan Croll
Lecturer
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 : Tue Dec 31 2013 - 23:23:34 CST