[Claudio]

Hi,

I am trying to create an OpenFOAM grid using enGrid to test a Wigley hull and I have several questions:

1) the mesh that is exported as STL is created in Rhinoceros, and it is creates with the z-axis being vertical with positive being up, but when I open the STL in enGrid y is the vertical axis and positive is up. why the change?

2) in the STL file the hull has square corner, but when I start making the surface grid they get rounded out (see the pictures attached). Any reason why?
STL file
enGrid file

3) I am following the tutorial on the enGrid website for version 1.3 since it creates the mesh starting from an STL file. I have created the boundary conditions with no big problems, and have moved on to create the surface meshes. To create the surface mesh, one has to create a rule for each BC: in the case of the tutorial (damper in a duct) the rules for the resolution on the damper surfaces are set to 0.05. What does the 0.05 represent? is it an absolute length? a relative length?

4) the tutorial suggests to run the "improve surface mesh" several times while keeping an eye on the change and fluctuation ratio. What do these ratios represent? What are good values to stop the process at? I currently can get the change ratio to 0%, but the fluctuation ratio seem to be stuck at ~5-6%. (Same enGrid file as above)

5) I assumed the surface grid was good enough and try to move forward to make the prismatic boundary layer: the tutorial says to define a volume first, and set all cells to green by double clicking, etc.. In enGrid 1.4 however the choices are "A <<" or ">> B". what do they mean and which one am I supposed to pick?

6) I let them as "A <<" and tried to grow the prismatic boundary layer by selecting "PortHull" and "StbdHull", in the BC windows, and newly created "tank" volume in the volumes window. There are then 5 check boxes and 7 parameters to be set. How are these supposed to be handled? is there a manual somewhere that explains what they do?

7) I used the default values and enGrid crashes. Any obvious reason why?

Hope somebody can help.

Claudio

[ogloth]

Hi Claudio,

I'll try to answer your questions:

1. That is to match the Blender definition of top, front, etc. You can change that behaviour in "Tools -> Configure enGrid -> General Tab"

2. enGrid probably fails to detect that corner as fixed. Try setting the parameter "edge angle to determine fixed vertices" in "Tools -> Configure enGrid -> surface meshing Tab". 45 degrees could be a good starting point.

3. The length is absolute. You do not need to specify rules for every patch; if you don't specify a rule, enGrid will relax the mesh size towards the maximal allowed edge length.

4. I consider those values converged ;-)

5. A<< is the old green -- adaptation for people with red green deficiencies. You can configure the colours in "Tools -> Configure enGrid -> Colours"

6. The only checkbox you need for now is the "use absolute height" option. Leave anything that does not make sense to you as default. If you want, you could use a very simple geometry and play around with the parameters to see what they do. We are still looking for volunteers to improve the documentation (GitHub wiki pages).

7. Sounds like a NETGEN crash. For some reason the NETGEN library version we are using at the moment does not stop gracefully... :-( If you upload the full case (.egc, .egc.vtu, .egc.geo.vtu) I can have a look and maybe it is something very simple.

I have completed a mesh for your geometry (see image below). You can find the several steps here: http://db.tt/teoAehko. The STL file got first imported into Blender and then exported to enGrid (the Blender files are in the archive as well).

Cheers,
Oliver

[Claudio]

Oliver,

thanks for your reply. I have downloaded your files and will examine them in details. If I open them with enGrid, will they show the set of parameters you used to make the steps work?

Sorry I didn't upload the complete set of enGrid files, didn't realize it made more than the file I saved. Here are the links to all of them:
.egc
.egc.vtu
.egc.geo.vtu

One more question: why did you import the STL into Blender first? When I checked the STL imported directly into enGrid, it said the mesh was ok. what is the advantage of doing the extra step in Blender?
I'm asking because I am learning enGrid, and OpenFOAM, and would love not to have to pile another program on top of it.

Cheers,
Claudio

[ogloth]

Blender is very useful to split the geometry into different boundary codes (patches) -- easier than the "P" and feature angle approach. It is not required though.

I haven't had the chance to look at your case yet. One suspicion, however, is that the surfaces are not correctly oriented.

[Claudio]

My understanding, and attempt, was to have the normals all pointing into the flow region.
So for the box the normals point inward, and for the hull they point outward.
I might not have achieved what I intended though...

[KateEisenhower]

Originally Posted by Claudio

My understanding, and attempt, was to have the normals all pointing into the flow region.
So for the box the normals point inward, and for the hull they point outward.
I might not have achieved what I intended though...

Hello Claudio,

I do it the other way round. According to the UNSTRUCTURED GRIDS FOR OPENFOAM WITH BLENDER AND ENGRID tutorial all normals have to point away from the fluid.