Previous Thread
Next Thread
Print Thread
Page 1 of 2 1 2
Joined: Apr 2009
Posts: 141
M
Forum Member
OP Offline
Forum Member
M
Joined: Apr 2009
Posts: 141
I am reading in the topology and parameter files using the way described in http://mackerell.umaryland.edu/Warning.html. So my input file was just:

==========input=============================
bomblev 0

open read form unit 11 name top_all22_prot.inp
read rtf card unit 11
close unit 11

open read form unit 12 name par_all22_prot.inp
read parameter card unit 12
close unit 12

open read form unit 13 name top_all36_cgenff.rtf
read rtf card append unit 13
close unit 13

open read form unit 14 name par_all36_cgenff.prm
read parameter card append unit 14
close unit 14

stop

============================================

But I got error messages:


=============errors=========================
CHARMM> open read form unit 13 name top_all36_cgenff.rtf
VOPEN> Attempting to open::top_all36_cgenff.rtf::
OPNLGU> Unit 13 opened for READONLY access to top_all36_cgenff.rtf

CHARMM> read rtf card append unit 13
MAINIO> Residue topology file being read from unit 13.
TITLE> * -------------------------------------------------------------------------- *
TITLE> * CGENFF: TOPOLOGY FOR THE CHARMM GENERAL FORCE FIELD V. 2B4 *
TITLE> * FOR SMALL MOLECULE DRUG DESIGN *
TITLE> * -------------------------------------------------------------------------- *
TITLE> *
*** WARNING **** residue ALAD already exists (old one deleted)
RESI ALAD 0.00
*** WARNING **** residue GLYP already exists (old one deleted)
RESI GLYP -1.00
IN USE MAXIMUM
ATOMS 10003 10000
BONDS 9534 10000
ANGLES 2 10000
DIHEDRALS 0 10000
IMPROPERS 496 4000
CROSSTERMS 27 2000
EXCLUSIONS 0 5000
ACCEPTORS 221 600
DONORS 141 600
BUILD/IC 8809 10000

***** LEVEL -4 WARNING FROM <RTFRDR> *****
***** LIMIT EXCEEDED
******************************************
BOMLEV ( 0) IS REACHED - TERMINATING. WRNLEV IS 5


============================================


May I ask how I should read in the CGFF correctly?

And I found the file below in the tutorialL
tutorial.html

Is this the introduction of how the CGFF was generated, or is this teaching us how to correctly read in the CGFF together with the protein force field (all22)?

Thanks a lot!

Last edited by mooctopus; 05/05/10 07:28 AM.
Joined: Dec 2005
Posts: 1,535
Forum Member
Offline
Forum Member
Joined: Dec 2005
Posts: 1,535
About the "limit exceeded": this is numero uno on the CGenFF FAQ and I answered it numerous times on these forums.

About the "residue already exists (old one deleted)" warnings: although these are harmless in most cases, I probably should either remove the residues involved from the CGenFF distribution, or update the recommendation to first stream in CGenFF and then the bio force field(s). I'm still debating what's best.

Joined: Apr 2009
Posts: 141
M
Forum Member
OP Offline
Forum Member
M
Joined: Apr 2009
Posts: 141
Thank you, Kenno!
You posted on the webpage that where "gnu" and "medium" should be modified according to architecture and desired CHARMM size, resp. Version 34b2 can be compiled by cd-ing into your c34b2 directory and untarring this file before compilation (this will overwrite ./install.com, ./source/fcm/dimens.fcm and ./doc/preflx_list.doc). Older CHARMM version are not supported. Be advised that the CHARMM build system will not recompile affected modules after changing preprocessor settings! Because of this, you cannot recompile CHARMM with CGenFF support in a directory in which you previously compiled CHARMM without CGenFF support unless you do

I am using c34b1, and I did not succeed in compiling this CGenFF. Is that because the version was older?

Thank you!

Joined: Apr 2009
Posts: 141
M
Forum Member
OP Offline
Forum Member
M
Joined: Apr 2009
Posts: 141
Hi Kenno, I guess c34b1 is not enough, since I run just the CGenFF themselves and got the skull message:
CHARMM> bomblev 0

CHARMM>

CHARMM>

CHARMM>

CHARMM> open read form unit 13 name top_all36_cgenff.rtf
VOPEN> Attempting to open::top_all36_cgenff.rtf::
OPNLGU> Unit 13 opened for READONLY access to top_all36_cgenff.rtf

CHARMM> read rtf card unit 13
MAINIO> Residue topology file being read from unit 13.
TITLE> * -------------------------------------------------------------------------- *
TITLE> * CGENFF: TOPOLOGY FOR THE CHARMM GENERAL FORCE FIELD V. 2B4 *
TITLE> * FOR SMALL MOLECULE DRUG DESIGN *
TITLE> * -------------------------------------------------------------------------- *
TITLE> *

CHARMM> close unit 13
VCLOSE: Closing unit 13 with status "KEEP"

CHARMM>

CHARMM> open read form unit 14 name par_all36_cgenff.prm
VOPEN> Attempting to open::par_all36_cgenff.prm::
OPNLGU> Unit 14 opened for READONLY access to par_all36_cgenff.prm

CHARMM> read parameter card unit 14

PARAMETER FILE BEING READ FROM UNIT 14
TITLE> * -------------------------------------------------------------------------- *
TITLE> * CGENFF: PARAMETERS FOR THE CHARMM GENERAL FORCE FIELD V. 2B4 *
TITLE> * FOR SMALL MOLECULE DRUG DESIGN *
TITLE> * -------------------------------------------------------------------------- *
TITLE> *

***** LEVEL -3 WARNING FROM <PARRDR> *****
***** Maximum no. of dihedrals reached
******************************************
BOMLEV ( 0) IS REACHED - TERMINATING. WRNLEV IS 5

Joined: Dec 2005
Posts: 1,535
Forum Member
Offline
Forum Member
Joined: Dec 2005
Posts: 1,535
CGenFF is officially only supported from c35 onwards. I'm offering a patch for c34b2 on my website as a courtesy to c34 users, but it requires recompiling CHARMM, and if you want to use an older version than that, you're on your own. It should not be too difficult to adjust the patch to your CHARMM version but I'm not helping with it.

Last edited by Kenno; 05/06/10 12:57 AM. Reason: More helpful information.
Joined: Apr 2009
Posts: 141
M
Forum Member
OP Offline
Forum Member
M
Joined: Apr 2009
Posts: 141
Okay, I will install c35b then

Joined: Apr 2009
Posts: 141
M
Forum Member
OP Offline
Forum Member
M
Joined: Apr 2009
Posts: 141
Hi Kenno, thanks a lot! I installed c35b3 and finally it works smile

Joined: Apr 2009
Posts: 141
M
Forum Member
OP Offline
Forum Member
M
Joined: Apr 2009
Posts: 141
May I also ask how to merge the teamsugar force field with the protein and CGenFF?

Thanks a lot!

Joined: Apr 2009
Posts: 141
M
Forum Member
OP Offline
Forum Member
M
Joined: Apr 2009
Posts: 141
I guess the Mass number matters? Is that okay if I just remas the atoms?

Joined: Dec 2005
Posts: 1,535
Forum Member
Offline
Forum Member
Joined: Dec 2005
Posts: 1,535
CHARMM internally refers to atom types as integers, which are provided by the MASS statements in the topology (rtf) file. For the purpose of the following discussion, I will call these integers "MASS numbers" (even though it's a bit of a misnomer).
CHARMM has a hard-coded maximum MASS number of 500, and increasing this would make the static memory usage explode, which is bad because CHARMM constantly brushes the maximum static memory allocation on certain architectures. The MASS numbers in CGenFF have a range of 256, those in the carbohydrate FF have a range of 99, and those in the protein force field have a range of 121. 256+99+121=476, so you can renumber the MASS statements by adding a constant offset to the MASS numbers in CGenFF and another constant offset to the carbohydrate force field, but you have to choose those offsets carefully.
Note that these MASS lists are pretty sparse. CGenFF actually only contains 141 atom types, the carbohydrate force field 45, and the protein force field 95. 141+45+95=281, so, if you renumber each and every MASS statement, you can have a contiguous range of MASS numbers from 1-281, leaving plenty of room for other CHARMM force fields. But it's more work, and more prone to breaking the psf (see warning below).
Note that CGenFF uses the flexible parameter reader ("flex" keyword), which requires an ATOMS section in the parameter (prm) file that is a duplicate of the MASS list in the topology (rtf) file.

WARNING: changing the MASS number of an atom type has no physical impact, except that it invalidates any psf file containing that atom type! In other words, you have to re-generate the psf after changing the MASS numbers. This is the reason why the MASS lists are sparse as they are: to allow for future atom types to be inserted without requiring the user to regenerate their psf files.

Last edited by Kenno; 05/06/10 05:24 PM. Reason: Added "more prone to breaking the psf..."
Page 1 of 2 1 2

Moderated by  alex, lennart, rmv 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.5
(Release build 20201027)
Responsive Width:

PHP: 7.3.31-1~deb10u5 Page Time: 0.025s Queries: 35 (0.017s) Memory: 0.7877 MB (Peak: 0.8860 MB) Data Comp: Off Server Time: 2023-11-28 19:06:37 UTC
Valid HTML 5 and Valid CSS