From: Chris Harrison (char_at_ks.uiuc.edu)
Date: Thu Mar 12 2009 - 07:14:23 CDT
Chris,
This is more or less how it works. The key thing is that NAMD itself
doesn't actually keep track of multiple lambdas ..... it is only aware
of a given bin with a specific lambda at any time. The namd config file
is actually just a tcl script that is parsed and ran through a "tcl
frontend" in NAMD. This means the config file is nothing
more than a tcl script that is simply iteratively making NAMD runs of
each specific lambda. So if you are willing to do a little extra work
in order to integrate your energies from multiple log files in order to
get your dG or dA for the entire perturbation, there's no reason you
couldn't restart the run of your current bin in one job to finish it's
sampling and then use it's restart file to begin the remaining bins by
simply deleting the lamba #'s of the bins that have already been
sampled. For example, for the first job you'd use something that looked
like:
-------
# LOOP OVER LAMBDA-STATES
fepEquilSteps 5000
set nSteps 30000
set dLambda 0.04
#set init {0.0 0.00001 0.0001 0.001 0.01 0.02}
#set end {0.98 0.99 0.999 0.9999 0.99999 1.0}
#runFEPlist $init $nSteps
runFEP 0.50 0.54 $dLambda $nSteps
#runFEPlist $end $nSteps
----
Notice that I commented out several lines in order that this run would
only run a bin from 0.5 to 0.54 for 30K steps. Caveat: you'll have to
basically manually merge data from the log file of the crashed 0.5-0.54
bin and this run to integrate the energy for this bin. If do you encounter
problems in the overall dG calculation, it is likely they will stem from
this bin.
To sample the remaining bins you would then use the following:
----
# LOOP OVER LAMBDA-STATES
fepEquilSteps 5000
set nSteps 85000
set dLambda 0.04
#set init {0.0 0.00001 0.0001 0.001 0.01 0.02}
set end {0.98 0.99 0.999 0.9999 0.99999 1.0}
#runFEPlist $init $nSteps
runFEP 0.54 0.98 $dLambda $nSteps
runFEPlist $end $nSteps
----
Again notice I commented out the first set of windows ("set init" line
and first "runFEPlist" line) and changed the beginning bin to of the
"runFEP" line to 0.54. This will provide sampling in the remaining
bins, from 0.54 to 0.98 and from 0.98 to 1.0.
Clear?
C.
--
Chris Harrison, Ph.D.
Theoretical and Computational Biophysics Group
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave., Urbana, IL 61801
char_at_ks.uiuc.edu Voice: 217-244-1733
http://www.ks.uiuc.edu/~char Fax: 217-244-6078
Christopher Hartshorn <cmhartshorn_at_gmail.com> writes:
> Date: Wed, 11 Mar 2009 22:35:02 -0700
> From: Christopher Hartshorn <cmhartshorn_at_gmail.com>
> To: Chris Harrison <char_at_ks.uiuc.edu>, namd-l_at_ks.uiuc.edu
> Subject: Re: namd-l: FEP restart?
> Return-Path: char_at_halifax.ks.uiuc.edu
> Message-Id: <F014B513-D70C-4DA7-A050-0051D81330D2_at_gmail.com>
> X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DNS_FROM_RFC_POST,
> SPF_PASS autolearn=no version=3.1.7-0+tcb1
>
> Chris,
> Attached below this is my conifg file. Yes it is possible that I do not
> have a full understanding of the process. My idea about the script from
> the tutorial (that I am using) is that it runs the sim/FEP for lambda
> step X for n iterations and then repeats for the next lambda step and so
> on. The restart file is created for each 1000 fs and there are 85000 in
> mine per lambda step. So, if I have a restart at 55000 of a particular
> lambda step then when I restart I will be in the middle of the n
> iterations. My understanding about this is that the purpose of the
> numerous iterations at each step is to allow convergence upon some dG
> value or more simply to allow for sufficient sampling. Thus, if I
> restart at some point (such as 55K of an 85K) will it still be at the
> same energy as before it crashed or does it require another 85K n steps
> to converge to a "reportable" value for the lambda step it had been
> trying to calculate? Or am just not getting how this is actually run in
> NAMD?
>
> Best,
> Chris
>
>
> #############################################################
> ## JOB DESCRIPTION ##
> #############################################################
> # FEP
> # DMPC and prot mid1 -upper half vanishing
> #############################################################
> ## ADJUSTABLE PARAMETERS ##
> #############################################################
>
> structure dmpc_mid1.psf
> coordinates mdsim2ns_out.coor
> velocities mdsim2ns_out.vel
> extendedSystem mdsim2ns_out.xsc
> set outputname dmpcmid1FEP55ksteps04_out
>
> #############################################################
> ## SIMULATION PARAMETERS ##
> #############################################################
> # Input parameters
> paraTypeCharmm on
> parameters par_all27_prot_lipid_sil.inp
> parameters par-extraterms.inp
>
> # Force-Field Parameters
> exclude scaled1-4
> 1-4scaling 1.0
> cutoff 12.0
> switching on
> switchdist 10.0
> pairlistdist 13.5
>
> # Integrator Parameters
> timestep 1.0 ;# 1fs/step
> nonbondedFreq 1
> fullElectFrequency 2
> stepspercycle 20
>
> # An internal tuning parameter used in determining the size of the cubes
> of
> # space with which NAMD uses to partition the system
> # The z dimension is going to shrink so pad sufficiently
> margin 1
>
> wrapWater on
> wrapNearest off
>
> # PME (for full-system periodic electrostatics) only with PBC's
> # Must get cell dimensions from PBC basisvectors for accurate PME
> # Remember multiples of 2,3, and/or 5
> PME on
> PMEGridSizeX 120
> PMEGridSizeY 120
> PMEGridSizeZ 100
>
> # Constant Pressure Control (variable volume) only for PBC's
> useGroupPressure yes # smaller fluctuations
> useFlexibleCell no # allow dimensions to fluctuate independently
>
> # Constant Temperature Control
> langevin on ;# do langevin dynamics
> langevinDamping 10 ;# damping coefficient (gamma) of 10/ps
> langevinTemp 310
> langevinHydrogen off ;# don't couple langevin bath to hydrogens
>
> # Nos´e-Hoover Langevin piston pressure control
> langevinPiston on
> langevinPistonTarget 1.01325 ;# in bar -> 1 atm
> langevinPistonPeriod 200.0
> langevinPistonDecay 100.0
> langevinPistonTemp 310
>
> # Output
> outputName $outputname
>
> restartfreq 1000 ;# 1000steps = every 1ps
> dcdfreq 1000
> xstFreq 1000
> outputEnergies 100
> outputTiming 100
> outputPressure 100
> binaryoutput off
>
> rigidbonds all
> rigidtolerance 0.000001
> rigiditerations 400
>
> fixedAtoms on
> fixedAtomsForces on
> fixedAtomsFile fix.pdb
> fixedAtomsCol B
>
> #############################################################
> ## EXECUTION SCRIPT ##
> #############################################################
> # FEP
>
> source fep.tcl
>
> fep on
> fepFile dmpc_mid1_FEP.fep
> fepCol B
> fepOutFile DMPCmid155ksteps04.fepout
> fepOutFreq 10
>
>
> # LOOP OVER LAMBDA-STATES
>
> fepEquilSteps 5000
> set nSteps 85000
>
> set dLambda 0.04
>
> set init {0.0 0.00001 0.0001 0.001 0.01 0.02}
> set end {0.98 0.99 0.999 0.9999 0.99999 1.0}
>
> runFEPlist $init $nSteps
> runFEP 0.02 0.98 $dLambda $nSteps
> runFEPlist $end $nSteps
>
> On Mar 11, 2009, at 5:53 PM, Chris Harrison wrote:
>
>> Chris,
>>
>> I can't think of a reason an FEP could not be restarted. I think you
>> maybe confusing the way FEP works inside NAMD with the way one of the
>> example tcl scripts works that allows you to do a full series of
>> lambda values in a single NAMD config script. Can you send your namd
>> config file?
>>
>> C.
>>
>>
>>
>> --
>> Chris Harrison, Ph.D.
>> Theoretical and Computational Biophysics Group
>> NIH Resource for Macromolecular Modeling and Bioinformatics
>> Beckman Institute for Advanced Science and Technology
>> University of Illinois, 405 N. Mathews Ave., Urbana, IL 61801
>>
>> char_at_ks.uiuc.edu Voice: 217-244-1733
>> http://www.ks.uiuc.edu/~char Fax: 217-244-6078
>>
>>
>> Christopher Hartshorn <cmhartshorn_at_wsu.edu> writes:
>>> Date: Wed, 11 Mar 2009 17:34:59 -0700
>>> From: Christopher Hartshorn <cmhartshorn_at_wsu.edu>
>>> To: namd-l_at_ks.uiuc.edu
>>> Subject: namd-l: FEP restart?
>>> Return-Path: char_at_halifax.ks.uiuc.edu
>>> Message-Id: <D90DD937-EB7C-4F36-9AC3-1B02777FE188_at_wsu.edu>
>>> X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00
>>> autolearn=unavailable version=3.1.7-0+tcb1
>>>
>>> Hello all. Recently, my dept. lost power during a snow storm here in
>>> Pullman. Unfortunately, I did not have a few of the computers on a
>>> power backup system and two sims were stopped before they had
>>> ripened,
>>> if you will.
>>>
>>> One of the sims was an FEP calculation, which brings me to my
>>> question
>>> of can an FEP be restarted? I had the restart feature on, of course,
>>> for the usual every 1000 steps, but the more I think about it the
>>> more I
>>> wondered whether this matters. If my last restart file was from the
>>> 55000 n step of lambda step .50 to .54 (there are 80K total n steps/
>>> lambda step) then my restart would be in the middle of the n
>>> iterations
>>> and I could not start from this point (as far as I understand, at
>>> least).
>>> I can only restart, I think, from the beginning of the lambda step
>>> (as
>>> in at the n=0 point). Thus, am I correct in my thinking about this,
>>> that
>>> I need to rerun the entire FEP because I do not have a restart point
>>> at
>>> the beginning of some lambda step? And, on that same note for the
>>> future, should I set my restart step number to the same as my n
>>> iterations number (e.g. restart=80K steps if n steps=80K) so that
>>> each
>>> restart file set will be only at the beginning of the lambda step?
>>> Thank you very much for any and all answers.
>>>
>>> Best,
>>>
>>> Chris
>>> WSU
>>>
>
>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:52:28 CST