[akidess]

I can't seem to find a way to save the output of the functionObject "cuttingPlane" into a binary file. The default seems to be ASCII, which wastes disk space. Does anyone know if it's possible to change the file format?

[wyldckat]

Hi Anton,

Nope! According to the code at "OpenFOAM-2.1.x/src/sampling/sampledSurface/writers", it's all hard coded as ASCII only. There is a proxy system, but it only sends the surface points to the writer.

The closest you can get is pack things via another functionObject: http://openfoamwiki.net/index.php/Ti...ect_systemCall - this way you even pick the format you want well, compression only

Best regards,
Bruno

[akidess]

Thanks Bruno! It's funny it's hard-coded to ASCII, because the writer classes do support binary files (at least src/conversion/ensight does). So for now I just hard-coded binary instead of ASCII, and it works fine

[wyldckat]

Hi Anton,

I think they hard-coded things this way, because the normal writers are for volumes only

Best regards,
Bruno

[akidess]

Sorry, I didn't quite get that. Can you explain what you mean with volumes only and normal writers?

[wyldckat]

Originally Posted by akidess

Sorry, I didn't quite get that. Can you explain what you mean with volumes only and normal writers?

The idea I was trying to convey is as follows: the simulation cases done with OpenFOAM usually focus only on the volume mesh and the patches. When we want to generate a sampled surface, even when directly coded in a solver or utility, the resulting surface data isn't as good looking as the volume mesh.

Here's an example of what I'm talking about: http://www.cfd-online.com/Forums/ope...tml#post343937
If you read the whole thread, you'll understand that the sampled surface cannot be represented as nicely as a patch surface, simply because said sampled surface is only represented by points!

I think this is why the functionObject "cuttingPlane" is using dedicated and hard-coded surface writers, instead of using an already existing "driver".

[akidess]

Actually, I just noticed that the sample 'sampleDict' changed between 2.0.x and 2.1.x. The latter now includes an entry

 39 // optionally define extra controls for the output formats
 40 formatOptions
 41 {
 42     ensight
 43     {
 44         format  binary;
 45     }
 46 }

which is exactly what I was looking for!

[wyldckat]

Nice! I should have looked deeper into this