RE: Colvars simulation running slow?

From: Tristan Croll (tristan.croll_at_qut.edu.au)
Date: Wed Sep 10 2014 - 17:15:35 CDT

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