Hi Scott, Ross, and Jason,
Thanks for the quick replies.
I thought i remembered the imin=5 option from the "old days", but browsing the manual I must have overlooked it.
I like this option and also calculating it from restart files. I’ll give both options a run...
Monitoring the density makes a lot of sense too and I’ll give that a shot as well.
I certainly can appreciate not wanting to make the code more complex and with these options above readily available I don’t think it makes any sense either.
Best,
Jesper
> Yes that would be my suggestion as well. Either save all your restarts or
> just use the frames in the trajectory file. You 'should' be able to pass
> these into sander using imin=5 and calculate the pressure for each frame -
> I think... You'll need to try it and see (it may need some code tweaking)
> but one should be able to get sander to calculate you the pressure for
> each frame in a trajectory file.
> On Nov 5, 2014, at 10:47 AM, Jason Swails <jason.swails.gmail.com> wrote:
>
> On Wed, 2014-11-05 at 18:18 +0000, Sorensen, Jesper wrote:
>> Hi Jason,
>>
>> I’d like to follow up on this… Is there a way in post-processing to
>> recalculate the pressure?
>
> Sure. Do a single-point calculation for each of the frames in your
> trajectory. I think if you request an mden file, it will print out the
> pressure there.
>
> Otherwise, you can request a 1-step NPT calculation for each frame,
> which will print out the pressure (unless you're using the MC barostat
> in pmemd, obviously).
>
>> I set the pressure with the Berendsen barostat first before switching
>> to MC, so I imagine that it’s where I’d like it to be on average (I
>> realize it fluctuates a lot), but it’d still be nice to check that it
>> hasn’t diverged too much due to unforeseen events…
>
> I still maintain that the density is a better property to track than the
> pressure. That was one of my tests I used to validate the MC barostat
> implementation.
>>
>> Is it not possible to asynchronously compute the virial for the energy
>> output using pmemd.cuda maybe by throwing it to the CPU similar to
>> writing files? This way the simulation can proceed, keeping it’s
>> efficient speed, yet outputting this property similar to the Berendsen
>> barostat… I guess this would also be a good question for Ross Walker
>> since it involves the GPU version of pmemd.
>
> I can almost guarantee that this won't happen, as the work involved is
> considerable. As I understand it, launching GPU kernels is a blocking
> action (that is, you _must_ wait for the kernel to finish/return before
> progressing). So you would have to start a new thread to do this, which
> opens up a whole new can of worms (I don't think any of the major
> routines in pmemd are thread-safe, for instance). Not to mention that a
> lot of changes would be necessary to even permit energy calculations to
> be performed on the CPU in pmemd.cuda in the first place.
>
> In summary, it's possible "in principle", but impractical in pmemd.cuda.
> Developer (i.e., Scott's ;) time would be better spent on other
> improvements when working on pmemd.cuda.
>
> HTH,
> Jason
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Nov 05 2014 - 12:30:02 PST
