> 5. Istvan reports that there will be a new release of desmond within the next
> month or so, but that it will not have major changes from what is available
> now. Still, if you thinking of playing with this, you might want to hold off
> until the newer version is available.
I ran tests with this system on our cluster, but since the hardware is
different, the absolute numbers are irrelevant. I have a few
suggestions. I attached my .cfg file for reference. I have not changed
any of the parameters, but turned off most of the I/O and the
so-called Glue option (to keep members of a complex together in the
trajectory file that got "separated" by PBC) since the water molecules
are free to diffuse wherever they want. Depending on your file system,
etc., Desmond performance can be severely affected by I/O and thus
biasing benchmark results. I also noticed that RESPA schedule was set
to 1:1:1 and I didn't change that. I don't know if PMEMD does multiple
time step integration, but it is the normal way of running Desmond and
with a 2 fs inner time step, the Desmond schedule should be 1:1:3,
which runs about 25% faster.
Other comments:
You can set the global cell partition in the .cfg file to [0 0 0] in
which case Desmond will figure out the ideal spatial decomposition
based on the number of CPUs requested.
When you say using 16 *threads*, did you mean 16 processes/cores? This
is what you set with the -P option. If you want to run multiple
threads per process use the -tpp option on the same command line.
There is also a -noopt option to make sure that the desmond script
will not apply "automatic optimization of cfg parameters". This was
not an issue here, but with more subtle settings you may want to use
this option to make sure that Desmond runs with your parameters. (If
you look at the working directory, you'll find a jac_desmond-out.cfg
file and that is the one actually read by Desmond.) So you could for
example run the test via:
$SCHRODINGER/desmond -HOST gyges -P 16 -tpp 2 -noopt -c
jac_desmond.cfg -in jac_desmond.cms
Desmond 2.4 is about 10% faster than Desmond 2.2, but I only tested it
with the upcoming source release, not the Maestro binary.
Double precision Desmond is much slower (you can invoke it with the
-dp option), but we consider DP only for debugging purposes. One of
the main efforts with Desmond was to run it in SP and still achieve
(almost) DP accuracy.
Istvan
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Jul 25 2010 - 18:30:03 PDT
