From: Marimuthu Krishnan (marimuthu.krishnan_at_googlemail.com)
Date: Wed Nov 14 2012 - 18:22:48 CST
Hello Giacomo,
Thanks. You are right. The boundaries of certain reaction coordinates in my
calculation are too tight. This choice was deliberate. I need to keep the
boundaries tight to restrain (or to fix/constrain) a few reaction
coordinates. Is there any way to improve the performance with tight
boundaries?
I did many fresh runs followed by restarts. In all cases, I notice this
slow-down and thus it is reproducible.
A related question: Is it possible to define the angle between a bond
vector (connecting two atoms) and a reference axis (say, Z-axis) as a
reaction coordinate but without using dummy atoms in ABF/metadynamics
calculations? I would appreciate any help from experts.
Krishnan
On Tue, Nov 13, 2012 at 3:11 PM, Giacomo Fiorin <giacomo.fiorin_at_gmail.com>wrote:
> Hello Krishnan, if you have a massive list of hills at the ends your
> boundaries may be too tight. Those hills only appear when the variables
> get too close to the boundaries of the grid.
>
> Make a new colvars configuration file with wider boundaries, and enable
> rebinGrids only once (you may disable it in the later runs). This should
> take care of the hills accumulated, if that is the problem.
>
> If you still see the performance decrease, is that reproducible? That is,
> have you tried to re-run the first job of the ABF or metadynamics
> calculations to see if the performance is still fast?
>
> Giacomo
>
>
> On Tue, Nov 13, 2012 at 2:58 PM, Aron Broom <broomsday_at_gmail.com> wrote:
>
>> I'm not sure if it is all a result of the *.colvars.state file, but it
>> seems like that could be the culprit. In general what one can do is to
>> set
>> Walls for your colvars that are somewhat far (multiple hill widths) from
>> the Boundary, and this will prevent the accumulation of hills in the file.
>> There may be some additional options to help with this in NAMD 2.9, I
>> can't
>> recall exactly, there might be old list messages with between myself and
>> Giacomo Fiorin that will have better information. But most of those
>> suggestions I guess are for starting a new simulation.
>>
>> Anyway, in essence what is happening is that when your colvar gets very
>> near your boundary, rather than writing the hill to the grids, the hill
>> must be written directly, otherwise a significant potion of the hill would
>> be ignored. Given enough time (i.e. build up of hills everywhere else)
>> the
>> metadynamics bias would push your system past the colvar boundary and it
>> would become trapped there, hence the need for those hills.
>>
>> I'm not sure exactly how to solve the problem once you've already started,
>> BUT, if you want to just test to make sure this IS the problem, that is
>> simple. Just open your .colvars.state file, delete all the hills from the
>> bottom, and try restarting your simulation. Not having the hills won't be
>> a problem for restarting, and you should get a sense of how the
>> performance
>> is comparing. Sadly you'll probably also see your system become trapped
>> outside the colvar boundary.
>>
>> ~Aron
>>
>> On Tue, Nov 13, 2012 at 2:47 PM, Marimuthu Krishnan <
>> marimuthu.krishnan_at_googlemail.com> wrote:
>>
>> > Aron,
>> >
>> > I do not use NAMD benchmarking to evaluate the performance. I simply use
>> > the trajectory length obtained in 24 hours as a measure of performance.
>> >
>> > The *.colvars.state files are > 10 MB and in some cases it is even
>> greater
>> > than 20 MB. The "usegrids" option is ON by default. I use default
>> values
>> > for 'hillwidth' and 'hillweight'. Although one could vary 'hillwidth'
>> and
>> > 'hillweight' to achieve better performance/accuracy, it is not clear to
>> me
>> > why restart runs perform poor than new runs for same values of
>> 'hillwidth'
>> > and 'hillweight'. Do you have some suggestions for me to improve the
>> > performance of restart runs at this point?
>> >
>> > You are correct. I see a massive list of hills at the bottom of the
>> > *.colvars.state file.
>> >
>> > By the way, I am not sure whether to keep 'rebinGrids' ON or OFF for
>> > restart runs. I have kept it 'OFF' (default value). Does it play any
>> role
>> > in the performance?
>> >
>> > best,
>> > Krishnan
>> >
>> >
>> > On Tue, Nov 13, 2012 at 11:47 AM, Aron Broom <broomsday_at_gmail.com>
>> wrote:
>> >
>> >> One possibility is that the performance decrease is actually
>> continuous.
>> >> You should have a *.colvars.state file, how large is it?
>> >>
>> >> If you're saying the performance decreases because of the NAMD
>> >> benchmarking that happens at the beginning of the run, this won't be
>> >> accurate in the case where your *.colvars.state file becomes very large
>> >> (i.e. > 10MB) during the course of the simulation. What you'll see in
>> that
>> >> case is a gradual decrease in performance over time, so make sure your
>> >> performance numbers are based on timings taken throughout the
>> simulation
>>
>
>
This archive was generated by hypermail 2.1.6 : Mon Dec 31 2012 - 23:22:15 CST