CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Post-Processing

OpenFOAM native format data visualization and workflow

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 12, 2008, 09:44
Default hi all! I noticed one (weir
  #1
Member
 
Maxim Loginov
Join Date: Mar 2009
Posts: 33
Rep Power: 17
zeliboba is on a distinguished road
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.
zeliboba is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Commercial meshers] Native OpenFOAM interface in Pointwise cnsidero OpenFOAM Meshing & Mesh Conversion 41 May 20, 2012 19: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
[OpenFOAM] Posted OpenFOAM native reader for ParaView3CVS 7islands ParaView 0 October 24, 2007 11:52
Visualization of Data in polar coordinates Sujit Kirpekar Main CFD Forum 4 December 3, 2002 13:41


All times are GMT -4. The time now is 07:01.