[cristian.arbe]

Hello all,

I am relatively new to OpenFoam and I am trying to simulate a photoreactor on incompressible turbulent flow at steady-state. I copied most of the code of the pitzDaily model from the tutorials adjusting all the parametres for my case. When running the case in parallel I get the following error:

mpirun noticed that process rank 7 with PID 3333 on node XXXXX exited on signal 8 (Floating point exception).

Commands I used:

decomposePar
mpirun -n 16 renumberMesh -overwrite -parallel
mpirun -np 16 simpleFoam -parallel
reconstructPar -latestTime

Things I did:

• deltaT: I tried reducing the deltaT to a point of a Courant number of 0.5 and still getting the error.
• Lack of memory: running on a workstation of 64GB of RAM and the used RAM does not even go above 1.5 GB.
• Laminar flow: simulation succeeds on calculating the laminar case.

I believe there is some bad boundary condition but I cannot find where it is.

Here is a 7z file with the case: https://mega.nz/#!Z1JTjZoY!YSOBNCHdW..._ArkRD3O1SmzvU

[cristian.arbe]

Succeeded by simulating the case in laminar flow but turbulent still does not work.

[Tobi]

Hi,

you can try to use the laminar pre-calculation for your turbulent calculation. Normally, I suppose that you made a mistake in the set-up of your turbulence variables k, epsilon or omega. For your 7z file we need some key! "To access this folder/file, you will need its Decryption key.
If you do not have the key, contact the creator of the link."

[cristian.arbe]

Sorry about the file! I edited the post so that the link includes the key to access.

For the and parametres I used the formulas:

[Tobi]

Originally Posted by cristian.arbe

Sorry about the file! I edited the post so that the link includes the key to access.

For the and parametres I used the formulas:

Use the correct boundary conditions! Do not set it by yourself.

[cristian.arbe]

I am sorry, what do you mean by using the correct boundary conditions? This is how my k and epsilon files look like respectively:

internalField   uniform 8.7277e-006;

boundaryField
{
    fluidInlet
    {
        type	fixedValue;
		value	uniform 0.0090220;
    }
	fluidOutlet
    {
        type	zeroGradient;
    }
	fluidCylinder
    {
        type	kqRWallFunction;
        value	uniform 8.7277e-006;
    }
	fluidRefinement
    {
        type	kqRWallFunction;
        value	uniform 0.0090220;
    }
}

internalField   uniform 3.0534e-006;

boundaryField
{
	fluidInlet
    {
        type            fixedValue;
		value           uniform 0.33827;
    }
	fluidOutlet
    {
        type            zeroGradient;
    }
	fluidCylinder
    {
        type            epsilonWallFunction;
        value           uniform 3.0534e-006;
    }
	fluidRefinement
    {
        type            epsilonWallFunction;
        value           uniform 0.33827;
    }
}

I set different values for Cylinder and Inlet/Refinement since they have different diametres and velocities.

[Tobi]

What about:

turbulentIntensityKineticEnergyInlet
mixingLength...DissipationRate

[cristian.arbe]

Originally Posted by Tobi

What about:

turbulentIntensityKineticEnergyInlet
mixingLength...DissipationRate

Tried changing the conditions as you suggested but still getting the error

mpirun noticed that process rank 6 with PID 2520 on node XXXX exited on signal 8 (Floating point exception).

I assume the mixing length refers to this?

[Tobi]

Hi,

the mixingLength is okay. So I will check our case now (:

[Tobi]

Hi,

some hints:

1. For the first try use Gauss upwind for k, epsilon
2. You are not really underrelaxing

k  0.2
epsilon 0.2
U 0.4
p 0.3

Try again you will see it should work and then you will find the problem cells

You sill will get a bounding problem:

bounding epsilon, min: -0.00074722 max: 1053.16 average: 1.14941

Thats due to your mesh. The inlet and outlet patches are not good. Also your nCellsBetweenLevels should be increased and the inlet and outlet patch should be refined 1 level more. The transition between inlet/outlet patches to your refine walls should be smooth. I did not check if you also have layers in the refinement walls - skip that at the beginning.


Cheers.

[cristian.arbe]

I'm trying to do all the changes you suggested, although I wanted to ask, when you talk about inlet and outlet, you refer to the tubes or the actual patches? Since the inlet/outlet patches only refer to the surface of I/O not the whole inlet tube.

Thank you very much for your time!

[Tobi]

Originally Posted by cristian.arbe

I'm trying to do all the changes you suggested, although I wanted to ask, when you talk about inlet and outlet, you refer to the tubes or the actual patches? Since the inlet/outlet patches only refer to the surface of I/O not the whole inlet tube.

Thank you very much for your time!

I refer only to the patches. The outlet and inlet patches have some "bad" faces at the connection between your refinement patch and inlet/outlet patch. These faces are not aligned correct.

[Tobi]

SNAP controls.

increase the nSolveIter
decrease tolerance
decrease nFeatureIter

CASTELLATED controls.

increase nCellsBetween

At least I am not a fan of featureEdge refinement. I think there was some new keyword about tolerance etc. Using this, you could get troubles (see tutorial on my homepage) if the backgroundMesh is aligned with one patch/feature edge - I think in your case it is okay.

TRIANGULATED SURFACE (STL)

I will never use STL's that will not be closed or exported by CAD software. The triangulation is very bad. In your case the STL is not waterproof. My experience after 6 years: Never use an non-waterproofed STL and snappyHexMesh. It could work or otherwise you could get some unexpected results (sometimes) especially if the gaps are bigger than the cells.

So a few things to do.

[Tobi]

One thing left.

surfaceFeatureEdges... please check it before using them. See attachment. Due to the fact that your STL's are not identical at the interfaces (same amount of points at the same locations) the featureEdges will also be different (attachment). So my question to you, which one should snappy use now? In addition, some feature edges are not closed etc...

Correct this too!

[cristian.arbe]

The STL files are exported from a model from SolidWorks I made myself and it was fine before exporting. What is your suggestion to import the geometry then?

[Tobi]

CAD files are okay. But after exporting single surfaces you will never get a closed surface. Just open paraview and load your STL. Show the edges and you wlil see.

[cristian.arbe]

So should I stick with the STL files even if there are some errors or is there something I can do to fix it?

[Tobi]

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. Keep in mind that the interfaces should be identical triangulated. Export the surfaces as STL and combine them like

cat *.stl > mySTL.stl
surfaceCheck mySTL.stl

Then you should have a waterproofed STL.


PS: If you stick your STL together, you would end up with a non closed STL -> bad. This happens always if you export out of CAD software (ALWAYS). You can export the whole geometry, then you get a closed STL but then you do not have regions // single patches (thats the problem).

[cristian.arbe]

I tried installing and running SALOME but I get the error

ImportError: No module named site

followed the README and set the environment variables but still getting the error.

Edit: solved by downloading the generic binaries instead of Ubuntu ones.

[cristian.arbe]

So what you are saying is to export the STL geometry from SALOME or to actually mesh the model on SALOME and export the mesh?