Hi,
Glad you were able to resolve the issue. Just to clarify, 'last' and
'lastframe' are indeed only supported by CPPTRAJ, but they each mean a
different thing:
last - Can be used in place of the <stop> argument as a substitute for
the final frame #.
lastframe - Means "use only the last frame", i.e. any other frame args
are ignored so only one frame (the final one) is used.
-Dan
On Fri, Mar 15, 2013 at 4:08 AM, Miguel Ortiz Lombardía
<miguel.ortiz-lombardia.afmb.univ-mrs.fr> wrote:
> Le 14/03/13 16:31, Miguel Ortiz Lombardía a écrit :
>> Hi all,
>>
>> I have a weird problem with ptraj (not cpptraj). I am trying to analyse
>> hydrogen bonds and water bridges on a trajectory comprising 2500 frames
>> over 25 files (100 frames per file). I have carried out this analysis on
>> two computers:
>>
>> 1. OS: OSX 10.6.8 (Snow Leopard Server) 64-bit
>> Compilers: intel 12.1.6 (gcc version 4.2.1 compatibility)
>> Amber 12 (patch level 15)
>> AmberTools 12 (patch level 35)
>> Configure: configure -macAccelerate (-mpi) intel
>>
>> 2. OS: Linux 2.6.32-220 (RHE Server 6.2) 64-bit
>> Compilers: GNU 4.4.6 20110731 (Red Hat 4.4.6-3)
>> Amber 12 (patch level 15)
>> AmberTools 12 (patch level 35)
>> Configure: configure -noX11 (-mpi) gnu
>>
>> In the first computer the analysis takes some time but all the frames
>> are processed. On the second computer the trajectory files are
>> apparently read and found to have 100 frames, but only one frame ('set')
>> is treated.
>>
>> This is from the output in the first computer:
>>
>> <...>
>>> PTRAJ: hbond distance 3.2 angle 135.0 print 0.02 solventdonor WAT O solventacceptor WAT O H1 solventacceptor WAT O H2 solventneighbor 12 hbfile u1e2h2_1_exdR_sol_prod01_watbrdg.dat avgfile u1e2h2_1_exdR_sol_prod01_hbavg.dat series hbt out u1e2h2_1_exdR_sol_prod01_hbt.dat
>>> [No output trajectory specified (trajout)]
>>> ../u1e2h2_1_exdR_sol_prod01_001.mdcrd: 100 frames.
>>> ../u1e2h2_1_exdR_sol_prod01_002.mdcrd: 100 frames.
>> <...>
>>> PTRAJ: Successfully read the input file.
>>> Coordinate processing will occur on 2500 frames.
>>> Summary of I/O and actions follows:
>>>
>>> INPUT COORDINATE FILES
>>> File (../u1e2h2_1_exdR_sol_prod01_001.mdcrd) is a NetCDF AMBER trajectory with box info with 100 sets
>>> File (../u1e2h2_1_exdR_sol_prod01_002.mdcrd) is a NetCDF AMBER trajectory with box info with 100 sets
>> <...>
>>
>> And this is the equivalent output from the second computer:
>>
>> <...>
>>> PTRAJ: hbond distance 3.2 angle 135.0 print 0.02 solventdonor WAT O solventacceptor WAT O H1 solventacceptor WAT O H2 so
>>> lventneighbor 12 hbfile u1e2h2_1_exdR_sol_prod_watbrdg.dat avgfile u1e2h2_1_exdR_sol_prod_hbavg.dat series hbt out u1e2h
>>> 2_1_exdR_sol_prod_hbt.dat
>>> [No output trajectory specified (trajout)]
>>> ../u1e2h2_1_exdR_sol_prod01_001.mdcrd: 100 frames.
>>> ../u1e2h2_1_exdR_sol_prod01_002.mdcrd: 100 frames.
>> <...>
>>> PTRAJ: Successfully read the input file.
>>> Coordinate processing will occur on 25 frames.
>>> Summary of I/O and actions follows:
>>>
>>> INPUT COORDINATE FILES
>>> File (../u1e2h2_1_exdR_sol_prod01_001.mdcrd) is a NetCDF AMBER trajectory with box info with 1 sets
>>> File (../u1e2h2_1_exdR_sol_prod01_002.mdcrd) is a NetCDF AMBER trajectory with box info with 1 sets
>> <...>
>>
>> Same input and command files in both cases.
>>
>> The second computer sees 100 frames per file but analyses just one of
>> them. In both cases I have results at the end, but of course they are
>> different.
>>
>> The reason I want to use the second computer is that this is an SMP
>> machine with a lot of memory where I could analyse three times this
>> number of frames (from 3 replicate production runs) The first computers
>> chokes on the resulting 7500 frames, giving a segmentation fault,
>> probably owing to lack of memory.
>>
>> Has anyone observed this behaviour before. Any ideas to overcome it?
>>
>> Best regards,
>>
>
> Hi again,
>
> It is still very weird, but I have solved the problem.
> My input file had trajin lines like:
>
>> trajin ../u1e2h2_1_exdR_sol_prod01_001.mdcrd 1 last 1
>> trajin ../u1e2h2_1_exdR_sol_prod01_002.mdcrd 1 last 1
> <...>
>
> Now, in the OSX machine and in a third machine (Linux) this poses no
> problem to ptraj, which simply sends out a:
>
>> WARNING in getArgumentInteger(): Scanning integer argument failed
>
> for each of these lines, but then carries out the calculations for all
> the frames.
>
> I found in the AMBER list archives that this arises from using
> "lastframe" in ptraj, whereas this option is only supported by cpptraj.
> Indeed, when I replaced 'last' by '100' (the number of frames per file)
> ptraj recognized 100 frames per file in all three machines.
>
> Why the 'last' option works with ptraj in two of these machines (an OSX
> and a Linux) but not in the third one (Linux) remains a mistery, but one
> I can now live with.
>
> Post this in case it helps others some day.
>
> Cheers,
>
> --
> Miguel Ortiz Lombardía
>
> Architecture et Fonction des Macromolécules Biologiques (UMR7257)
> CNRS, Aix-Marseille Université
> Case 932, 163 Avenue de Luminy, 13288 Marseille cedex 9, France
> Tel: +33(0) 491 82 55 93
> Fax: +33(0) 491 26 67 20
> mailto:miguel.ortiz-lombardia.afmb.univ-mrs.fr
> http://www.afmb.univ-mrs.fr/Miguel-Ortiz-Lombardia
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
--
-------------------------
Daniel R. Roe, PhD
Department of Medicinal Chemistry
University of Utah
30 South 2000 East, Room 201
Salt Lake City, UT 84112-5820
http://home.chpc.utah.edu/~cheatham/
(801) 587-9652
(801) 585-9119 (Fax)
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Mar 15 2013 - 09:00:05 PDT
