[Tobi]

Hi,

Export your geometry as STEP, open it with SALOME, create your different patches (create groups), go to mesh module and mesh the different patches like you want.

So there it is.
Geometry module -> make your patches
Mesh module -> triangulate your patches and export as STL

[cristian.arbe]

I did import the STEP file, created the patches but now I cannot find what you meant by triangulating (I have never used SALOME before).

[Tobi]

Hi,

if you export a surface out of a CAD software and save the file as STL (STereoLithography), the software will triangulate the surface. In other words, the surface will be approximated by triangles.

Using CAD tools you normally can not have a big influence on how the surface will be triangulated. Normally it will be done in a way that the size of the file is small. However this is a very bad behavior if you have more STL combined to one complete geometry. It will work if you have only flat surfaces but hence two connected STL's share a curved line, this will fail all the time. Therefore SALOME offers you the possibility to generate the triangles by some more advanced methods.

To do the triangulation, you have to go to the mesh module and mesh your surfaces with Netgen 2d or other methods.

If you export this file as STL, it will use the generated triangulation.

Simple example in the attachment. The first one shows the geometry. The second one the triangulation of CAD exported and my own one. You clearly see that mine is closed and the export of the CAD software not. And now think about more complex shapes. CAD softwares are not created for "meshing surfaces". Maybe there are some extensions but I never used some of them.

This should be clear now (:

Further information about how to mesh can be found in the tutorial section of salome.


PS: For sHM the nice triangulation is much better.

[cristian.arbe]

I understand the idea but I don't really get how to do it in SALOME. Is there any way I can check whether the STL files are water-proofed to try and fix them from the CAD software? What I can do is to increase the tolerance of the distances and angles, setting it to max. maybe fixes the problem?

EDIT: Solved! I will try simulating everything again.

[cristian.arbe]

Now getting another error:

--> FOAM Warning :
    From function gaussConvectionScheme
    in file finiteVolume/convectionSchemes/gaussConvectionScheme/gaussConvectionScheme.H at line 123
    Reading "/home/cristian/OpenFOAM/cristian-3.0.1/run/reactorCaseTurbulent/system/fvSchemes.divSchemes.div(phi,epsilon)" at line 33
    Unbounded 'Gauss' div scheme used in steady-state solver, use 'bounded Gauss' to ensure boundedness.
    To remove this warning switch off 'warnUnboundedGauss' in "/opt/openfoam30/etc/controlDict"

[Tobi]

Originally Posted by cristian.arbe

I understand the idea but I don't really get how to do it in SALOME. Is there any way I can check whether the STL files are water-proofed to try and fix them from the CAD software? What I can do is to increase the tolerance of the distances and angles, setting it to max. maybe fixes the problem?

EDIT: Solved! I will try simulating everything again.

If you export from CAD, the software will not set the outer points of the different patches to the same position. Either you use salome for that or another surface mesher. I will post some other trick, how to get a water proofed STL for snappyHexMesh, using snappyHexMesh itself (:

The post will be done during weekend.

To your error.

1. First this is not an error
2. This is just a warning

--> FOAM Warning :
    
    Reading  "/home/cristian/OpenFOAM/cristian-3.0.1/run/reactorCaseTurbulent/system/fvSchemes.divSchemes.div(phi,epsilon)"  at line 33
    Unbounded 'Gauss' div scheme used in steady-state solver, use 'bounded Gauss' to ensure boundedness.

Everything is written in your warning. Either ignore this or just use bounded schemes. This was introduced (I think in 2.1???, can not remember and will include the Sp() term in your equations. If you do not know what that mean, just search the forum.

[cristian.arbe]

Then I guess it's all fine cause the simulation converged. Thanks!

[cristian.arbe]

Actually the first simulation ran fine, but then when I ran it again cause I lost the data it does not converge anymore. I made sure that all the changes I did with @Tobi are kept, but still.

Residuals screenshot: http://imgur.com/l3Yeimj
Case Folder: https://drive.google.com/open?id=0By...GZIZEtOSnQwLWc

[Tobi]

Hi,

first, congrats to your nice triangulation. That is very good. I want to mention that your dT set-up is senceless. We do not have any time derivative in the SIMPLE algorithm and therefore dT does not influence the simulation. Normally it is set to 1 because then the time indicates the number of iterations you already did. So if you set dT to 1 and endTime to 40, you will at least have 40 iterations. If you set dT to 0.0001 and endTime to 0.004 you end up with the same solution.

To you case.

• The mesh is (for me not so nice).
• You forgot ";" in fvSolutions
• p should be relaxed in fields not equations
• you put 2times U in relaxation
• U inlet BC (why do you do sth. like that?) I think you want some normal inlet velocity or some mass flow mass flux, easier to apply

http://www.holzmann-cfd.de/cfd-onlin...rbulent.tar.gz

tar xzf reactorCaseTurbulent.tar.gz
cd reactorCaseTurbulent
ideasUnvToFoam backgroundMesh.unv
snappyHexMesh -overwrite
simpleFoam

I could not try because I am too lazy to convert this case to 2.3.x (I think only one file I should add but still its to much

Thats how I would do it.

[cristian.arbe]

You forgot ";" in fvSolutions
p should be relaxed in fields not equations
you put 2times U in relaxation

Wow those were some stupid mistakes

U inlet BC (why do you do sth. like that?)

I tried using a normal value for U but it would give me problems. When I changed it for the vector, the simulation stopped giving errors, although if the vector is on the right direction, shouldn't it be fine?

tar xzf reactorCaseTurbulent.tar.gz
cd reactorCaseTurbulent
ideasUnvToFoam backgroundMesh.unv
snappyHexMesh -overwrite
simpleFoam

I'll try and do that, but I'm not sure what it is (?).

EDIT: Now I get the error:

Cannot find patchField entry for defaultFaces

[Tobi]

Hi,

of course the normal velocity BC will give you problems because your faces at the inlet are nor correct oriented (:
Thats why. But I already told you in the first replay that you have to make a good mesh for the inlet and outlet.

[cristian.arbe]

I've seen that with the files you sent me the mesh has way more elements, could you explain me what you did there?

And what should I do with the error "Cannot find patchField entry for defaultFaces"?

Thanks.

[Tobi]

In your boundary (constant/polyMesh/boundary) there is the entry "defaultFaces". Just remove the entry and set the first number before the brackets to 3.

What I did, I made improvements to your mesh.

• I just used featureEdges that are necessary (you used almost again several with same features lines, I do not know if this will influence or not)
• I removed your feature edge refinement
• I increased the levels of inlet and outlet
• I made a better mesh for your channels (fluidRefinement)
• I removed your region refinement
• I removed your layer addition (only up to 50%)
• I made a new background mesh (because I did not had yours)

[cristian.arbe]

Originally Posted by Tobi

What I did, I made improvements to your mesh.
I just used featureEdges that are necessary (you used almost again several with same features lines, I do not know if this will influence or not)
I removed your feature edge refinement
I increased the levels of inlet and outlet
I made a better mesh for your channels (fluidRefinement)
I removed your region refinement
I removed your layer addition (only up to 50%)
I made a new background mesh (because I did not had yours)

Thanks!

From what I could guess, when using the command you gave me "ideasUnvToFoam backgroundMesh.unv", there are some faces that do not belong to any patch so it adds them to defaultpatch, and then when I try to use decomposePar -after deleting default patch- to mesh in parallel it complains about it:

--> FOAM FATAL IO ERROR: 
error in IOstream "/home/cristian/OpenFOAM/cristian-3.0.1/run/reactorCaseTurbulent/processor4/constant/polyMesh/points" for operation Ostream& operator<<(Ostream&, const Scalar&)

file: /home/cristian/OpenFOAM/cristian-3.0.1/run/reactorCaseTurbulent/processor4/constant/polyMesh/points at line 41800.

    From function IOstream::check(const char*) const
    in file db/IOstreams/IOstreams/IOstream.C at line 99.

FOAM exiting

[Tobi]

No.

If you use that command it will convert the mesh to a foam mesh (its pure hexmesh). Due to the fact that I did not set any name to the boundary faces, OpenFOAM sets all unknown or not defined faces to the group defaultFaces. After meshing there are no faces anymore that belong to that group but the entry in the boundary file still exist. OpenFOAM initialize all boundaries that are written in that file (does not matter if they have faces or not). Therefore you have to delete that entry or copy a createPatchDict to your system and run createPatch -overwrite.

Hence the initialization will check all boundaries, you get the error. The other way to fix that, just add boundary conditions to all your variables but that is senceless hence defaultFaces do not have any face entry. You can check this out in the file constant/polyMesh/boundarys


The error you get is related to some mistake you did.


Note: If the nFaces entry in defaultFaces are not 0 you are not allowed to delete that entry. So you should make a short workaround what is standing in the files and what that means.

[cristian.arbe]

It won't even let me do SHMesh, it throws this:

[10] --> FOAM FATAL IO ERROR: 
[10] error in IOstream "/home/cristian/OpenFOAM/cristian-3.0.1/run/reactorCaseTurbulent/processor10/constant/polyMesh/faces" for operation Ostream& operator<<(Ostream&, const char)
[10] 
[10] file: /home/cristian/OpenFOAM/cristian-3.0.1/run/reactorCaseTurbulent/processor10/constant/polyMesh/faces at line 877056.
[10] 
[10]     From function IOstream::check(const char*) const
[10]     in file db/IOstreams/IOstreams/IOstream.C at line 99.
[10] 
FOAM parallel run exiting

[Tobi]

Okay, lets start from the beginning.

• Take my case
• Rename (for meshing) 0 to 0.org
• Remove constant/polyMesh
• Remove other time folders

ideasUnvToFoam theGuy.unv

This should give you the background mesh that I made (you can also use your background-mesh but then maybe the meshing is not exactly what I got).

Then just mesh it:

snappyHexMesh -overwrite

Copy a createPatchDict into your system folder (search in the tutorials) and the entrys should be empty in that file (something like that):

patches ();

Then proceed:

createPatch -overwrite

This step will finally delete the defaultFaces entry in your boundary file if you did everything correct. Then you can go on as know.

Note: For meshing that simple case you never will need 10 cores or more. Finally you should really know how to split your domain, otherwise you will slow down your calculation because of the shared faces.

[cristian.arbe]

I get "No patches removed." and the defaultFaces patch is still there after doing what you did

On my boundary file there is only one patch which is defaultFaces though, all the other patches disappeared.

Edit: Solved, forgot to reconstruct after running in parallel.

[cristian.arbe]

I've run the simulation and the residuals for U and p (I've ran only the laminar case to see everything is ok) stay on an almost constant value of 10e-2 and 10e-1, respectively, for 1,000 iterations. Is that just cause the simulation doesn't converge or maybe is there any parameter limiting the value of the residuals?