[WernerW]

Hi Luois !

With your hack my simulation is now running. I had to introduce that line of code in both AMI1 and AMI2 boundary conditions. Thank you very much !!

best regards,
Werner

[WernerW]

Hi again,

The simulation ran for a couple of hours (in debug Mode) and then the courant number began growing dramaticly before the solver crashed.

What is making the courant number to grow that way ? May it be because the simulation starts working with the finer cells of my model that have a smaller deltaX ? (having in mind that the courant number is Co=U*deltaT/deltaX)

Do you have any ideas of how to solve this issue?

thank a lot in advance,
Werner

Courant Number mean: 1.58406e+10 max: 5.5251e+18
deltaT = 1.27898e-38
--> FOAM Warning :
From function Time:perator++()
in file db/Time/Time.C at line 1061
Increased the timePrecision from 7 to 8 to distinguish between timeNames at time 0.000836173
Time = 0.00083617293

solidBodyMotionFunctions::rotatingMotion::transfor mation(): Time = 0.000836173 transformation: ((0 0 0) (0.999998 (0.00219077 0 0)))
AMI: Creating addressing and weights between 11445 source faces and 11385 target faces
AMI: Patch source sum(weights) min/max/average = 0.52426, 1.5688, 0.999447
AMI: Patch target sum(weights) min/max/average = 0, 1.32047, 0.98348
AMI: Patch target identified 84 faces with weights less than 0.2
PIMPLE: iteration 1
smoothSolver: Solving for Ux, Initial residual = 0.725092, Final residual = 0.0085745, No Iterations 1000
smoothSolver: Solving for Uy, Initial residual = 0.888055, Final residual = 0.00400061, No Iterations 1000
smoothSolver: Solving for Uz, Initial residual = 0.90349, Final residual = 0.00305682, No Iterations 1000
GAMG: Solving for p, Initial residual = 1, Final residual = 0.00762114, No Iterations 10
GAMG: Solving for p, Initial residual = 0.0762132, Final residual = 0.000454403, No Iterations 4
GAMG: Solving for p, Initial residual = 0.00866505, Final residual = 6.5352e-05, No Iterations 5
time step continuity errors : sum local = 5.07099e+37, global = 1.60258e+34, cumulative = 1.60258e+34
GAMG: Solving for p, Initial residual = 0.00101329, Final residual = 7.52296e-06, No Iterations 5
GAMG: Solving for p, Initial residual = 0.0554729, Final residual = 0.000521735, No Iterations 3
GAMG: Solving for p, Initial residual = 0.0058221, Final residual = 8.72701e-07, No Iterations 11
time step continuity errors : sum local = 3.50618e+35, global = -1.0706e+34, cumulative = 5.3198e+33
smoothSolver: Solving for epsilon, Initial residual = 1, Final residual = 7.36595e-07, No Iterations 42
smoothSolver: Solving for k, Initial residual = 0.999998, Final residual = 0.0137714, No Iterations 1000
bounding k, min: 2.18625e-70 max: 4.94981e+122 average: 1.2043e+117
ExecutionTime = 2833.72 s ClockTime = 2994 s

forces forces output:
sum of forces:
pressure : (5.63196e+127 4.50394e+127 2.04517e+127)
viscous : (2.21528e+134 -2.32353e+135 6.78297e+133)
porous : (0 0 0)
sum of moments:
pressure : (-8.87904e+129 6.95887e+129 7.50734e+129)
viscous : (4.5602e+137 6.44412e+136 -8.49082e+136)
porous : (0 0 0)

Courant Number mean: 3.86218e+40 max: 8.868e+48
deltaT = 2.88449e-87
--> FOAM Warning :
From function Time:perator++()
in file db/Time/Time.C at line 1061
Increased the timePrecision from 8 to 9 to distinguish between timeNames at time 0.000836173
Time = 0.000836172933

solidBodyMotionFunctions::rotatingMotion::transfor mation(): Time = 0.000836173 transformation: ((0 0 0) (0.999998 (0.00219077 0 0)))
AMI: Creating addressing and weights between 11445 source faces and 11385 target faces
AMI: Patch source sum(weights) min/max/average = 0.52426, 1.5688, 0.999447
AMI: Patch target sum(weights) min/max/average = 0, 1.32047, 0.98348
AMI: Patch target identified 84 faces with weights less than 0.2
PIMPLE: iteration 1
smoothSolver: Solving for Ux, Initial residual = 0.899469, Final residual = 6.77381e-07, No Iterations 26
smoothSolver: Solving for Uy, Initial residual = 0.913388, Final residual = 8.25847e-07, No Iterations 26
smoothSolver: Solving for Uz, Initial residual = 0.979692, Final residual = 8.50494e-07, No Iterations 22
[5] #0 Foam::error:rintStack(Foam::Ostream&) at ~/OpenFOAM/OpenFOAM-2.4.0/src/OSspecific/POSIX/printStack.C:219
[5] #1 Foam::sigFpe::sigHandler(int) at ~/OpenFOAM/OpenFOAM-2.4.0/src/OSspecific/POSIX/signals/sigFpe.C:108
[5] #2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
[5] #3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ~/OpenFOAM/OpenFOAM-2.4.0/src/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGSolverScale.C:56
[5] #4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMa trix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ~/OpenFOAM/OpenFOAM-2.4.0/src/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGSolverSolve.C:375
[5] #5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ~/OpenFOAM/OpenFOAM-2.4.0/src/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGSolverSolve.C:122
[5] #6 Foam::fvMatrix<double>::solveSegregated(Foam::dict ionary const&) at ~/OpenFOAM/OpenFOAM-2.4.0/src/finiteVolume/fvMatrices/fvScalarMatrix/fvScalarMatrix.C:169 (discriminator 3)
[5] #7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ~/OpenFOAM/OpenFOAM-2.4.0/src/finiteVolume/lnInclude/fvMatrixSolve.C:82
[5] #8 ? at ~/OpenFOAM/OpenFOAM-2.4.0/applications/solvers/incompressible/pimpleFoam/pimpleDyMFoam/pEqn.H:34 (discriminator 1)
[5] #9 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
[5] #10 ? at ??:?

[WernerW]

Hi,

I could solve the problem working with a courser mesh. Now I'll refine it slowly to get a better precision in the results.

Using a searchableCylinder to define the geometry of the slinding Cylinder where the turbine is contained, I was able to avoid the low weight faces on the AMI interface. I guess snappyHexMesh works more stable with this definition that with and .stl for the Cylinder.

thank you all !
Werner

[louisgag]

Originally Posted by WernerW

Using a searchableCylinder to define the geometry of the slinding Cylinder where the turbine is contained, I was able to avoid the low weight faces on the AMI interface. I guess snappyHexMesh works more stable with this definition that with and .stl for the Cylinder.

Thanks for sharing your findings Werner, for my case there is no difference between using searchableCylinder or a .stl file, but this may be linked to the quality of the .stl file.

Regards,


-Louis

[WernerW]

Thank YOU Louis !
What software and settings do you use to generate the .stl file ?

[louisgag]

For the cylinders I use Gmsh with a simple script that generates them. I don't even need to open the graphical interface and it is completely parametrized...

[WernerW]

Hi Louis and OpenFoamers,

I have worked further with my wind Turbine Model and now I'm finding issues since I can't refine the model as much as I need. I hope this is inquiry is not very far away of the topic of the thread.

I have been able to run a model (with pimpleDyMFoam) of a wind turbine already and have got nice results so far. However the torque that I'm getting is just one third of the experimental Torque. Therefore I'm trying to refine my mesh in a Grid Independence test but I'm not able to increase the number of cells over 250 000 cells. Whenever I increase this (e.g. increasing the surface refinement over rotor as you can see in my MeshSensiAna.xls spreadsheet) the solver blows-up with large MaxCourant numbers that get balanced by decreasing deltaTime (since I'm using adjustableTimeStep in controlDict). As a results the simulation advances much slower and crashes eventually. This is presumably because I have too small deltaX in the finer cells.

Some advice is to implement the same region refinement outside of the rotating cylinder so that the sliding interface would have the same cell size at both sides, thus I created a region called CylinderBig (as you may see in my snappyHexMeshDict.txt ), yet with no positive result.

Do you know how to create a finer Mesh and get my simulation running ?. I tried already increaing the relaxationFactors in fvSolution, and refining the mesh changing several parameters (as you may see in MeshSensiAna.xls) but this didnt't work either. I haven't tried yet with other meshing software because I want to understand what is happening with my model and if possible make it run with snappyHexMesh, where I have everything ready.

thanks in advance for your attention,
Werner

ps.
I'm dealing as well with the layer addition that is not properly made. I'm trying to put just 1 layer around the blades and as the addlayers application iterates the layers that I had at the beginning get all removed, aparently because they didn't comply with the meshquality controls.. Do you have any ideas for this issue ?

[louisgag]

Dear Werner,
I only had time to look quickly at your files, but I'd suggest you try to change

the faceType to baffle for your AMI interface:

    refinementSurfaces // Surface-wise min and max refinement level
    {
    rotor         {level (1 4);}
    Cylinder     {
            level (1 1);
            faceType    baffle;
            cellZone        Cylinder;
            faceZone        Cylinder;
            cellZoneInside    inside;
            }

That may help with the quality of the cylinder...

I would also reduce the initial timestep as it seems you Courant number in the first few time steps is too high. Try not to let it ever go above ~5

I hope this leads to to some sort of solution.

Regards,


-Louis

[mahtin360]

Hi Louis,

I'm currently also struggeling with getting a good AMI source and target weights with mesh generated using snappyHexMesh.
I've tried both, using .stl files for the cylinder and creating the cylinder as searchableCylinder in SHMD but both options do not give me a good mesh around the edges of the cylinder.

Further, I'm meshing a number of cylinders and the quality of the mesh around the edges varies quite a bit between cylinders at different positions within my domain.

Could you give some more information as to what actually changes by changing the faceType to baffle?I did this and it solved all the problems i was encountering for a long long long time !! Getting very good numbers now on the patch weights.

AMI: Patch source sum(weights) min/max/average = 1, 1.00006, 1
AMI: Patch target sum(weights) min/max/average = 1, 1.00006, 1
AMI: Creating addressing and weights between 32189 source faces and 32189 target faces
AMI: Patch source sum(weights) min/max/average = 1, 1.05919, 1.00001
AMI: Patch target sum(weights) min/max/average = 1, 1.05919, 1.00001
AMI: Creating addressing and weights between 32120 source faces and 32120 target faces
AMI: Patch source sum(weights) min/max/average = 1, 1.06342, 1.00001
AMI: Patch target sum(weights) min/max/average = 1, 1.06342, 1.00001

Thank you very much

[louisgag]

Hi Martin,

I'm glad this solved your issue. I'm not the code expert, but from what I recall the baffle condition imposes that both inside and outside AMI interfaces have exactly the same cell faces. In the other scenario, the inside and outside interfaces are allowed to be meshed differently.

There seems to be issues when there are big cells on one side of the AMI and small cells on the other.

Best Regards,


-Louis

[mahtin360]

Are you using the splitOrMergeBaffles after this step? I'm getting a lot of errors now in the moveDynamicMesh -checkAMI and it looks like the cells are being pulled by the rotation or there was some error during snapping?

solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 7.69383 transformation: ((0 0 0) (0.996041 (0.0889006 0 0)))
solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 7.69383 transformation: ((0 0.00331939 -0.0371904) (0.996041 (0.0889006 0 0)))
solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 7.69383 transformation: ((0 -0.00331939 0.0371904) (0.996041 (0.0889006 0 0)))
solidBodyMotionFunctions::rotatingMotion::transformation(): Time = 7.69383 transformation: ((0 0 0) (0.996041 (0.0889006 0 0)))
AMI: Creating addressing and weights between 10765 source faces and 10765 target faces
AMI: Patch source sum(weights) min/max/average = 1, 1.13227, 1.00006
AMI: Patch target sum(weights) min/max/average = 1, 1.13227, 1.00006
AMI: Creating addressing and weights between 10532 source faces and 10532 target faces
AMI: Patch source sum(weights) min/max/average = 1, 1.24544, 1.00016
AMI: Patch target sum(weights) min/max/average = 1, 1.24544, 1.00016
AMI: Creating addressing and weights between 10489 source faces and 10489 target faces
AMI: Patch source sum(weights) min/max/average = 1, 1.21772, 1.0001
AMI: Patch target sum(weights) min/max/average = 1, 1.21772, 1.0001
AMI: Creating addressing and weights between 10171 source faces and 10171 target faces
AMI: Patch source sum(weights) min/max/average = 1, 1.16598, 1.00006
AMI: Patch target sum(weights) min/max/average = 1, 1.16598, 1.00006
    Point usage OK.
    Upper triangular ordering OK.
    Topological cell zip-up check OK.
    Face vertices OK.
    Number of identical duplicate faces (baffle faces): 41957
  <<Number of duplicate (not baffle) faces found: 6. This might indicate a problem.
  <<Number of faces with non-consecutive shared points: 7. This might indicate a problem.
    Mesh topology OK.
    Boundary openness (8.17392e-17 1.84432e-16 6.86022e-16) OK.
 ***High aspect ratio cells found, Max aspect ratio: 1.21045e+196, number of cells 652
    Minimum face area = 1.38377e-09. Maximum face area = 0.0101884.  Face area magnitudes OK.
 ***Zero or negative cell volume detected.  Minimum negative volume: -1.46402e-07, Number of negative volume cells: 649
    Mesh non-orthogonality Max: 179.834 average: 15.5283
   *Number of severely non-orthogonal (> 70 degrees) faces: 32041.
 ***Number of non-orthogonality errors: 4562.
 ***Error in face pyramids: 9357 faces are incorrectly oriented.
 ***Max skewness = 48556.3, 19066 highly skew faces detected which may impair the quality of the results
    Failed 5 mesh geometry checks.
    Failed 1 mesh checks.
Calculating AMI weights between owner patch: AMI1 and neighbour patch: AMI2
Calculating AMI weights between owner patch: AMI3 and neighbour patch: AMI4
Calculating AMI weights between owner patch: AMI5 and neighbour patch: AMI6
Calculating AMI weights between owner patch: AMI7 and neighbour patch: AMI8
ExecutionTime = 855.37 s  ClockTime = 855 s

[louisgag]

Hello Martin,

Yes, I use these tools after running snappyHexMesh:

runParallel createPatch $nProcs -overwrite
runParallel mergeOrSplitBaffles $nProcs -split -overwrite; # split baffles when faceType baffles called in snappyHexMesh (baffle solves the problem of badly defined AMI patches)
runParallel topoSet $nProcs
runParallel renumberMesh $nProcs -overwrite
runParallel checkMesh $nProcs

You can use runApplication instead of runParallel is you are not meshing in parallel.


-Louis

[jgross]

Hi,

Might be a bit late to the party on this one, but thought it might be better to post in a thread that is already established, rather than to make another. I was hoping Bruno (or anyone else for that matter) might have some advice for a similar problem.

I am trying to use sHM to make a mesh of a volute casing and the internal volume. I am finding that the quality of the mesh is not very good (particularly the internal volume). In particular, there are a number of skewed faces that are being generated during the patch smoothing iterations.

Here is a link to the directory containing the problem.

https://universityofcambridgecloud-m....000Z&e=jczdgy

Disclaimer: I am using OpenFOAM Extend 4.0. I do not feel there will be any issues if one were to attempt this on normal installations of OF (e.g. OF V5.0), but I have not tested this. The Allrun file will most likely need to be slightly modified however.

Regards,
James

[Gabriela_ro]

Hi everyone!

I have a very similar problem. I don’t have a lot of experience with openFoam and also not with scripting. I have a very complex building geometry that sits on a topography ground and I need to run an air flow around the building.

Attached 2 screenshots of the case.

I am trying for a few days to mesh this with snappyhex and always 2 highly skew faces left and in the last try, also 2 nonOrthoFaces.
I can visualize them in paraview but imposible to find them in my rhino model or stl file. I redid the area there they appear a few times and still no change. They appear in a different location.

I don’t know what parameters to change to improve my mesh. My snappyhex was set up by someone else that I cant contact.
I gave a try to start the simulation but error is: Floating point exception(core dumped)

What I did until now is to increase the level of cells for my building, I am not at 30 cm cell size.

below is my snappyHexMeshDict if anyone would have time to take a look.

Any help is highly appreciated.

Thank you very much!
Gabriela

[louisgag]

Hi Gabriela,

It seems you are using a script to run the case, pyFoam, with which I am not familiar.

The floating point error you mention may be linked to something else than the mesh, I would advise running the case with a smaller mesh step by step to see where it actually "breaks".

Also, to better understand snappy, have a read at this quick guide: https://cfd.direct/openfoam/user-guide/snappyhexmesh/

Good luck,


-Louis

[farzadmech]

Dear pcaron
I am going to test your solution "This problem arises when your surface is almost aligned with the mesh." and see if it works for me or not. I have attached my skewed face to this post.


Thanks,
Farzad

Originally Posted by pcaron

Louis, thanks for your reply. This problem arises when your surface is almost aligned with the mesh. Then some nodes and/or elements are deleted. In my pictures the element is deleted so the surface has a cube inside the mesh, so in the snap stage the nodes are attracted by the stl surface. But, this is the problem, not the solution I don't have a solution either.

Some hints
1) Start with a coarse mesh and add layers. I don't have layer in my pictures.
2) Increase the tolerance in snapControls. In this case the resulting surface has a lot of bumps.

These are just some ideas. I think there isn't a unique solution.

Regards

Pablo

[farzadmech]

Dear Pacron
your suggestion does not worked!

Thanks,
Farzad

Originally Posted by farzadmech

Dear pcaron
I am going to test your solution "This problem arises when your surface is almost aligned with the mesh." and see if it works for me or not. I have attached my skewed face to this post.


Thanks,
Farzad