[matteoc]

thank u Mark,

but I've just set CEI_ARCH to "linux_2.6_32"!

When I open results, choosing the files format, OF is not present in the list

I've a OF 64bit installed!

Do u have any suggestion?
bye, Matteo

[fra76]

I typically do:
foamToEnSight root case
a directory root/case/enSight is created, with a .case file and fields inside.

From EnSight, open that file (the .case one) as ensight case file format, and everything works...
OF 64bit and EnSight 64 bit.

[olesen]

Hi Matteo,

if you have 64bit OpenFOAM and 64bit Ensight, you shouldn't need to explicitly export a CEI_ARCH value (ie, the value returned by $CEI_HOME/bin/cei_arch should be fine).

Check that the values for ENSIGHT8_INPUT=dummy and ENSIGHT8_READER=$FOAM_LIBBIN are correctly set and exported. Maybe even check that no value is exported for CEI_ARCH.

Beyond that, I can't help much further since we have 32bit OpenFOAM on the x86_64 machines.

[matteoc]

Thanks a lot Mark,

Only another trouble with 64bit OF will take me to change to 32 as soon as possible!!!!

bye

[fra76]

BTW, I can read directly OpenFOAM cases into ensight, without exporting them, but it's not convenient, because of file selection...
However, I had to recompile libuserd-foam.so in the directory ensight76FoamExec, because of some error while ensight tried to load it.
I've just followed the istructions given above...

[fabianpk]

For those of you who haven't been able to use the Ensight reader with OpenFOAM 1.4, I think I might have found the error. In the file OpenFOAM-1.4/applications/utilities/postProcessing/graphics/ensight76FoamExec/Ma ke/options
simply include the OpenFOAM package, by adding the line -lOpenFOAM \

the last part of options should then look like this:

LIB_LIBS = \
-lOpenFOAM \
-lfiniteVolume \
-llagrangian \
-lfoamUtil \
$(PROJECT_LIBS)

This worked for me, I hope it works for everyone else as well.

/Fabian

[sek]

Has anybody used OpenFOAM and Ensight successfully to visualize particles moving around in an unsteady flow-field? Lest's say the particles diameters also change as they move. Can someone give me a direction?

[olesen]

It should work okay if you select Measured/Particle as the source and change the node representation to spheres and then scale them by your favourite scalar.
BTW: the node representation icon is the thing that looks like a triangle (just above the hammer icon) - it took me a call to Ensight support before I discovered this!

[marinota]

I tried running the foamToEnsight utility which did not convert the Lagrangian variables. Only the continuous phase variables (U, and P) were translated.

[olesen]

The Lagrangian variables might have been missed if they were not available at all the time intervals.

BTW:
I've be working on and off on a different version for quite a while (foamZoneToEnsight). It seems to work mostly okay, but isn't documented enough to a proper release.

Nonetheless, let me know if you are interesting in beta testing it.

Features:
* ascii/binary output
* an Ensight part is created for each cellZone and patch
* the -zeroTime option can be used to include the often incomplete
initial conditions (missing useful calculated values)
* no parallel data

The Lagrangian export seemed to work okay for some simple test cases, but it hasn't be properly stress-tested.

To avoid collisions with the existing foamToEnsight utility, subdirectory 'Ensight' is used instead of "EnSight".

/mark

[marinota]

Mark, I'd love to beta test foamZoneToEnsight.

thomas.marino@navy.mil

[olesen]

Hi Thomas,

Here is my current version of foamZoneToEnsight.tar.gz

NB: since I've implemented the EnSight writing as a library, it can be re-used elsewhere as well.

/mark

[marinota]

Mark,
Compile and execute went fine. I get a "Error prereading data" warning when loading the case file into Ensight (8.2.3). It appears there is a problem sequencing data (descending/duplicate ordered time values).
Tom

[olesen]

Hi Tom,

It could be a conversion problem or even an EnSight issue -- the current EnSight is 8.2.6(c)

One problem could be if your lagrangian data doesn't exist at the last time step, but I'm not really actually sure, since I haven't looked at the code for quite a while.

Note that each data sub-directory should have a time file that might help you figure out what is going wrong.

[egp]

I am having an annoying format problem when running foamToEnsight on rasInterFoam output files.

EnSight is very specific about the format of the files, i.e., each real must be 12 characters long.

Unfortunately, foamToEnsight is writing the gamma variable (and only the gamma variable ?!?) with a 3-digit mantissa for values very close to zero. This gives a 13 digit real, and causes ensight to choke (actually, it reads the file, but you end up with garbage in that variable) when reading the input files.

I've confirmed this by probing the file by hand, and by running ens_checker (a CEI utility for checking the integrity of input files).

Anyone else seen this? Is there an easy fix?

Eric

[fra76]

P.S.
The elegant solution above is not coming from me... I wouldn't have used scalar(floatScalarVSMALL)), but a fixed small enough value (like 1.e-50), which is not so good.

[egp]

Francesco,

Thanks for the quick answer! Simple and effective.

Eric

[olesen]

Hi Eric,

If you'd like to be a further beta tester, you might also try the foamZoneToEnsight that was posted earlier in this thread. The EnSight binary output would probably avoid this problem too.

[ebertmp]

In regards to Eric Paterson's post and the solution provided by Frasncesco...

I had come up with an alternate solution to this problem based on the belief that this is essentially a type mismatch issue that occurs when using double precision on the OpenFOAM side. The EnSight format only supports single precision in both ASCII and binary forms. So when the double precision data stored in OpenFOAM is inserted into the OFstream you can potentially get values with negative 3 digit exponents which will violate the format expected by EnSight (12.5e) even though the stream was sent the setw(12) manipulator and the precision was set to 5. Apparently the field width setting is viewed as more of a suggestion and is not strictly enforced when negative 3 digit mantissas are involved. In single precision you won't be able represent numbers with 3 digit mantissas so this won't be a problem.

Based on this, the solution I came up with was to simply cast the double presicion values to floats as they are being inserted into the stream. For good measure I did this for both the field values as well as the grid coordinates.

In ensightField.C change (line 45) from

ensightFile << setw(12) << sf[i] << nl;
to
ensightFile << setw(12) << float(sf[i]) << nl;


and in ensightMesh.C change (line 305) from

ensightGeometryFile << setw(12) << pointsComponent[pointi] << nl;
to
ensightGeometryFile << setw(12) << float(pointsComponent[pointi]) << nl;


I also made another small change to the foamToEnsight utility. When using ens_checker on the data sets written by foamToEnsight I got many obscure warnings that turned out to be due to there not being a final end-of-line inserted at the end of the case file. So I modified ensightCaseTail.H so that one was added to the end of the file. This made all the warnings from ens_checker go away.

[hjasak]

I have added both into the dev version. One thing though: you should take the

ensightGeometryFile << setw(12)

and

ensightFile << setw(12)

out of the loop. setw(12) is a stream modifier, it modifies the stream only once and afterwards all is fine. There is no need to tell the stream to modify itself millions of times, this just slows things down.

Hrv