OK. OK. You all convinced me. I'm going to change my old habits.
Gerald.
On 06/17/2015 10:03 PM, Marion, Antoine wrote:
> Hi Gérald,
>
> I did the same tests as you did and got similar results for the files size.
> A compressed ascii file is smaller than the corresponding netcdf one.
>
> However, I agree with Prof. Case about the efficiency of post-processing netcdf files.
>
> Here are some timings for 200 frames of a ~160000 atoms system with PBC.
>
> For a series of distances and rmsd analysis using cpptraj :
> - ascii :TIME: Total execution time: 16.3310 seconds.
> - ascii.gz : TIME: Total execution time: 21.6712 seconds.
> - netcdf : TIME: Total execution time: 2.4660 seconds.
>
> The difference is also quite striking when loading a trajectory into a visualization program.
> Using vmd :
>
> -- ascii
>>> time vmd -parm7 md.prmtop -crdbox md.crd << eof
> quit
> eof
>
> real 0m34.124s
> user 0m33.038s
> sys 0m0.732s
>
> -- netcdf
>>> time vmd -parm7 md.prmtop -netcdf md.nc << eof
> quit
> eof
>
> real 0m2.132s
> user 0m1.657s
> sys 0m0.369s
>
> Also to run the trajectory itself, it feels like it is faster to write netcdf files.
> I cannot give you the exact timings since the two simulations ran on different machines and with different output setting for the velocities, but it seems so.
> Anyone else did such a comparison ?
>
> Best wishes,
>
> Antoine
> ________________________________________
> From: David A Case <case.biomaps.rutgers.edu>
> Sent: Wednesday, June 17, 2015 9:27 PM
> To: AMBER Mailing List
> Subject: Re: [AMBER] cpptraj : gzip or bzip2 netcdf trajectory files not recognized
>
> On Wed, Jun 17, 2015, Gerald Monard wrote:
>
>> What's the advantage, except size, of using the NetCDF format?
>
> Loading netcdf files into cpptraj can be *much* faster than uncompressing
> an ASCII file, then converting those to the internal representation.
>
> Second, code can skip frames efficiently, rather than having to read the
> intervening frames.
>
> Third, values are stored in floating point format, so you avoid the dreaded
> problem of finding '****' in the 5075'th frame.
>
> Fourth, you can skip corrupted frames (which *do* happen occasionally) much
> more robustly with netcdf than with ASCII.
>
> ....dac
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
____________________________________________________________________________
Prof. Gerald MONARD
SRSMC, Université de Lorraine, CNRS
Boulevard des Aiguillettes B.P. 70239
F-54506 Vandoeuvre-les-Nancy, FRANCE
e-mail : Gerald.Monard.univ-lorraine.fr
tel. : +33 (0)383.684.381
fax : +33 (0)383.684.371
web : http://www.monard.info
____________________________________________________________________________
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jun 17 2015 - 13:30:03 PDT
