channelflow.org

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Switch binary FlowField IO to HDF5 ======

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

^ HDF5 field ^ meaning, issues^
|''geom/x,y,z''     | The x,y,z gridpoint values. |
|''geom/Nx,Ny,Nz''  | Number of gridpoints in x,y,z.|
|''geom/Lx,Lz,a,b'' | Lengths in x and z and bounds in y (a <= y <= b)|
|''data/u0,u1,u2,...'' | Components of scalar/vector/tensor field |
|''param/dt,dtmax,...'' | All the integration parameters, set by DNS algorithm or to null values |
|''version''        | channelflow version, e.g. 1.3.3 |
|''comment''        | optional descriptive comment |

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

  * ''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.
channelflow.org

User Tools

Site Tools

Page Tools
