User Tools

Site Tools


development:hdf5

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

development:hdf5 [2008/12/29 08:16]
gibson
development:hdf5 [2010/02/02 07:55]
Line 1: Line 1:
-====== Switch binary FlowField IO to HDF5 ====== 
- 
-John Gibson Mon Dec 29 10:46:55 EST 2008 
- 
-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''​. 
- 
-**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 // 
- 
  
development/hdf5.txt · Last modified: 2010/02/02 07:55 (external edit)