From: Stefano Guglielmo (stefano.guglielmo_at_unito.it)
Date: Wed Dec 20 2017 - 01:55:15 CST
Hi,
I apologize for bothering; I realized that probably the reason was
connected to the version of NAMD I was using: it was a binary file (v 2.12,
compiled with icc and against cuda 9.0, it was a bit faster) compiled by
the administrator for a remote machine, which for some reason at a certain
moment "decided" not to write pmf anymore; when using the released binary
everything goes well.
Thanks again for all the info.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Mail
priva di virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
2017-12-20 1:24 GMT+01:00 Giacomo Fiorin <giacomo.fiorin_at_gmail.com>:
> Hi Stefano, look closely at the differences between the input files of the
> previous run (which did save a PMF file) and the new one, where you only
> changed the contents of the .coor file (did you?).
>
> In general, to trigger saving of Colvars output files use the command "cv
> save [outputPrefix]", for example right after the "run" command.
>
> Giacomo
>
>
> On Tue, Dec 19, 2017 at 7:17 PM, Stefano Guglielmo <
> stefano.guglielmo_at_unito.it> wrote:
>
>> Hi all,
>> thanks for your indications.
>> I re-wrapped and restarted and indeed it is working; anyhow NAMD is not
>> writing pmf file anymore (all the other files are ok).
>> What could be the cause?
>>
>> 2017-12-19 19:52 GMT+01:00 Jeff Comer <jeffcomer_at_gmail.com>:
>>
>>> Thanks, Giacomo. I didn't mean to confuse the issue. I've been in the
>>> habit of setting colvarsRestartFrequency, when I should probably just
>>> leave it as the default.
>>>
>>> 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 Tue, Dec 19, 2017 at 10:27 AM, Giacomo Fiorin
>>> <giacomo.fiorin_at_gmail.com> wrote:
>>> > Hi Jeff, I would be a bit careful with this.
>>> >
>>> > It is possible that restartFreq and colvarsRestartFrequency may
>>> differ, but
>>> > by default colvarsRestartFrequency is equal to restartFreq. When they
>>> > differ, it is only because people set them explicitly like that for
>>> their
>>> > own reasons. Because the NAMD restart file does not contain the
>>> timestep
>>> > number, checking this with certainty after the fact will not be
>>> possible.
>>> > If Stefano has the input files he can do so, but I don't know about the
>>> > general case.
>>> >
>>> > On the other hand, the problem of a multi-chain protein "breaking up"
>>> due to
>>> > wrapping is a very common scenario. I added the check for "differs
>>> greatly"
>>> > after dealing with countless instances of this problem in and out of
>>> this
>>> > mailing list. Fortunately, it is possible to verify whether this is
>>> > happening. If so, it is also possible to prevent it by disabling
>>> wrapAll,
>>> > or by restraining the center-of-mass motion to the molecular complex of
>>> > interest.
>>> >
>>> > Your advice is correct, but it may be misinterpreted by others who
>>> just want
>>> > the error message go away.
>>> >
>>> > Giacomo
>>> >
>>> >
>>> > On Tue, Dec 19, 2017 at 10:20 AM, Jeff Comer <jeffcomer_at_gmail.com>
>>> wrote:
>>> >>
>>> >> I just wanted to note that the error you're experiencing "differs
>>> >> greatly from the value last read from the state file" can be due to
>>> >> the restartFreq in the NAMD configuration file being different from
>>> >> colvarsRestartFrequency in the Colvars configuration file. The
>>> >> simulation then starts from a different frame from the last one in the
>>> >> state file and the value of the colvar is likely to be different. If
>>> >> this is the reason, one solution is simply to edit the .colvars.state
>>> >> file and change the value of the colvar to the calculated value
>>> >> (44.0519).
>>> >>
>>> >> 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 Tue, Dec 19, 2017 at 8:08 AM, Giacomo Fiorin
>>> >> <giacomo.fiorin_at_gmail.com> wrote:
>>> >> > Hi Stefano, I wouldn't try turning on or off the PBC- and
>>> >> > wrapping-related
>>> >> > flags, but try instead to diagnose what is going on.
>>> >> >
>>> >> > You could load the same set of input files in VMD:
>>> >> > mol new *.psf
>>> >> > mol addfile *.restart.coor
>>> >> > pbc readxst *.restart.xsc
>>> >> > (The last one is needed to load the PBC unit cell.) Then load the
>>> >> > Colvars
>>> >> > configuration file and evaluate the variables as you did before.
>>> >> >
>>> >> > If you conclude that PBC wrapping is to blame, keep in mind that
>>> >> > disabling
>>> >> > wrapAll can only prevent future problems. Once the existing restart
>>> >> > files
>>> >> > written by NAMD are affected by it, you will probably need to go
>>> back to
>>> >> > the
>>> >> > 2nd most recent set of restart files. Alternatively, you could opt
>>> for
>>> >> > translating and re-wrapping your system in VMD using pbctools, or
>>> the
>>> >> > much
>>> >> > faster qwrap:
>>> >> > https://github.com/jhenin/qwrap
>>> >> >
>>> >> > Then, you can save back the corrected restart file:
>>> >> > animate write namdbin wrapped.coor
>>> >> > If you do this you lose the double precision, but it would only be
>>> for
>>> >> > that
>>> >> > one step when you restart.
>>> >> >
>>> >> > Giacomo
>>> >> >
>>> >> >
>>> >> > On Tue, Dec 19, 2017 at 3:48 AM, Stefano Guglielmo
>>> >> > <stefano.guglielmo_at_unito.it> wrote:
>>> >> >>
>>> >> >> Hi Josh and Giacomo,
>>> >> >> thanks for tips. I tried to re-run tha calculation loading
>>> >> >> *.restart.colvars.state in the config file, but NAMD is reporting
>>> the
>>> >> >> following error:
>>> >> >>
>>> >> >> Error: the calculated value of colvar "distance_ver":
>>> >> >> colvars: 44.0519
>>> >> >> colvars: differs greatly from the value last read from the state
>>> file:
>>> >> >> colvars: 60.976
>>> >> >> colvars: Possible causes are changes in configuration, wrong state
>>> >> >> file,
>>> >> >> or how PBC wrapping is handled.
>>> >> >>
>>> >> >> I double checked the requested files but apparently everything
>>> seems
>>> >> >> correct;
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >>
>>> >> >> I also tried with wrapall off and forceNoPBC for the collective
>>> >> >> variable
>>> >> >> involved in the error, but the outcome was always the same.
>>> >> >> Do you have any suggestions?
>>> >> >> Thanks
>>> >> >> Stefano
>>> >> >>
>>> >> >> 2017-12-19 2:40 GMT+01:00 Giacomo Fiorin <giacomo.fiorin_at_gmail.com
>>> >:
>>> >> >>>
>>> >> >>> If you do have the state file saved, the next run after loading it
>>> >> >>> should
>>> >> >>> print the PMF file again.
>>> >> >>>
>>> >> >>> Giacomo
>>> >> >>>
>>> >> >>> On Dec 18, 2017 7:38 PM, "Vermaas, Joshua" <
>>> Joshua.Vermaas_at_nrel.gov>
>>> >> >>> wrote:
>>> >> >>>>
>>> >> >>>> Hi Stefano,
>>> >> >>>>
>>> >> >>>> I haven't done it myself, but wouldn't you just need to write a
>>> >> >>>> script
>>> >> >>>> to re-add the hills that metadynamics is adding yourself, based
>>> >> >>>> either on
>>> >> >>>> the colvars.traj file (ideally) or worst case recalculating your
>>> >> >>>> reaction
>>> >> >>>> coordinate trajectory from the dcd? The end result should in
>>> >> >>>> principle be
>>> >> >>>> the same if you saved these values at the same frequency that
>>> hills
>>> >> >>>> are
>>> >> >>>> added, albeit with a large chance of making a mistake somewhere
>>> in
>>> >> >>>> code if
>>> >> >>>> you don't have a working example to make sure that your script
>>> does
>>> >> >>>> what it
>>> >> >>>> is supposed to.
>>> >> >>>>
>>> >> >>>> -Josh
>>> >> >>>>
>>> >> >>>> On 12/18/2017 05:29 PM, Stefano Guglielmo wrote:
>>> >> >>>> Dear NAMD users,
>>> >> >>>> is it possible to reconstruct pmf of a metadynamics simulation
>>> (if
>>> >> >>>> for
>>> >> >>>> some reason the original file was corrupted or lost) in the same
>>> >> >>>> format as
>>> >> >>>> the one written as output by NAMD?
>>> >> >>>> Thanks in advance
>>> >> >>>> Stefano
>>> >> >>>>
>>> >> >>>> --
>>> >> >>>> Stefano GUGLIELMO PhD
>>> >> >>>> Assistant Professor of Medicinal Chemistry
>>> >> >>>> Department of Drug Science and Technology
>>> >> >>>> Via P. Giuria 9
>>> <https://maps.google.com/?q=Via+P.+Giuria+9+%0D+%3E%3E+%3E%3E%3E%3E+10125+Turin,+ITALY+%0D+%3E%3E+%3E%3E%3E%3E+ph.+%2B39&entry=gmail&source=g>
>>> >> >>>> 10125 Turin, ITALY
>>> <https://maps.google.com/?q=Via+P.+Giuria+9+%0D+%3E%3E+%3E%3E%3E%3E+10125+Turin,+ITALY+%0D+%3E%3E+%3E%3E%3E%3E+ph.+%2B39&entry=gmail&source=g>
>>> >> >>>> ph.
>>> <https://maps.google.com/?q=Via+P.+Giuria+9+%0D+%3E%3E+%3E%3E%3E%3E+10125+Turin,+ITALY+%0D+%3E%3E+%3E%3E%3E%3E+ph.+%2B39&entry=gmail&source=g>+39
>>> (0)11 6707178
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Stefano GUGLIELMO PhD
>>> >> >> Assistant Professor of Medicinal Chemistry
>>> >> >> Department of Drug Science and Technology
>>> >> >> Via P. Giuria 9
>>> <https://maps.google.com/?q=Via+P.+Giuria+9+%0D+%3E%3E+%3E%3E+10125+Turin,+ITALY+%0D+%3E%3E+%3E%3E+ph.+%2B39&entry=gmail&source=g>
>>> >> >> 10125 Turin, ITALY
>>> <https://maps.google.com/?q=Via+P.+Giuria+9+%0D+%3E%3E+%3E%3E+10125+Turin,+ITALY+%0D+%3E%3E+%3E%3E+ph.+%2B39&entry=gmail&source=g>
>>> >> >> ph.
>>> <https://maps.google.com/?q=Via+P.+Giuria+9+%0D+%3E%3E+%3E%3E+10125+Turin,+ITALY+%0D+%3E%3E+%3E%3E+ph.+%2B39&entry=gmail&source=g>+39
>>> (0)11 6707178
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Giacomo Fiorin
>>> >> > Associate Professor of Research, Temple University, Philadelphia, PA
>>> >> > Contractor, National Institutes of Health, Bethesda, MD
>>> >> > http://goo.gl/Q3TBQU
>>> >> > https://github.com/giacomofiorin
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Giacomo Fiorin
>>> > Associate Professor of Research, Temple University, Philadelphia, PA
>>> > Contractor, National Institutes of Health, Bethesda, MD
>>> > http://goo.gl/Q3TBQU
>>> > https://github.com/giacomofiorin
>>>
>>
>>
>>
>> --
>> Stefano GUGLIELMO PhD
>> Assistant Professor of Medicinal Chemistry
>> Department of Drug Science and Technology
>> Via P. Giuria 9
>> <https://maps.google.com/?q=Via+P.+Giuria+9+10125+Turin,+ITALY+ph.+%2B39&entry=gmail&source=g>
>> 10125 Turin, ITALY
>> <https://maps.google.com/?q=Via+P.+Giuria+9+10125+Turin,+ITALY+ph.+%2B39&entry=gmail&source=g>
>> ph. +39
>> <https://maps.google.com/?q=Via+P.+Giuria+9+10125+Turin,+ITALY+ph.+%2B39&entry=gmail&source=g>
>> (0)11 6707178
>>
>>
>
>
> --
> Giacomo Fiorin
> Associate Professor of Research, Temple University, Philadelphia, PA
> Contractor, National Institutes of Health, Bethesda, MD
> http://goo.gl/Q3TBQU
> https://github.com/giacomofiorin
>
-- Stefano GUGLIELMO PhD Assistant Professor of Medicinal Chemistry Department of Drug Science and Technology Via P. Giuria 9 10125 Turin, ITALY ph. +39 (0)11 6707178
This archive was generated by hypermail 2.1.6 : Sun Dec 31 2017 - 23:21:51 CST