|September 12, 2008, 08:44||
hi all! I noticed one (weir
Join Date: Mar 2009
Posts: 33Rep Power: 10
I noticed one (weird) tendency: when someone want to import/export data to non-native OF format, he writes a converter instead of reader/writer. why is that? currently, my workflow looks like this:
preprocessing. let's say I prepared mesh in GAMBIT, save it, then I have to convert it to "OF native". I do not mind to do it for mesh in 10 000 cells, but for 10 million it takes quite a lot of space and time. It seems to be more natural to write a reader, which can read Fluent format directly into OF.
postprocessing. OF outputs data (only?) in its own native format, which seems to be designed for restart files and is not really suitable for postprocessing. if one do not use ParaView or VisIt, they have convert data again. It is more natural to specify in which format to save your data for postprocessing and save it directly.
OOP design should facilitate writing such input-output filters, isn't it? so why everybody write converters not readers?
One of the reason might be that OF does not provide tools/API for that. Compare VisIt and OpenDX with ParaView: first two provide excellent scripts and tutorial for writing new readers, while last one gives (almost) nothing. Is it the same situation in OF?
Another reason could be that native OF format is so perfect, that everyone wants to keep with it. Is it? No, it is not:
1. it is neither widespread, nor standard. only few programs can read/write it.
2. it is not portable. if you write compressed ascii, it is kind of portability. also you can read it without having OF library (which is fine), but see next item.
3. it is slow. ok, if you write in "native binary", maybe it is fast, but "native binary" is not portable. even if you use compressed ascii (through szip), it is probably slower then uncompressed hdf5 and I generally do not believe that compressed ascii could be fast. having hdf5 tools you also can read data and prepare it for gnuplot and similar programs (again this would be probably faster, then use gzip+sed+awk for compressed ascii)
4. it is not well suitable for archiving.
please, correct me if I'm wrong. of course I'm talking about case with 10 mio cells or let's say 100 cases with 100000 cells.
|Thread||Thread Starter||Forum||Replies||Last Post|
|Native OpenFOAM interface in Pointwise||cnsidero||OpenFOAM Meshing & Mesh Conversion||41||May 20, 2012 18:30|
|Native OpenFOAM interface in Pointwise||Chris Sideroff||Main CFD Forum||0||January 16, 2009 13:37|
|Data Visualization||Ahmed||Main CFD Forum||4||March 15, 2008 17:02|
|Posted OpenFOAM native reader for ParaView3CVS||7islands||OpenFOAM Paraview & paraFoam||0||October 24, 2007 10:52|
|Visualization of Data in polar coordinates||Sujit Kirpekar||Main CFD Forum||4||December 3, 2002 13:41|