Follow

OpenFOAM Reader Guidelines

Trouble with the OpenFOAM reader?

Here are the first couple of things to check.

1. EnSight 9.2.2(a) now implements the Version 2 of the OpenFOAM reader.
a. changing coordinate and changing connectivity transient are now supported.
b. Parallel OpenFOAM files can now be read into EnSight (non-SOS, i.e. non-parallel).  There is no need to run the "reconstructPar" OpenFOAM utility prior to reading the parallel OpenFOAM model into EnSight. Users specify the same "system/controlDict" file for parallel runs, and EnSight will detect all of the "processorN" directories containing the parallel files, and read them into a serial EnSight Server. From a user's point of view, there is no difference between loading in a parallel dataset or a serial/reconstructed dataset (same commands used, no additional flags/specification, no knowledge of a parallel vs serial/resconstructed dataset). As of yet, you cannot use EnSight Gold parallel (SOS) capability with this reader.
c. 2D parts now receive their own variables if they exist (yplus, wall shear, etc.). If the 2D parts do not have their own variable, then they receive their parent fluid element's value. There is no interpolation or adjustment of the value from the fluid element cell centered value to the 2D surface (for example, velocity will be taken directly from the adjacent fluid element).

2. EnSight 9.2.1.(a) is contains the first release of version1 the EnSight OpenFOAM reader.

3. Known Limitations of Version 1 reader:
a. Does not handle changing connectivity.
b. Does not handle changing coordinate transient.
If either of these exist,  use the "foamToEnsight" utility to convert the OpenFOAM files to EnSight Case gold format.

c. Does not handle pre-decomposed datasets (parallel OpenFOAM).
Use the "reconstructPar" utility to merge decomposed datasets back into a single file dataset structure. Then use our Native OpenFOAM reader on this reconstructed dataset.

(all of the above limitations are planned to be removed in Version 2 of the reader (circa Spring 2011).

4. The  reader can handle both ascii and binary, and uncompressed or compressed (.gz) formats of either. No extra steps or conversions are required to read these datasets.

Geometry:
4. Assuming that the OpenFOAM run in a directory called "basename", then the following items must exist:
a. basename/system/controlDict file must exist, be readable by the user.
b. basename/constant/polyMesh/points or points.gz file must exist, and be readable by user.
c. basename/constant/polyMesh/faces , owner, and neighbour  (or .gz form of) must exist and readable by user.

FYI:
(points is the file containing node numbers and locations).
(faces is the file containing the face connectivity of the "points").
(owner is the file containing the collection of faces which make up an 3D element)
(neighbour is the file containing connectivity between the faces (each face has an owner, and neighbour, apart from boundaries, who have owner only).

Variables:
5. The variables live in a series of directories. The directory name is interpreted as the Timestep.
a. basename/<timestep>  contains a single file for each of the variables written out. eg. basename/0/p contains pressure for each element at timestep 0; basename/250/U contains velocity vector information for timestep 250.
There is no pre-assumed variables in that directory. Typically, but not a requirement, there is at minimum a "U" file (velocity vector), and a "p" file (pressure scalar). 
b. In Version 1 of the reader, 2D parts ONLY had their adjacent 3D fluid elemental variable value, and not have the ability to have their own variable (yplus, wall shear, etc).
c. In Version 2, 2D parts now receive their own variables if they exist (yplus, wall shear, etc.). If the 2D parts do not have their own variable, then they receive their parent fluid element's value. There is no interpolation or adjustment of the value from the fluid element cell centered value to the 2D surface (for example, velocity will be taken directly from the adjacent fluid element).

EnSight does not distinguish between a steady state run with multiple iteration values, versus a transient run with multiple timestep values. Both look identical to EnSight. As an effect of this, a steady state run with solutions stored at iteration 0,200, 400, 600, 800 will appear in EnSight as a time dependent solution, with 5 timesteps (0-4), at "time" equals 0, 200, 400, 600, 800.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments