basic netgen questions
 

Hi All - I am having trouble using netgen with openfoam. I am able to use the netgenNeutralToFoam command to create a mesh and I can view the mesh as well. I always delete the first patch (patch 0) that is created because it is always of size zero and seems unnecessary. A typical boundary file looks as follows:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

7
(
patch0
{
type patch;
physicalType patch;
nFaces 0;
startFace 1440;
}
patch1
{
type patch;
physicalType patch;
nFaces 32;
startFace 1440;
}

.... more patches.

As you can see the first patch has zero faces and the same start face as the second patch, so I delete it. I also update the number of patches to be the correct number. In the above case I'd delete "7" and replace it with "6". Is there anything else I am supposed to do? My problem is that when I run dsmc foam I always get stuck at the dsmcInitialise step with the following errors:

Initialising particles
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam170/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam170/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3
in "/opt/openfoam170/applications/bin/linux64GccDPOpt/dsmcInitialise"
#4
in "/opt/openfoam170/applications/bin/linux64GccDPOpt/dsmcInitialise"
#5
in "/opt/openfoam170/applications/bin/linux64GccDPOpt/dsmcInitialise"
#6 __libc_start_main in "/lib/libc.so.6"
#7
in "/opt/openfoam170/applications/bin/linux64GccDPOpt/dsmcInitialise"
Floating point exception

I can't figure out why since the boundary and initial conditions are virtually the same as what are used in the tutorial. Thanks for any and all help.

Hello and a very good Evening to you!

I think this post might have a title which could reduce the number of people who would potentially reply, because as far as I can see, the problem you are facing does not involve the netgen mesh at all, but a basic problem with the case setup or the OpenFOAM installation.

A very quick way to check whether the mesh has been imported correctly would be to use the "checkMesh" utility. If this utility shows that the mesh is ok, then it normally implies that the import worked out fine.

Would it be possible for you to post the output of checkMesh here? That way we can see if we need to work on the import side, or on the case setup side.

Have a great day ahead!

Philippose

Hello Philippose and thanks for the help. I ran the checkMesh utility and got an OK mesh. Her are the results from the test:

/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.7.0 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 1.7.0-113391ee57bd
Exec : checkMesh
Date : Aug 04 2010
Time : 11:02:26
Host : ubuntu
PID : 2007
Case : /home/daniel/OpenFOAM/daniel-1.7.0/run/myruns/cube_2
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 189
faces: 1632
internal faces: 1440
cells: 768
boundary patches: 6
point zones: 0
face zones: 0
cell zones: 0

Overall number of cells of each type:
hexahedra: 0
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 768
polyhedra: 0

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
patch1 32 25 ok (non-closed singly connected)
patch2 32 25 ok (non-closed singly connected)
patch3 32 25 ok (non-closed singly connected)
patch4 32 25 ok (non-closed singly connected)
patch5 32 25 ok (non-closed singly connected)
patch6 32 25 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (-50 -50 -100) (50 50 0)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (0 0 0) OK.
Max cell openness = 0 OK.
Max aspect ratio = 3 OK.
Minumum face area = 220.9708691. Maximum face area = 382.7327723. Face area magnitudes OK.
Min volume = 1302.083333. Max volume = 1302.083333. Total volume = 1000000. Cell volumes OK.
Mesh non-orthogonality Max: 54.73561032 average: 33.28261205
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 0.6029411765 OK.

Mesh OK.

End

Do you think this means that openFOAM was installed on my Ubuntu improperly?

Thanks Again

Hi Philippose - In a related question, it looks like the total volume of my mesh is 1000000. Is that in units of meters? When I drew the block in CAD It was 100mm per side. Is there a way I can change the scale?

Thanks so much

Hello again :-)!

Looks like you found the problem.....

Netgen is unit-agnostic..... in that, it does not do any form of scaling. So if your geometry was created in "mm", then when you import it into OpenFOAM, it will be imported as "mm".

On the other hand, OpenFOAM works with SI units, and the boundary conditions that you specify are always in SI units.... hence, you need to convert the mesh from "mm" to "m"....

This can be done very easily in OpenFOAM using the following command run within the simulation case folder:

Note... the quotes are also required.

This command scales the mesh with the factor 0.001 in x, y and z directions.

If you want to see what else this command can do, just run:

Hope this helps :-)!

Have a nice day!

Philippose

This isn't entirely true. Take a look at etc/controlDict. The constants specified there are the only ones that correspond to SI units. And even then, those can be replaced by any other system.

The only thing that needs to be taken care of is the relative scaling of various aspects like length-to-time, viscosity, etc. Otherwise, everything is unit-agnostic.

Hello Sandeep,

A Good Evening to you :-)!

Thanks a lot for shedding some light on that..... so this implies that in a dimensioned quantity for example pressure [1 -1 -2 0 0 0 0], it only corresponds to:

[ mass length time current temperature quantity luminous intensity ]

and their relative ratios right?

And the only thing that needs to be ensured is that the relative ratios of each physical unit match? And that the units of all the variables within a simulation are consistent?

Its something which one tends to forget, when the day to day units are more or less limited to SI units :-)!

Sorry about that..... and once again, thanks for bringing it up.

Philippose

Many Thanks to Sandeep and especially Philippose. Code is running now. I am so grateful.