-
Notifications
You must be signed in to change notification settings - Fork 164
Closed
Description
See: <AmberSourceDist>/AmberTools/src/leap/src/leap/commands.c:1694 (oCmd_loadAmberParams). Excerpt:
/*
* nasty, special kludge to prevent loading parm10 more than once;
* This is not generalizable....
*/
static int parm10_loaded = 0;
static int parm99_loaded = 0;
static int parm15_loaded = 0;
static char parm10[] = "parm10.dat";
static char parm99[] = "parm99.dat";
static char parm15[] = "parm15";
if ( !bCmdGoodArguments( "loadAmberParams", iArgCount, aaArgs, "s" ) ) {
VPFATALDELAYEDEXIT(( sUsage ));
return(NULL);
}
strcpy( sFile, sOString(oAssocObject(aaArgs[0])) );
if( strstr( sFile, parm10 ) ) {
parm10_loaded += 1;
if( parm10_loaded > 1 ){
VPNOTE(( "Skipping %s: already loaded\n", sFile ));
parm10_loaded -= 1;
return(NULL);
}
}Amber's loadAmberParams uses a "nasty, special kludge" to ensure parm10, parm99, and parm15 are loaded no more than once. If this behavior is not replicated in ParmEd, Amber parameters may be loaded incorrectly. For example, consider using AmberParameterSet.from_leaprc with the following leaprc:
source leaprc.protein.ff14sb
# ...
# parm10 = loadAmberParams parm10.dat
# frcmod14SB = loadAmberParams frcmod.ff14SB
# ...
source leaprc.RNA.OL3
# ...
# parm10 = loadAmberParams parm10.dat
# ...Without replicating the "special kludge", leaprc.RNA.OL3 will reload parm10 and overwrite many of the changes introduced by loading frcmod.ff14SB. A solution is to match Amber's behavior and ensure each of parm15, parm99, and parm15 are loaded at most once. Here's an example patch from my ParmEd fork.
Metadata
Metadata
Assignees
Labels
No labels