- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Jason Swails <jason.swails.gmail.com>

Date: Mon, 6 Feb 2017 20:52:06 -0500

On Sat, Feb 4, 2017 at 8:59 AM, Abhilash J <md.scfbio.gmail.com> wrote:

*> Hi Elvis and others,
*

*>
*

*> I also did not find a way to separate the two calculations. What i am
*

*> saying is:
*

*> 1. Is such a separation possible by making a some changes in source
*

*> code and recompiling. If it is not too technical i am willing to try.
*

*>
*

Possible, yes. Easily... maybe? But I wouldn't guarantee it.

*> 2. Will it be possible to incorporate such a change in future releases
*

*> of AMBER.
*

*>
*

Unlikely.

*> I just found an example to illustrate my point. Let me share it.
*

*> Following is the result of GB+Entropy calculations on a 350ns run on a ~280
*

*> residue protein with 5 threads.
*

*>
*

*> Timing:
*

*> Total setup time: 0.000 days
*

*> Creating trajectories with cpptraj: 0.026 days
*

*> Total calculation time: 2.368 days
*

*>
*

*> Total GB calculation time: 1.587 days
*

*> Total quasi-harmonic calculation time: 0.746 days
*

*> Statistics calculation & output writing: 0.000 days
*

*> Total time taken: 2.394 days
*

*>
*

*>
*

*> Enthalpy calculation took 1.587 days i.e. double of entropy (.7 days).
*

This isn't actually a very good example. quasi-harmonic entropy

calculations involves the diagonalization of a *single* matrix. It calls

cpptraj to build a mass-weighted covariance matrix from all of the frames,

diagonalizes it, and pulls out the eigenvalues as quasi-normal mode

frequencies.

This calculation runs on a single thread. Always. So the only thing that

is parallelized here is your enthalpy calculation.

The only RAM-intensive entropy calculation that will limit the number of

threads you can run on due to memory considerations are normal mode

calculations. And if done right, the normal mode calculations will take

*much* longer than any GB calculation so as to make the enthalpy part

virtually negligible. Even analyzing 10% of the frames for normal mode, I

would expect a 350 ns simulation in which you analyze every frame with GB

and every 10 with normal modes to take weeks. In light of that, 1.5 days

hardly seems important :). After all, you can (roughly) estimate the

quasi-harmonic calculation time as the amount of time it takes to do a

single frame with normal mode analysis. So you would just need to do 6-10

frames with normal modes on 5 CPUs to get the entropy calculation to take

just as long as the GB took (with presumably many tens of thousands of

frames).

That said, you are almost certainly analyzing too many frames. Since you

have already done the full calculation, I would suggest trying to analyze

every 10, 100, and 1000 frames and see if you can even detect a

statistically significant difference in the results.

And of course, you can always split the parallelization of the enthalpy

and entropy parts by running them in separate MMPBSA.py.MPI calculations if

you need to :).

HTH,

Jason

Date: Mon, 6 Feb 2017 20:52:06 -0500

On Sat, Feb 4, 2017 at 8:59 AM, Abhilash J <md.scfbio.gmail.com> wrote:

Possible, yes. Easily... maybe? But I wouldn't guarantee it.

Unlikely.

This isn't actually a very good example. quasi-harmonic entropy

calculations involves the diagonalization of a *single* matrix. It calls

cpptraj to build a mass-weighted covariance matrix from all of the frames,

diagonalizes it, and pulls out the eigenvalues as quasi-normal mode

frequencies.

This calculation runs on a single thread. Always. So the only thing that

is parallelized here is your enthalpy calculation.

The only RAM-intensive entropy calculation that will limit the number of

threads you can run on due to memory considerations are normal mode

calculations. And if done right, the normal mode calculations will take

*much* longer than any GB calculation so as to make the enthalpy part

virtually negligible. Even analyzing 10% of the frames for normal mode, I

would expect a 350 ns simulation in which you analyze every frame with GB

and every 10 with normal modes to take weeks. In light of that, 1.5 days

hardly seems important :). After all, you can (roughly) estimate the

quasi-harmonic calculation time as the amount of time it takes to do a

single frame with normal mode analysis. So you would just need to do 6-10

frames with normal modes on 5 CPUs to get the entropy calculation to take

just as long as the GB took (with presumably many tens of thousands of

frames).

That said, you are almost certainly analyzing too many frames. Since you

have already done the full calculation, I would suggest trying to analyze

every 10, 100, and 1000 frames and see if you can even detect a

statistically significant difference in the results.

And of course, you can always split the parallelization of the enthalpy

and entropy parts by running them in separate MMPBSA.py.MPI calculations if

you need to :).

HTH,

Jason

-- Jason M. Swails _______________________________________________ AMBER mailing list AMBER.ambermd.org http://lists.ambermd.org/mailman/listinfo/amberReceived on Mon Feb 06 2017 - 18:00:02 PST

Custom Search