From: Tristan Croll (tristan.croll_at_qut.edu.au)
Date: Wed Sep 10 2014 - 19:51:15 CDT
... and now I see I’m just running over old ground. Sorry – I did do a search, but obviously didn’t hit the right keywords. For anyone that comes across this thread in future, the problem (as hashed out in detail here: http://www.ks.uiuc.edu/Research/namd/mailing_list/namd-l.2013-2014/3007.html) is that the colvars calculations are running on a single core).
From: owner-namd-l_at_ks.uiuc.edu [mailto:owner-namd-l_at_ks.uiuc.edu] On Behalf Of Tristan Croll
Sent: Thursday, 11 September 2014 8:16 AM
To: Jérôme Hénin
Cc: namd-l_at_ks.uiuc.edu
Subject: RE: namd-l: Colvars simulation running slow?
Hi Jerome,
Thanks for this. By being a bit more selective I cut the number of atoms in each group down from 1500 to 380, and I’m back to about 75% of previous speed (which I can happily live with). I’ll watch out for that in future – just hadn’t expected such a large hit considering my overall system is ~400k atoms...
Cheers,
Tristan
From: heninj_at_gmail.com [mailto:heninj_at_gmail.com] On Behalf Of Jérôme Hénin
Sent: Wednesday, 10 September 2014 5:13 PM
To: Tristan Croll
Cc: namd-l_at_ks.uiuc.edu
Subject: Re: namd-l: Colvars simulation running slow?
Hi Tristan,
It is likely that NAMD was just about scaled out in your previous setup, and the extra communication necessary to gather the coordinates of 1500 atoms is killing that scaling. Effectively, you are introducing long-range interactions involving a large number of atoms. The only way out of this is to reduce the number of atoms involved.
Best,
Jerome
On 10 September 2014 03:31, Tristan Croll <tristan.croll_at_qut.edu.au<mailto:tristan.croll_at_qut.edu.au>> wrote:
Hi all,
I’m currently running what’s effectively a TMD simulation based on the colvars file pasted in below. Briefly, I have two domains which were previously steered to within ~30 angstroms between their centres of mass, and are now allowed to rattle around within a wall at 31 angstroms. That initial steering simulation ran well (and fast) even with the inclusion of four individual RMSD colvars with harmonic restraints maintaining the internal fold of individual domains.
In the current phase, I’m steering two other groups of atoms – one of which I’m maintaining to the geometry it “found” during the previous phase of the simulation, while the other is steered to a matching configuration over 20ns. There’s nothing fundamentally different about this simulation from what I’ve done to date, yet it’s consistently running ~8-fold slower. Just wondering what might be causing this? The only real differences I see are the number of atoms in each colvar (~1500 in this case vs ~50 previously – I’m steering all heavy atoms this time around, rather than just restraining CAs), and the fact that while the individual atoms in each of the current colvars I’m steering are fairly close in 3D space, they’re up to a few thousand residues apart in the sequence.
Is this slowdown likely to be a consequence of my setup, or should I look more closely at the cluster? The managers of it assure me there’s nothing currently going wrong there...
Thanks,
Tristan
colvarsTrajFrequency 1000
colvarsRestartFrequency 1000
colvar {
name Fn_distance
outputAppliedForce on
upperWall 31.0
upperWallConstant 10
distance {
group1 {
atomsfile colvars.pdb
atomsCol O
atomsColValue 1.0
}
group2 {
atomsfile colvars.pdb
atomsCol O
atomsColValue 2.0
}
forceNoPBC yes
}
}
colvar {
name RMSD_ID_E
rmsd {
atoms {
atomsfile target_ID_sym.pdb # Select biased atoms from this file
atomsCol B # based on beta
atomsColValue 1.0
}
refPositionsFile target_ID_sym.pdb # ref. positions are selected based on atom number
}
}
harmonic {
name ID_E_restrain
colvars RMSD_ID_E
centers 0
targetCenters 0
targetNumSteps 25000000
forceConstant 10
}
colvar {
name RMSD_ID_F
rmsd {
atoms {
atomsfile target_ID_sym.pdb # Select biased atoms from this file
atomsCol B # based on beta
atomsColValue 2.0
}
refPositionsFile target_ID_sym.pdb # ref. positions are selected based on atom number
}
}
harmonic {
name ID_F_steer
colvars RMSD_ID_F
centers 4.8
targetCenters 0
targetNumSteps 10000000
forceConstant 10
}
This archive was generated by hypermail 2.1.6 : Wed Dec 31 2014 - 23:22:50 CST