From: Brian Radak (brian.radak_at_gmail.com)
Date: Thu Apr 29 2021 - 07:17:24 CDT
I don't know about namd3 gpu support, but, for what it's worth, namd2 gpu
support should already exist.
If you are only interested in one residue then constant-pH MD is probably
not a very efficient approach - I would just enumerate all protonation
states and run standard alchemical FEP. The cost statement about number of
residues was meant to reflect overall sampling cost, not computational
cost. That latter depends entirely on system size.
The cphMaxProposalAttempts keyword is deprecated, bc it usually leads to
detailed balance violations - thanks for pointing out that this is still in
the manual (it should not be). It's fixed at one because that's the only
value that should work. If you want more switch attempts then increase the
On Wed, Apr 28, 2021, 7:54 PM Smith, Harper E. <
> Hi mailing list,
> First, does anyone know if there are plans to allow GPU support for
> constant-pH simulations?
> I read that the computational expense of constant-pH simulations scales as
> the number of titratable sites (
> My protein of interest has 65 titratable residues (127,352 atoms), but I
> only care about one. I have selected 8 more in the vicinity and used the
> keyword "cphExcludeResidue" to prevent the others from being considered,
> but my simulation is about the same speed after adding those exclusions
> (something like 300 cycles of 5 ps each in 20 hours for 9 replicas on 144
> cores -- is this reasonable?). I am running namd2.13b2.
> The documentation says the maximum number of switch proposal attempts per
> cycle defaults to the number of residues, so I lowered
> cphMaxProposalAttempts to 9. However, my log files all include the lines:
> TCL: namdcph) CONSTANT pH neMD/MC MOVES:
> TCL: namdcph) MAX. ATTEMPTS PER CYCLE: 1
> TCL: namdcph) ONE RESIDUE MOVES
> What is going on here? Is the log file wrong? Am I wrong to think that my
> simulations should speed up when less residues are considered for
> protonation events?
> Harper Smith
This archive was generated by hypermail 2.1.6 : Fri Dec 31 2021 - 23:17:11 CST