[gmx-users] FEP and loss of performance
Justin A. Lemkul
jalemkul at vt.edu
Mon Apr 4 18:48:04 CEST 2011
Chris Neale wrote:
> >> Dear Chris and Justin
>>>/ Thank you for your precious suggestions
> />>/ This is a test that i perform in a single machine with 8 cores
> />>/ and gromacs 4.5.4.
> />>/ I am trying to enhance the sampling of a protein using the decoupling scheme
> />>/ of the free energy module of gromacs. However when i decouple only the
> />>/ protein, the protein collapsed. Because i simulated in NVT i thought that
> />>/ this was an effect of the solvent. I was trying to decouple also the solvent
> />>/ to understand the system behavior.
>>Rather than suspect that the solvent is the problem, it's more likely that
>>decoupling an entire protein simply isn't stable. I have never tried anything
>>that enormous, but the volume change in the system could be unstable, along with
>>any number of factors, depending on how you approach it.
>>If you're looking for better sampling, REMD is a much more robust approach than
>>trying to manipulate the interactions of huge parts of your system using the
>>free energy code.
> Presumably Luca is interested in some type of hamiltonian exchange where lambda represents the interactions between the protein and the solvent?
> This can actually be a useful method for enhancing sampling. I think it's dangerous if we rely to heavily on "try something else". I still see no methodological
> reason a priori why there should be any actual slowdown, so that makes me think that it's an implementation thing, and there is at least the possibility that this is
> something that could be fixed as an enhancement.
Then perhaps we can get some clarification. Based on the earlier .mdp snippet:
free_energy = yes
init_lambda = 0.9
delta_lambda = 0.0
couple-moltype = Protein_Chain_P
couple-lambda0 = vdw-q
couple-lambda0 = none
It looked to me as if the intent was to decouple some protein complex from the
system by simultaneously annihilating all solute-solvent and solute-solute
nonbonded interactions (which comes with its own set of methodological issues -
stability, convergence, etc).
>>/ I expected a loss of performance, but not so drastic.
> />/ Luca
> />>/ Load balancing problems I can understand, but why would it take longer
> />>/ in absolute time? I would have thought that some nodes would simple be
> />>/ sitting idle, but this should not cause an increase in the overall
> />>/ simulation time (15x at that!).
> />>/ There must be some extra communication?
> />>/ I agree with Justin that this seems like a strange thing to do, but
> />>/ still I think that there must be some underlying coding issue (probably
> />>/ one that only exists because of a reasonable assumption that nobody
> />>/ would annihilate the largest part of their system).
> />>/ Chris.
> />>/ Luca Bellucci wrote:
> />>>/ / Hi Chris,
> />>/ />/ thank for the suggestions,
> />>/ />/ in the previous mail there is a mistake because
> />>/ />/ couple-moltype = SOL (for solvent) and not "Protein_chaim_P".
> />>/ />/ Now the problem of the load balance seems reasonable, because
> />>/ />/ the water box is large ~9.0 nm.
> />>/ /
> />>/ Now your outcome makes a lot more sense. You're decoupling all of the
> />>/ solvent? I don't see how that is going to be physically stable or terribly
Justin A. Lemkul
ICTAS Doctoral Scholar
Department of Biochemistry
jalemkul[at]vt.edu | (540) 231-9080
More information about the gromacs.org_gmx-users