Hi Trevor,
Ack, for some reason I though util.py was bytecode.... I made the change in
> util.py already.
>
The makefile only moves the compiled bytecode into $AMBERHOME/bin after its
compiled during the make process, so you'll have to re-run "make" after you
make those changes.
> I don't have hard numbers but when I changed all trajouts to include
> netcdf, I got huge speed ups which actually negated the need to run the mpi
> version. I say this because the mpi version bogged my PC and made it
> practically unusable (using openmpi 1.4.2 and latest mpi4py at the time of
> this writing). That being said, I'm glad you pointed me to edit util.py
> because converting my trajectories to ascii felt backwards.
>
Well after you make the changes for netcdf, there's no reason you can't use
the MPI version, also. One caveat about using the MPI version is that each
thread does a fair bit of I/O, so if you're trying to run 8 threads on a
single machine, you're probably going to be thrashing the hard disk while
everyone is trying to access files at once, akin to using parallel ptraj on
a non-parallel file system I'd think. I'd be interested to see how much
faster netCDF is when you run the serial version as opposed to the parallel
version, or if you were to run the MPI version on a machine with a lustre
filesystem or something. Implementing mpi4py into MMPBSA.py was primarily
done to aid PB and nmode calculations which each take a long long time and
is not directly parallelizable in sander or nab, respectively. GB is so
fast that there's rarely a good reason to use MMPBSA.py.MPI for MM/GBSA,
unless for some reason you want to analyze thousands of frames.
> However, we didn't really think the performance
> increase of using netcdf warranted inclusion (since if coordinate reading
> is
> the RDS, then it's pretty fast anyway ;) ).
>
>
> > General question: how are the total energies calculated for the pb
> method?
> > Gb looks straightforward because everything needed to calculate the total
> > energy is listed in the final mmpbsa.py output. As for pb... an energy
> term
> > that is used to calculate the final energy is missing from the total, or
> > mmpbsa and I disagree on how to do general floating point arithmetic.
> >
>
> It's done in the same way that GB is. However, depending on your
> "verbosity" setting, you can avoid printing a lot of redundant data. For
> instance, for single-trajectory simulations, the bonded terms (including
> 1-4
> interactions) must cancel or something has gone wrong. Therefore, they are
> not printed by default (but they ARE checked for consistency and printed if
> inconsistent). If they're not printed, they're subtracted from the
> reported
> total. Only by setting verbose=2 in the input file will give you complete
> agreement between the _MMPBSA_complex/receptor/ligand_pb.mdout files and
> the
> final output file. Furthermore, G gas is the sum of the gas-phase terms
> (VDWAALS, EEL, and the bonded terms if they're included) and G solv is the
> sum of the solution phase terms (EPB and ECAVITY or EGB and ESURF for
> pb/gb,
> respectively). Thus, all of the terms that come before the "total" should
> add up to exactly twice the total, since that's what's added together. I
> just checked it for amber11 by running the test files.
>
> Now that I should have a functional patched netcdf version I should be able
> to see what verbose=2 gives me (in short time!). The reference to my
> question was the output given in your tutorial
> http://ambermd.org/tutorials/advanced/tutorial3/py_script/section2.htm
> The G gas and solv for pb don't match up with the total which was
> concerning because I was looking to post-process without the script. I'm
> assuming/hoping the energies will pan out when the verbosity is increased
> per your response. I was using the script from that tutorial.
>
Bahh, these have to be updated, I think. There was a point in time when the
addition was NOT done properly (or rather, the values not reported were NOT
subtracted from the total), but that has long since been fixed. We must not
have run new calculations to replace the values on the tutorial website.
Rest assured that is fixed now (at least in the version I just used to
verify it).
Thanks!
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Sep 16 2010 - 14:00:05 PDT
