CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Post-Processing (https://www.cfd-online.com/Forums/openfoam-post-processing/)
-   -   Ensight (https://www.cfd-online.com/Forums/openfoam-post-processing/57194-ensight.html)

matteoc February 28, 2007 09:10

thank u Mark, but I've just
 
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 February 28, 2007 09:17

I typically do: foamToEnSight
 
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 February 28, 2007 09:38

Hi Matteo, if you have 64bi
 
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 February 28, 2007 10:50

Thanks a lot Mark, Only ano
 
Thanks a lot Mark,

Only another trouble with 64bit OF will take me to change to 32 as soon as possible!!!! http://www.cfd-online.com/OpenFOAM_D...part/happy.gif

bye

fra76 March 1, 2007 03:05

BTW, I can read directly OpenF
 
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 July 4, 2007 10:49

For those of you who haven't b
 
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 September 19, 2007 11:16

Has anybody used OpenFOAM and
 
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 September 20, 2007 03:21

It should work okay if you sel
 
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 September 20, 2007 10:24

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

olesen September 21, 2007 04:36

The Lagrangian variables might
 
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 September 24, 2007 07:17

Mark, I'd love to beta test fo
 
Mark, I'd love to beta test foamZoneToEnsight.

thomas.marino@navy.mil

olesen September 24, 2007 08:43

Hi Thomas, Here is my curre
 
Hi Thomas,

Here is my current version of http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif foamZoneToEnsight.tar.gz

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

/mark

marinota September 24, 2007 14:24

Mark, Compile and execute wen
 
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 September 24, 2007 14:43

Hi Tom, It could be a conve
 
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 November 7, 2007 11:30

I am having an annoying format
 
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 November 7, 2007 11:51

P.S. The elegant solution abo
 
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 November 7, 2007 12:03

Francesco, Thanks for the q
 
Francesco,

Thanks for the quick answer! Simple and effective.

Eric

olesen November 8, 2007 03:43

Hi Eric, If you'd like to b
 
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 November 19, 2007 08:21

In regards to Eric Paterson's
 
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 November 20, 2007 18:54

I have added both into the dev
 
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


All times are GMT -4. The time now is 04:55.