[gmx-users] FEP and loss of performance

[Justin A. Lemkul]

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
couple-intramol= yes

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).

-Justin

> Chris.
> 
> 
> -Justin
> 
>>/  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
Ph.D. Candidate
ICTAS Doctoral Scholar
MILES-IGERT Trainee
Department of Biochemistry
Virginia Tech
Blacksburg, VA
jalemkul[at]vt.edu | (540) 231-9080
http://www.bevanlab.biochem.vt.edu/Pages/Personal/justin

========================================