Re: [AMBER] copy charges using Python API

From: Jason Swails <jason.swails.gmail.com>
Date: Sun, 7 Aug 2016 09:05:35 -0400

On Sun, Aug 7, 2016 at 7:28 AM, Thomas Evangelidis <tevang3.gmail.com>
wrote:

> Hello,
>
> ​Is it possible to read a mol2 file with charges and copy them to another
> mol2 file of the same molecule but with different coordinates using a
> python API (e.g. parmed, ptraj, etc.)? Alternatively, is it possible to
> copy the coordinates from a mol2 file to another, but leaving the charges
> unaltered?
>

​ParmEd should be capable of both of these things.

For example:

import parmed as pmd

m1 = pmd.load_file('first.mol2')
m2 = pmd.load_file('second.mol2')

# Transfer charges from second.mol2 to first.mol2
for a1, a2 in zip(m1.atoms, m2.atoms):​

    a1.charge = a2.charge

# Transfer coordinates from first.mol2 to second.mol2
​m2.coordinates = m1.coordinates

# Note that you must have the same number of atoms in the same order
# for any of this to work

# Save file format based on "mol2" extension
m1.save('first_modified.mol2')
m2.save('second_modified.mol2')​

Another question: is anyone aware of any effort made to parallelize
> antechamber computations? I want to screen a database using bcc charges.
>

​Not parallelize within antechamber. But there are ways of doing this at
the shell level. If you are doing some kind of database for this, "xargs"
is actually a great way to parallelize. You can tell it how many
processors to use, and it will run through a list of arguments and dispatch
it to the target program. Once one job finishes, it will pull the next one
from the queue and dispatch it to the program (making sure never to have
more than the requested number of jobs active at a time).​

The man page and googling for examples will show you how to use it. I've
personally used it in AF-NMR to process each snapshot in a multi-model PDB
file in parallel. You can see this here:
http://casegroup.rutgers.edu/shifts-5.1.tar.gz (look for 'mulitafnmr.sh').

You will probably also have to wrap antechamber in a shell script to make
sure that each antechamber run runs in a separate directory to avoid
collisions of intermediate files.

There is another way to do it through the shell, but it's not as
efficient. You can do something like this:

cd dir1
antechamber <args> &
cd ../dir2
antechamber <args> &
cd ../dir3
antechamber <args> &
cd ../dir4
antechamber <args> &
cd ..

wait

cd dir5
antechamber <args> &
...


This has the effect that 4 jobs will run at a time, but the next group of 4
will only proceed when each of the previous group finishes (rather than
xargs, where it uses a queue-like approach to make sure processors are
rarely idle).


HTH,
Jason

-- 
Jason M. Swails
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun Aug 07 2016 - 06:30:03 PDT
Custom Search