Using Geometries Created in Other Programs
 

Hello all. Please forgive my beginner questions, as I am quite new to OpenFOAM.

I would like to create a geometry in a CAD program and use OpenFOAM to do the CFD work, and I am trying to use OpenFOAM's "motorbike" tutorial as my teacher. However, I haven't been able to figure out how the tutorial works--that is, I can run the tutorial easily enough, but I don't understand how to build a similar case from scratch. So, I would be very grateful if you could share a tutorial that explains the process (and the thinking behind it). If you would like to read on, I have two more specific questions for now:

According to the tutorial's "Allrun" file, the first step is to get an .obj file of the geometry I want to analyze. I can use my CAD program to export my geometry as a .obj file, but I see that there are different kinds of .obj file (i.e. Wavefront OBJ file). If I am to use the surfaceFeatureExtract function which the motorbike tutorial uses, which kind of .obj file do I need to use? I ask this because I have already tried exporting my geometry as several varieties of .obj file, and each time I am able to use surfaceFeatureExtract on the file, but when that function finishes, I am unable to read the .eMesh file that it creates.

Also, in the motorbike tutorial, I don't see in the blockMeshDict where the imported surface is referenced. Is the purpose of the blockMesh only to create a simple "box" around the bike, while the snappyHexMesh refines the mesh near the bike and tells the computer to include only the mesh within the bike?

Thanks for reading my very long question and for giving any help at all. I've got a long way to go before I understand this tutorial, so your knowledge is appreciated.

Hey there, welcome to the forum!

anyways, I usually export the CAD geometry into .stl files and use snappyHexMesh on the the stl files. In my case, part of my snappyHexMeshDict that links the stl files looks like this:

geometry
{
patch1.stl
{
type triSurfaceMesh;
name patch1;
}
patch2.stl
{
type triSurfaceMesh;
name patch2;
}
...
...
...
}

where each of the stl file contains a patch of the geometry that is needed for boundary condition specification.

you are correct about the blockMeshDict, it basically specifies the background mesh that is big enough to contain your geometry, and snappyHexMesh will refine/snap the cells to your geometry depending on your definition inside the snappyHexMeshDict.

Hope that's enough to get you started.

Thanks much for your help. I was able to create a CFD case that ran and meshed without giving me an error; however, when I tried to view the results in ParaView, I got this error at the fourth or fifth write interval:

--> FOAM FATAL IO ERROR:
Cannot find patchField entry for Fifteendw_patch0

file: /home/sean/OpenFOAM/sean-2.2.0/run/SnappyHexPractice/15dw/0.04/p.boundaryField from line 26 to line 43.

From function GeometricField<Type, PatchField, GeoMesh>::GeometricBoundaryField::readField(const DimensionedField<Type, GeoMesh>&, const dictionary&)
in file /home/sean/OpenFOAM/OpenFOAM-2.2.0/src/OpenFOAM/lnInclude/GeometricBoundaryField.C at line 154.

FOAM exiting

Can anyone tell me what it means? Have I set up my case incorrectly?

can you take a look at constant/polyMesh/boundary, and your p field in the time directories to make sure they have the same boundaries. and which solver did you use?

Thank you for your reply. I am using rhoCentralFoam to model a 15 degree wedge at supersonic speed (my case in similar to Openfoam's 15 degree wedge tutorial).

I checked the boundary and p-field files as you suggested, and I found a difference; in the p-field files of the first 3 time directories (time 0.0001, 0.0002, and 0.0003), I go to the polyMesh folder, then the boundary file, and I find an extra boundary that is not a part of my constant/polyMesh/boundary file. However, in future time directories (i.e. time 0.1), this extra boundary is not present. I'm guessing that this is a problem.

hey there,

definitely the cause. i'm surprised it didn't complain for the first 3 time steps as there exists a mismatch between the boundary conditions already. Get rid of those and try again and hope for the best =) oh and check other fields in your initial time directory for any mismatch too. can't be too careful.

good luck!

Thanks for your help. I tried your suggestion, and it got rid of the error. But, I've noticed what looks like a new problem. In my time-zero directory, the p-file (also U and T files) contains 6 boundaries; one for the top, bottom, inlet, outlet, sides, and the wedge itself. The boundary for the wedge is called "Fifteendw_.*". I chose this name because the motorBike tutorial has a similar name in its time-zero p-file. However, in the 0.0001, 0.0002, and 0.0003 time-directory p-files, those 6 boundaries are also present, but the wedge's boundary is now called fifteendwname_patch0 (this is the boundary that zhengzh5 told me to delete). The name fifteendwname is somewhat sensible because in my snappyHexMeshDict, I have

geometry
{
Fifteendw.stl
{
type triSurfaceMesh;
name fifteendwname;

etc.
etc.

but why is the wedge's boundary named fifteendwname_patch0 in the 0.0001, 0.0002, and 0.0003 time directory files? What is the purpose of the _patch0?

Next, when I run rhoCentralFoam, the p-files in future time directories (e.g. time directory 0.1 or 0.2) don't have any boundary for the wedge--they have the top, bottom, inlet, outlet, and side boundaries, but not the one for the wedge.

When I view the rhoCentralFoam results in Paraview, I see that the computational domain never changes from its initial conditions. I feel that the mis-matched, or downright lack of, boundary names is my main problem. So, do you (or anyone else) know how to make sure that the wedge's boundary gets correctly placed into all time-directory p-files? Or at least ell me which file/dictionary is responsible for this action?



Note: I'm not sure if this is important, but in my constant/polyMesh/boundary file, I don't specify a boundary for the wedge, as the Motorbike tutorial's constant/polyMesh/boundary file also does not specify a boundary for the bike.

Thanks a bunch for all your help!

Also, if the solver is starting from the 0-time directory, which just consists of my original blockmesh, and not starting from time directory 0.0003 which has my snappy mesh and its boundary conditions, would that be why the computation domain never changes from its initial conditions? If so, how do I correct it?

I think I see what happened here. Can you check if you have the overwrite flag set as on in the snappyHexMeshDict. Other thing is, is your 0.0001, 0.0002, and 0.0003 time directories a result of the snappyHexMesh? If that's the case, delete the 0.0001 and 0.0002, and rename 0.0003 as 0 (initial condition for your solver). The reason being, snappyHexMesh outputs the time directory after each step (blockMesh, castellation, snap) for debugging purpose. You really only need the last mesh to run the solver. Let me know how that goes!

Good luck!

Thanks for your reply. I actually managed to solve that problem--all I had to do was change my controlDict from

application rhoCentralFoam;

startFrom startTime;

startTime 0;

stopAt endTime;

etc
etc
etc

to

application rhoCentralFoam;

startFrom latestTime;

startTime 0;

stopAt endTime;



However, I've since come across 3 new problems:

Problem #1) I often get a floating point exception when I run my case. Since the stack trace (hopefully I'm using the correct terminology) usually includes something about sqrt(U), I think this error happens when the velocity in my flowfield goes negative somewhere. Refining the mesh usually solves this problem.

Problem #2) I sometimes get this error:

#0 Foam::error:printStack(Foam::Ostream&) at ??:?
etc
etc
etc
(Foam::fvMesh const&, Foam::word const&) at ??:?
#19 Foam:psiThermo::New(Foam::fvMesh const&, Foam::word const&) at ??:?
#20
at ??:?
#21 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#22
at ??:?
Segmentation fault (core dumped)

I've read that a segmentation error usually occurs when the computer tries to access memory that it isn't allowed to, or that isn't there. Furthermore, I can navigate to the file /lib/x86_64-linux-gnu/libc.so.6 but I can't open it, so the issue might be with that file, although I consider that unlikely because I can run other openfoam cases, such as the tutorials, without getting this error. I haven't managed to solve this error yet.

Problem #3:

When my solution runs, the results are wrong. I wish I had a picture to show you, but I don't, so I'll do my best to describe it--the flow over a 15 degree wedge/cone/just about any shape I can think of at mach 5 should create some kind of shock waves, but my solution never shows them. Instead, all I get is a thin layer of slightly increased pressure over the leading surface of my shape, and a thin layer of slightly decreased pressure over the trailing surface of my shape.

I've also experienced problem #3 when I used GMSH to mesh my geometries, and since I've read that openfoam's compressible flow solvers like hexahedral meshes instead of tetrahedral ones (I can't remember where I read that, so if I'm wrong, tell me so), I concluded that my problems were due to GMSH giving me the wrong kind of mesh. Moreover, when I view my snappyHexMesh in paraView, I see that the mesh on the surface of my geometry often has 5 or 6 sides to a face, and I've always been under the impression that a hex mesh would have 4 sides to a face (again, please correct me if I'm wrong).


So, thanks a bunch to those of you who read through this long post, and I'd appreciate any advice you can give me.

hey, using latestTime in controlDict effectively ignores the previous time directories produced by snappyHexMesh, to tidy things up a bit, just go to snappyHexMeshDict and turn overwrite flag to on, and you won't even see the extra time directories at all.

Regarding other problems you are experiencing, I don't have a definite answers to any of them. but here's what i think anyways:

1. since you have M=5, what's the courant number that you used? and what's your initial and boundary conditions for p, U, T, etc.

2. how is your mesh resolution. is the resolution high enough near the shock regions to represent the sudden jump in pressure and other fields?

3. you're correct in that OpenFOAM likes hexas more than tets and I think that's finite-volume in general. I think it has to do with the orientation of the cells and the flux of properties through neighbouring cells. It becomes more problematic when you have such high speed flow too.