Re: [AMBER] copy charges using Python API

From: William Lees <william.lees.org.uk>
Date: Tue, 9 Aug 2016 10:07:50 +0100

GNU Parallel is useful for this kind of thing too. It has an xargs
compatible syntax. It also has a semaphore method which I find more
intuitive in many cases. for example the following will run a maximum of
8 echoes in parallel (-j8):

for i in `seq 1 20` ; do
     sem -j8 sleep 2 ";" echo $i
done
sem --wait

It will run across multiple machines using ssh.

http://www.gnu.org/software/parallel/

All the best

William

William Lees
Associate Research Fellow
Institute of Structural and Molecular Biology
Birkbeck, University of London
http://shepherd-group.ismb.lon.ac.uk





On 07/08/2016 14:05, Jason Swails wrote:
> 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
>


_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Aug 09 2016 - 02:30:02 PDT
Custom Search