From: Souvik Sinha (souvik.sinha893_at_gmail.com)
Date: Tue May 30 2017 - 02:51:31 CDT
Hi,
1. I am running a 2D eABF using "alpha" & "distanceZ" colvars as my 2 RCs.
In the *colvar.traj files, I am getting fields like " step alpha
r_alpha Translocation r_Translocation". I don't get what does this "
r_colvarName" field mean?
2. I have also tried semi-eABF by enabling "extendedLagrangian" for 'alpha'
colvar, but not for 'distanceZ' colvar. But eventually, it failed to do
what I wished for. It stopped with an error as follows:
colvars: can't read "extendedFluctuation": no such variable
FATAL ERROR: Error in the collective variables module: No such file or
directory
Then I switched to full eABF by enabling "extendedLagrangian" for both
the colvars. So it seems my approach is not correct for semi-eABF. Can you
please help me out?
Souvik
On Fri, May 26, 2017 at 9:23 PM, Souvik Sinha <souvik.sinha893_at_gmail.com>
wrote:
> Ok thanks. I get it now.
>
>
> On Fri, May 26, 2017 at 9:00 PM, Jérôme Hénin <jerome.henin_at_ibpc.fr>
> wrote:
>
>> Hi Souvik,
>>
>> The .count/.grad/.pmf files are the ABF results for the extended
>> coordinate. They can be useful to monitor the progress of the simulation,
>> but you don't need to worry about them.
>>
>> *.eabf.* files are related to the Z/Y estimator. *.czar.* are related to
>> the CZAR estimator. They should converge to just about the same values.
>>
>> Jerome
>>
>>
>> On 26 May 2017 at 00:45, Souvik Sinha <souvik.sinha893_at_gmail.com> wrote:
>>
>>> Thanks for the reply.
>>>
>>> I know that each replica would separately give output of its grad &
>>> counts (classical ABF). But here in eABF, each replica is giving multiple
>>> grads & count files as I mentioned in the previous mail. One set is for
>>> CZAR estimator that I understood but what about other sets? how do I
>>> suppose to handle them?
>>>
>>> On Fri, May 26, 2017 at 2:36 AM, Jeff Comer <jeffcomer_at_gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Each replica produces its own gradient, count, and PMF files, which are
>>>> synchronized every shareFreq steps. For usual values of shareFreq, these
>>>> files should be very similar. How different they are depends on shareFreq,
>>>> which is the number of steps between synchronization of the replicas. If I
>>>> remember correctly, output of the .grad, .count, etc. files happens before
>>>> synchronization, so if shareFreq and colvarsRestartFrequency are the same,
>>>> your files will be different by shareFreq samples.
>>>>
>>>> Jeff
>>>>
>>>>
>>>>
>>>> –––––––––––––––––––––––––––––––––––———————
>>>> Jeffrey Comer, PhD
>>>> Assistant Professor
>>>> Institute of Computational Comparative Medicine
>>>> Nanotechnology Innovation Center of Kansas State
>>>> Kansas State University
>>>> Office: P-213 Mosier Hall
>>>> Phone: 785-532-6311
>>>> Website: http://jeffcomer.us
>>>>
>>>> On Thu, May 25, 2017 at 5:02 AM, Souvik Sinha <
>>>> souvik.sinha893_at_gmail.com> wrote:
>>>>
>>>>> While running MW_eabf, I am actually getting 4 sets " grad " files for
>>>>> each
>>>>> replica [ e.g. colvar2.1.grad, colvar2.1.zgrad, colvar2.1.czar.grad
>>>>> & colvar2.eabf.1.grad ] & 3 sets of " count " files [colvar2.1.count,
>>>>> colvar2.1.zcount & colvar2.eabf.1.count]. There are significant
>>>>> difference
>>>>> in the values of those files.
>>>>>
>>>>> I understand that " *.zcount " is the z-histogram & " *.zgrad "
>>>>> contains
>>>>> z-averaged restraints forces. But, what is need of the other sets ? I
>>>>> guess, one of them is related to Z-Y estimator but which one is it ?
>>>>>
>>>>> I found " *outputName*.czar.grad: current estimate of the free energy
>>>>>
>>>>> gradient (grid), in multicolumn ". Then where this file is differing
>>>>> from
>>>>> outputName.[ReplicaID].grad & outputName.eabf.[ReplicaID].grad ?
>>>>>
>>>>> Part of the configuration file (related to input-output) is here :
>>>>>
>>>>> set outName colvar2
>>>>>
>>>>> structure vacuum.psf
>>>>> parameters common/par_all22_prot.inp
>>>>>
>>>>> paraTypeCharmm on
>>>>>
>>>>> coordinates equilvac.coor
>>>>> velocities equilvac.vel
>>>>>
>>>>>
>>>>> outputname $outName.[myReplica]
>>>>> restartname $outName.[myReplica]
>>>>>
>>>>> *****
>>>>> ***
>>>>> source ../eabf.tcl
>>>>> set eabf_inputname 0 ;# restart file name
>>>>> or
>>>>> "0"
>>>>> set eabf_outputname colvar2.eabf.[myReplica] ;# restart file name
>>>>> set eabf_temperature 300
>>>>> set eabf_outputfreq 10000
>>>>>
>>>>> **************************
>>>>> *****************
>>>>>
>>>>> # ABF
>>>>>
>>>>> colvars on
>>>>> colvarsConfig colvars2.in
>>>>>
>>>>> ##### Replica Exchange ####################
>>>>>
>>>>>
>>>>> source /apps/NAMD_2.12_Linux-x86_64-multicore/lib/selectionRules.tcl
>>>>> source /apps/NAMD_2.12_Linux-x86_64-multicore/lib/resampleWalkers.tcl
>>>>> source /apps/NAMD_2.12_Linux-x86_64-multicore/lib/minExchanges.tcl
>>>>>
>>>>>
>>>>> firsttimestep 0
>>>>> replicaUniformPatchGrids on
>>>>> set m 1000
>>>>> set sharedFreq 10000
>>>>> for {set i 0} {$i < $m} {incr i} {
>>>>> run $sharedFreq
>>>>> cv bias abf1 share
>>>>> }
>>>>>
>>>>>
>>>>> *************************************************************
>>>>>
>>>>>
>>>>> Please help me out.
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>> On Fri, Apr 28, 2017 at 10:57 AM, Souvik Sinha <
>>>>> souvik.sinha893_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Thanks for the reply.
>>>>> >
>>>>> > On Fri, Apr 28, 2017 at 2:30 AM, Jérôme Hénin <jerome.henin_at_ibpc.fr>
>>>>> > wrote:
>>>>> >
>>>>> >> Hi Souvik,
>>>>> >>
>>>>> >> Indeed, you can always find the current documentation here:
>>>>> >> http://colvars.github.io/
>>>>> >>
>>>>> >> Multiple-walker eABF works fine. To estimate the free energy, you
>>>>> can
>>>>> >> merge CZAR results from different walkers. For that, run a single
>>>>> eABF
>>>>> >> simulation for zero steps, providing the output from all walkers as
>>>>> >> inputPrefix
>>>>> >> <http://colvars.github.io/colvars-refman-namd/colvars-refman
>>>>> -namd.html#x1-590006.1.2>.
>>>>> >> To get all the necessary input, you need to enable
>>>>> writeCZARwindowFile
>>>>> >> <http://colvars.github.io/colvars-refman-namd/colvars-refman
>>>>> -namd.html#x1-640006.2.1> during
>>>>>
>>>>> >> your calculations (if you forgot, you can also extract this
>>>>> information
>>>>> >> from state files, but that will an extra step).
>>>>> >>
>>>>> >> The NAMD config for combining might look like this, using Tcl to
>>>>> build
>>>>> >> the list of files:
>>>>> >>
>>>>> >> set f base_name
>>>>> >> set n_replicas 42
>>>>> >> set input ""
>>>>> >>
>>>>> >> for {set i 0} {$i < $n_replicas} {incr i} {
>>>>> >> append input "$f.$i "
>>>>> >> }
>>>>> >>
>>>>> >> colvars on
>>>>> >> cv config "
>>>>> >> (...)
>>>>> >> abf {
>>>>> >> inputPrefix $input
>>>>> >> (...)"
>>>>> >>
>>>>> >> Alternately, for the Zheng/Yang estimator, see the -mergemwabf
>>>>> option in
>>>>> >> the documentation. To do that, remember that you need to enable the
>>>>> >> Zheng/Yang estimator when running all the calculations!
>>>>> >>
>>>>> >> Best,
>>>>> >> Jerome
>>>>> >>
>>>>> >>
>>>>> >> On 26 April 2017 at 13:17, Souvik Sinha <souvik.sinha893_at_gmail.com>
>>>>> >> wrote:
>>>>> >>
>>>>> >>> Sorry, I got most of my answers in http://www.ks.uiuc.edu/Rese
>>>>> >>> arch/vmd/current/ug/node235.html
>>>>> >>>
>>>>> >>> Still, doubt remain regarding applicability of Multiple-walker
>>>>> strategy
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Souvik Sinha
>>> Research Fellow
>>> Bioinformatics Centre (SGD LAB)
>>> Bose Institute
>>>
>>> Contact: 033 25693275
>>>
>>
>>
>
>
> --
> Souvik Sinha
> Research Fellow
> Bioinformatics Centre (SGD LAB)
> Bose Institute
>
> Contact: 033 25693275
>
-- Souvik Sinha Research Fellow Bioinformatics Centre (SGD LAB) Bose Institute Contact: 033 25693275
This archive was generated by hypermail 2.1.6 : Mon Dec 31 2018 - 23:20:19 CST