CHARMM Development Project Forums User Discussion & Questions Installation and Testing Any way to speed up GBSW?

Hi All,
I'm new to using the GBSW implicit solvent model. I ran a test simulation with GBSW implicit solvent model and find that the CPU time usage is very low:
$$$$$ JOB ACCOUNTING INFORMATION $$$$$
ELAPSED TIME: 6.10 MINUTES
CPU TIME: 0.04 SECONDS

Wall clock is around 6 minutes, while CPU time is less then 6 seconds. I assume this is because of the volume calculations that are carried out in GBSW(?).

I was wondering if there was some way I could speed up my simulations, maybe use a different set of parameters in my script (see below)? Any suggestions would be appreciated.

Thanks,
Ed


set nx 1
set ny 3
set nz 4
calc a @nx*175 ! in angstroms
calc b @ny*28.003 ! assume a monoclinic crystal
calc c @nz*17.346
set cryscut 175 ! crystal cutoff
set alpha 90.00
set beta 96.24
set gamma 90.00
set steps 250000
set timestp 0.002
set temp 300
!set rand 50659391
set fbsolu 50.0
set cut 21.0 ! cutoff for non-bond and images

open unit 20 read card name @top
read rtf card unit 20
close unit 20

open unit 20 read card name @parm
read para card unit 20
close unit 20

! Get psf
read psf card name @psf

! Get the coordinates
open read unit 3 card name @strt
read coor card unit 3
close unit 3

! define the crystal lattice type and geometry
crystal define monoclinic @a @b @c @alpha @beta @gamma

! build the crystal along with the images within the cutoff
crystal build Noper 0 cutoff @cryscut

!create nonbond list
update
image bysegment sele .not. resname CW1 end xcen 0.0 ycen 0.0 zcen 0.0
image byatom sele resname CW1 end xcen 0.0 ycen 0.0 zcen 0.0
update inbfrq 1 ihbfrq 0 imgfrq 1 cutim @cut

! activate GBSW
nbond atom switch cdie vdw vswitch -
ctonnb 19 ctofnb 19 cutnb @cut

prnlev 0
stream ../setup_c22/radius_gbsw.str
prnlev 3
scalar wmain statistics select .not. type H* end
define check select (.not type H* ) .and. ( property wmain .eq. 0.0 ) show end
if ?nsel ne 0 stop !some heavy atom have a zero radius

! ativate GBSW energy term
gbsw sgamma 0.005 nang 50

cons fix sele (.not. resname CW1).and.(.not. segid free) end

!turn on SHAKE of all covalent bonds involving hydrogen
SHAKE bonh param

! Set friction forces
scalar fbeta set @fbsolu

! kinetics
open unit 12 write form name output/@OUT.res
open unit 21 write unform name output/@OUT.dcd
open unit 22 write form name output/@OUT.mon

dyna leap langevin strt nstep @steps timestep @timestp -
iprfrq 0 ieqfrq 0 ntrfrq 0 -
iunwri 12 iuncrd 21 iunvel -1 kunit 22 -
ihtfrq 0 teminc 0 nprint 500 nsavc 500 nsavv 0 ihbfrq 0 -
inbfrq -1 imgfrq -1 -
ilbfrq 0 - ! and step frequency for writing restart file
rbuffer 0.0 tbath @temp -
firstt @temp finalt @temp -
iasors 0 iasvel 1 iscvel 0 ichecw 0 twindh 0.0 twindl 0.0 iseed @rand -
cutim @cut echeck 100000000

I've seen wrong CPU timing reports for a long time and they seem to appear independently of the type of calculations being performed. But I didn't care too much because the elapsed time is (for me) more important, as it represents the real (clock) time that was needed to finish the calculation. The CPU time is normally useful only when oversubscribing a computer (f.e. running 4 identical CHARMM jobs on a computer with 1 CPU will yield, for each of the jobs, an elapsed time that is 4 times larger than the CPU time).

Try an alternate timing method, such as the command TIME NOW before the calc and TIME DIFF afterwards; that's the way I do CHARMM benchmark tests.