Hi David,
Yes, I understand that I can reprocess with sander to get energies that correspond to the trajectory coordinates. This is fine for sander-generated trajectories, but I am more concerned about generating trajectories with other programs, specifically the GPU-accelerated pmemd.cuda and sander_openmm. As I understand it, pmemd.cuda energies might be slightly different because of precision issues (probably negligible) but sander_openmm has a different surface area methodology altogether. Unless I am missing something, that means it is impossible to use sander to get energies that were used during sander_openmm dynamics (and are relevant to importance sampling); this is why it would be helpful to have the energies output during the run correspond to the coordinates output during the run.
Thanks,
David
On Mar 9, 2012, at 8:37 PM, David Case wrote:
> On Mar 9, 2012, at 4:47 PM, David Minh <daveminh.gmail.com> wrote:
>
>> As a test, I ran a short trajectory with sander and then used sander to reprocess the same trajectory to try to get the same energies. The prmtop and inpcrd files were the same. It was disturbing to see that the energies were different.
>>
>> In any case, is there a way to ensure that energies in the mdout file are consistent with the energies of the coordinates in the mdcrd file?
>
> You've done it: use the imin=5 option, and you will get the energies that correspond to the
> Coordinates in the mdcrd file. Try short runs with ntpr=1 to see more about what is going on.
> You should also be able to use the ntwe option to dump energies, although I have never done that myself....
>
> ...dac
>
> _______________________________________________
> 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 Fri Mar 09 2012 - 18:30:03 PST
