John Gibson Mon Dec 29 10:46:55 EST 2008

Miloš Ilak of Princeton MAE is working on this and we've been discussing over email. The following is my revision of Miloš's most recent proposed structure for HDF5 files.

Note: geom/x,y,z is shorthand for three separate HDF5 fields geom/x, geom/y, and geom/z.

Issues

• geom/x,y,z may or may not be worth including. Cost would be negligible, but they are redundant and trivially regenerable from more fundamental discretization parameters, e.g. x_n = n*Lx/Nx.
• channelflow takes Lx,Lz,a,b as the fundamental geometrical quantities. Others like lx = Lx/2pi and alpha=2pi/Lx are currently provided in ascii-output geometry files to make comparisons easy for some collaborators who prefer these quantities. I don't think they're needed in HDF5 files.
• need to enumerate the integration parameters and their types (bool, int, real, string). Need to consolidate them within channeflow, as well. Right now they're scattered in several places following the logic of the algorithm. But that's gotten too complicated.
• integration time might as well go with integration parameters.
• saving version as three ints would eliminate need for string parsing when making comparisons
• I think all data should be stored as u0,u1,u2,…. FlowFields are meant to store fields of arbitrary meaning: pressure, velocity, stresses, vorticity, etc. Trying to change to labels based on the meaning of the field would lead to too much complexity in the FlowField IO function signature and/or the FlowField object.
• Rather than storing additional fields like vorticity or pressure inside a given field's HDF5 file, it's better to create them as separate FlowFields in C++ and then save them as separate HDF5 files. That fits how FlowFields are used within C++ better.

responses go here, please give name and date