On Mon, Nov 27, 2017 at 2:46 PM, Storm Weiner <stormwei...@berkeley.edu> wrote:
> Thanks for the advice. > > Barry, did you mean to add more information after that ":"? > > HDF5 sounds like a great option for my application, but I don't see much > information about how it interfaces with PETSc. All I can find are the > doc pages for a few viewer routines. Do you have a link to a more detailed > description? > > Specifically, I'd like to know if PETSc has automatically configured HDF5 > datatypes and how to access them. And if there is a standard way to make > compound data types derived from PETSc datatypes. In short, how much do > I need to muck around in HDF5 myself, and how much can I let PETSc take > care of? > You should be able to use HDF5 exactly as you would use the PETSc binary viewer and the filesystem. Instead of giving a directory and filename, you give a groupname http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Viewer/PetscViewerHDF5PushGroup.html and the filename is the object name. Then just call View(). We also allow you to write metadata about the object http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Viewer/PetscViewerHDF5WriteAttribute.html Matt > -Storm > > On Nov 26, 2017 5:49 AM, "Smith, Barry F." <bsm...@mcs.anl.gov> wrote: > >> >> Storm, >> >> Specifically for TS there is an abstract object called TSTrajectory >> which is a way to store histories of simulations (it is used by TSAdjoint >> but also useable for other purposes). It has several ways to store >> histories and more can be added. >> >> One draw back to saving everything in PETSc binary in one file is that >> we don't have simple support for random access of a particular vector. >> >> You can also store to HDF5 format and some others that may be useful >> for you: >> >> >> Barry >> >> >> > On Nov 26, 2017, at 2:27 AM, Jose E. Roman <jro...@dsic.upv.es> wrote: >> > >> > >> > >> >> El 26 nov 2017, a las 2:25, Storm Weiner <stormwei...@berkeley.edu> >> escribió: >> >> >> >> Hey there, >> >> >> >> For simulations, its useful to store the history as a series of state >> vectors. For simulations with many time-steps it can get annoying to store >> each state vector as a separate file. It would be useful if there were >> some way to manage a database of petsc vectors. To save the current >> time-step, append the state vector to the database. To restart a >> simulation, load the corresponding state vector out of the database. >> >> >> >> Is there a standard way to do this in PETSc? >> >> >> >> Thanks, >> >> Storm >> > >> > In the command line, you can use the “append” option for the viewer. >> For instance in the MFN solver in SLEPc you can do this: >> > $ ./ex23 -mfn_view_solution binary:vectors.bin::append >> > It will save one vector in each call to MFNSolve(), and all vectors >> will be stored in the same file ‘vectors.bin’. >> > >> > Alternatively, in the source code you can use PetscViewerBinaryOpen() >> to open the viewer, then save as many vectors as you want with VecView(), >> and finally close the file with PetscViewerDestroy(). Use VecLoad() to load >> the vectors. >> > >> > Jose >> > >> >> -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>