I forgot to mention, that once you create the hierarchy once with the hdf5 file, you can load the new coordinates into the existing hierarchy.
On Mar 22, 2011, at 10:52 PM, Dave Barkan wrote:
> I use read_particles_binary to read MD trajectories. Here I am loading > different coordinates many times into the same existing particle > hierarchy. I only need the coordinates for each step until I load the > next step, so conceivably I could create a new hierarchy each step and > process the coordinates before reading the next step. I sort of like how > it works now, but I agree that the NetCDF requirement is a pain. > > On 3/22/11 4:45 PM, Daniel Russel wrote: >> Now that there is the the hdf5 based I/O support in IMP, I would propose moving towards getting rid of the old I/O functions IMP::read_particles IMP::write_particles, IMP::read_particles_binary, IMP::write_particles_binary as I think they are little used, complicated and the last two require NetCDF to work. >> >> The new format is a very different IO model than the kernel function in that it creates new particles upon read rather than loading the data into an ordered list of existing particles. I think this makes for more resilient code as adding a new particle doesn't make you unable to load your old data. >> >> The advantages of the new format include: >> - the ability to create molecular hierarchies and particles upon reading (similar to what happens with read_pdb) >> - better control for loading and saving multiple conformations of the same set of particles >> - the ability to write and read display::Geometry objects >> - the ability to go directly from atom::Hierarchies in a file to things that can be displayed in Chimera/Pymol via the command line >> - the ability to print out molecular hierarchies in the file directly from the command line >> >> >> In doing this, one would, at least for the moment, loose the ability to read and write ConfigurationSets in one go, but that could be easily added if desired. However, I'm not sure that writing things in such a raw way is really that desirable. >> >> Thoughts? >> >> Anyway, I encourage people to try out the module. >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev