CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Post-Processing (http://www.cfd-online.com/Forums/openfoam-post-processing/)
-   -   OpenFOAM native format data visualization and workflow (http://www.cfd-online.com/Forums/openfoam-post-processing/61367-openfoam-native-format-data-visualization-workflow.html)

zeliboba September 12, 2008 08:44

hi all! I noticed one (weir
 
hi all!

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.


All times are GMT -4. The time now is 06:00.