From: BIN ZHANG (zhngbn_at_gmail.com)
Date: Tue Jan 26 2010 - 23:54:19 CST
That's very good to know. Thanks for the great work.
Bin
On Jan 26, 2010, at 6:18 AM, Giacomo Fiorin wrote:
> The only known bug affecting results is the sign error in the angle
> gradients, which was already discussed on namd-l last December. If
> you're using an "angle" component, you can fix this issue with a
> negative force constant (at least until the updated sources are
> available). As far as we know, this is the only condition where
> your trajectory can be affected (fortunately in a way easy to notice).
>
> All the other fixes are for issues at compilation time with certain
> compilers, or errors in the initialization (i.e. the module not
> allowing you to run configurations that are otherwise legal). One
> of these is indeed the inability to use multiple "run" commands.
>
> Giacomo
>
> ---- ----
> Giacomo Fiorin
> ICMS - Institute for Computational Molecular Science
> Temple University
> 1900 N 12 th Street, Philadelphia, PA 19122
> work phone: (+1)-215-204-4216
> mobile: (+1)-267-324-7676
> mail: giacomo.fiorin_at_gmail.com
> ---- ----
>
>
> On Tue, Jan 26, 2010 at 2:32 AM, BIN ZHANG <zhngbn_at_gmail.com> wrote:
> Dear Giacomo:
>
> Thanks a lot for your reply. Now everything makes more sense to me.
>>
>
>> There is a fix coming up on CVS to solve this issue entirely,
>> together with several other bugfixes.
>>
> For my purpose, the code you posted should be enough for now. I'm
> only using the simple harmonic bias.
>
> But could you be a little bit more specific about these bugfixes?
> I'm planning on using the colvar module to run some productive long
> trajectories, and would like to know whether they are going to
> affect my result or not.
>
>
> Thanks again,
> Bin
>
>> In the meantime, depending on what you're doing, you can try by
>> replacing the function colvarmodule::finalise() at line 499 of
>> colvarmodule.C with what follows.
>>
>> void colvarmodule::finalise()
>> {
>> std::string const out_name =
>> (output_prefix.size() ?
>> std::string (output_prefix+".colvars.state") :
>> std::string ("colvars.state"));
>> cvm::log ("Saving collective variables state to \""+out_name+"\".
>> \n");
>> proxy->backup_file (out_name.c_str());
>> std::ofstream out (out_name.c_str());
>> out.setf (std::ios::scientific, std::ios::floatfield);
>> this->write_restart (out);
>> out.close();
>>
>> cv_traj_os.flush();
>> }
>>
>> This function (as opposed to the one you currently have) will write
>> the state file, synchronize the buffer of the trajectory file, but
>> not deallocate anything.
>>
>> This fix will work assuming that you don't need output files
>> written by the bias (such as the ".pmf" files written by ABF and
>> metadynamics) at the end of each "run" statement. If you do need
>> them, then I can send you all the updated sources privately.
>>
>> Bests
>> Giacomo
>>
>>
>> ---- ----
>> Giacomo Fiorin
>> ICMS - Institute for Computational Molecular Science
>> Temple University
>> 1900 N 12 th Street, Philadelphia, PA 19122
>> work phone: (+1)-215-204-4216
>> mobile: (+1)-267-324-7676
>> mail: giacomo.fiorin_at_gmail.com
>> ---- ----
>>
>>
>> On Mon, Jan 25, 2010 at 4:09 PM, BIN ZHANG <zhngbn_at_gmail.com> wrote:
>> Dear All:
>>
>> I have experienced an interesting behavior of the colvar module. It
>> seems to me that this module does not work properly with the
>> command "run". Say, if I have the following in my config file
>>
>> run 100
>> output ./folder/outfile
>> run 100
>>
>> Then the colvar module will be only initialized correctly in the
>> first 100 step. For the next 100 steps, no collective variables are
>> written in either the traj, or state file. It seems the colvar
>> definition are completely uninitialized. This won't cause too much
>> problem, but if you happen to know how to fix it, I would be very
>> happy to listen.
>>
>> Thanks,
>> Bin
>>
>>
>>
>
>
This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:53:43 CST