The architecture taskforce held a meeting (2008-4-15) on the progress of NetCDF as the default output format for Delft3D and SOBEK. The presentation is attached.
Issues discussed (aside from topics mentioned in the presentation):
- Importance of adaptation en extension of the CF standard for output.
- Implementation challenges
- phasing out old tools and libraries (What is the end of life cycle for old file formats?)
- backward compatibility (Will we make sure all old files can be read and written?)
- programming language for conversion tools (Shall we use matlab or another dynamic language to implement the converters?)
- Planning
Agreed was that:
In the next few months we will work on creating converters to import and export cf/netcdf files from and to our current output files. (april - july)
In the 2nd half of this year we will work to change our output formats from his/nefis to netcdf.
Relevant links:
CF standard
CF standard names
NetCDF
Unstruc example requires access to delft3d/sobek repository
NetCDF sources with VS2005 solution requires access to delft3d/sobek repository
4 Comments
Unknown User (don)
... and what about input files, I hope it will be the next step
Fedor Baart AUTHOR
Not all input fits nicely into the netcdf file structure. But revising our input is on the agenda.
Unknown User (don)
Can you attach somewhere supergrid article mentioned in the presentation?
... can't imagine what will not fit, NetCDF is generic enough and can provide more formal and self-descriptive definition of input. With NetCDF4 it will be also possible to group different variables into the higher level groups. Advantages are clear - to have only one file as input instead of many specific files.
Bert Jagers
I agree that NetCDF could very well be used for storing bulk input data, however, I still don't think storing all input data in NetCDF makes sense. For parameter settings (e.g. the Delft3D-FLOW mdf file) a simple ASCII file seems to be much more appropriate: it is easy to edit and compare from within Total Commander. Furthermore, ASCII files make life easy when searching for simulations with certain settings. Okay, these features can be implemented for new file types as well, but why spend valuable time on the implementation of something that is already abundantly available in all environments for ASCII files? I know there is an ASCII representation of a NetCDF file but it is more verbose (hence less easy to get overview) and you still need to convert between the two representations.