[JeroenVanmassenhove]

Dear CFD-online forum users,

I'm currently working on my master thesis, but i'm stuck with openfoam calculation.

-short sketch of the thesis:
It's about the optimal wind and rain comfort around high rise buildings, with a case study about the 'MAS' in Antwerp, Belgium. After thousands of problems concerning the building of the mesh in gambit (program I had to work with as said by my professor), I finally reached the stadium where I could have a working export .msh file and I have used 'fluent3DMeshToFoam' to make my mesh in Openfoam.

-The mesh has several BC like the West is the inflow, North and South are symmetryPlanes and the East is the outflow, ...

-At this point, the simulation started, but crashed after several timesteps. The residuals showed a very strange behaviour: They don't go down as fast as they should, after some timesteps, the residuals reset to 1 and after some timestaps beyond the reset, right before crashing, the residual of 'p' becomes higher than 1 after 1000 iterations, causing it to crash.

I'm not very familiar with CFD, as i'm only using it for a part in my thesis.

I've added a screenshot of the residual-plot.


In the attachment you'll find the logfile of the simulation.

Thanks in advance!

Kind regards

[gonpe]

Hi Jeroen

Looks like your run diverged relatively quickly.
I am not too familiar with converting Fluent meshes into Foam Meshes but I know mesh quality can sometimes be an issue.

Did you run the checkMesh utility to check the quality of your mesh?

Goncalo

[JeroenVanmassenhove]

Originally Posted by gonpe

Did you run the checkMesh utility to check the quality of your mesh?

Thanks for your fast reply. I started working on my mesh as soon as you answered, but I forgot to reply here, sorry. So, at that time, it had 2 fails in the checkMesh. There were wrongOrientedFaces and nonOrthogonalFaces present at that time. I was able to fix the first error, but there are still some nonOrthogonalFaces present (checkMesh in a file attached here concerning my current mesh).

Since my meshing program (Gambit) is acting up on me and crashing a lot, i'm concerned that it may be a lot of work for no reason, I mean that I really must be sure it's my mesh that is causing the problems.

I hope someone has the time and wants to look at my setup. I have been fiddling around with different solvers, relaxation factors, ... But I really don't know exactly what I'm doing wrong.
Every timestep, the initial residual is for example 0.1 with the final residual 0.002, but in the next timestep, it says that the initial residual is something like 0.11 or something, not the 0.002 from the previous timestep.

I zipped my directory and uploaded to dropbox, since it's too large to put on here.

https://www.dropbox.com/s/owqtw8ki7s...m-MAS.zip?dl=0

In there, you'll see that in the '0' directory, my mesh has been converted with 'fluent3DMeshToFoam'. To save file size, I deleted my .msh file and the '1' directory, which is created after the command 'renumberMesh' to speed up the process.

I hope someone can find the solution quickly (and even get it running with my current mesh).

Thanks!

[sheaker]

I have just run Your case.

Time = 31

DILUPBiCG:  Solving for Ux, Initial residual = 0.328793, Final residual = 0.0101797, No Iterations 2
DILUPBiCG:  Solving for Uy, Initial residual = 0.272819, Final residual = 0.00795739, No Iterations 2
DILUPBiCG:  Solving for Uz, Initial residual = 0.326133, Final residual = 0.0115309, No Iterations 2
GAMG:  Solving for p, Initial residual = 0.53214, Final residual = 4.76677e-05, No Iterations 38
GAMG:  Solving for p, Initial residual = 0.0161664, Final residual = 1.52874e-06, No Iterations 31
time step continuity errors : sum local = 2.64571e-05, global = -4.08299e-06, cumulative = -7.54567e-06
DILUPBiCG:  Solving for epsilon, Initial residual = 0.713892, Final residual = 0.000604893, No Iterations 1
bounding epsilon, min: -4.52933e+06 max: 7.7203e+11 average: 212695
DILUPBiCG:  Solving for k, Initial residual = 0.560936, Final residual = 0.000447181, No Iterations 1
bounding k, min: -33406.4 max: 9.14964e+09 average: 3970.52
ExecutionTime = 6564.47 s  ClockTime = 6579 s

Time = 32

DILUPBiCG:  Solving for Ux, Initial residual = 0.587645, Final residual = 0.00682674, No Iterations 2
DILUPBiCG:  Solving for Uy, Initial residual = 0.380312, Final residual = 0.00559989, No Iterations 2
DILUPBiCG:  Solving for Uz, Initial residual = 0.653642, Final residual = 0.0581962, No Iterations 1
GAMG:  Solving for p, Initial residual = 0.221871, Final residual = 1.85799e-05, No Iterations 38
GAMG:  Solving for p, Initial residual = 0.365829, Final residual = 2.89263e-05, No Iterations 21
time step continuity errors : sum local = 8548.7, global = 590.713, cumulative = 590.713
DILUPBiCG:  Solving for epsilon, Initial residual = 0.999996, Final residual = 0.00375216, No Iterations 1
bounding epsilon, min: 0 max: 5.22988e+14 average: 3.48458e+08
DILUPBiCG:  Solving for k, Initial residual = 1, Final residual = 0.00252026, No Iterations 1
bounding k, min: 0 max: 5.40522e+14 average: 1.75143e+08
#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam221/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::sigFpe::sigHandler(int) in "/opt/openfoam221/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2   in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/openfoam221/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4  void Foam::divide<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/opt/openfoam221/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#5   at kEpsilon.C:0
#6  Foam::incompressible::RASModels::kEpsilon::correct() in "/opt/openfoam221/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#7  
 in "/opt/openfoam221/platforms/linux64GccDPOpt/bin/simpleFoam"
#8  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9  
 in "/opt/openfoam221/platforms/linux64GccDPOpt/bin/simpleFoam"
Floating point exception (core dumped)
sheaker@sheaker-Lenovo-Y50-70:~/Desktop/ablSim-MAS$

[JeroenVanmassenhove]

Originally Posted by sheaker

I have just run Your case.

Thanks for that. You encounter the same problem as I do, that the simulation doesn't go any further and it doesn't converge, as seen in the original post's screenshot. I don't know why and and I don't know any solution to this.

[sheaker]

Is Your mesh auto-generated? As I know sometimes auto-generated mesh isn't good enough.

Think about max aspect ratio (around 1100).
Your smallest cell are very small. Isn't Your timestep too long?

[JeroenVanmassenhove]

Originally Posted by sheaker

Is Your mesh auto-generated? As I know sometimes auto-generated mesh isn't good enough.
Think about max aspect ratio (around 1100).

Nope, as stated previously, I made this mesh with Gambit. It's a pain to adapt things at this moment. I don't think 1 cel with such high aspect ratio will cause the whole simulation to fail, right?

Originally Posted by sheaker

Your smallest cell are very small. Isn't Your timestep too long?

I have no idea how long a timestep should be what so ever.

[sheaker]

Try to set write interval to 1. You will be able to start simulation from the point it crashed.
If your simulation crash then decrease Your timestep to 0.5 or 0.2 or 0.1 ...

Also read this.
https://en.wikipedia.org/wiki/Couran...Lewy_condition

[akidess]

Oskar, Jeroen is running a steady state simulation. Thus the time step can be chosen arbitrarily.

[JeroenVanmassenhove]

I need to know what's wrong with this simulation. I just want to make sure the input files and so on are correct, can anyone verify this?

[akidess]

Jeroen, your mesh is not great. Specifically, your non-orthogonal cells can make it blow up. Don't use corrected schemes and introduce gradient limiters. Ideally, make a better mesh (if you have an STL, be sure to try snappyHexMesh).

Apart from that, I'm surprised you used fixedValue for k on "west" instead of atmBoundaryLayer stuff as on the other fields. Is the atmBoundaryLayer BC not suitable for the "top" boundary?

Also, try getting the simulation to run without the symmetry boundary conditions for now.

Edit: Not the source of your problems, but the atmBoundaryLayer stuff has very recently been updated. See http://www.openfoam.org/mantisbt/view.php?id=1384

[JeroenVanmassenhove]

First of all, thank you for taking the time and effort to really look at my case, thanks!

Originally Posted by akidess

Specifically, your non-orthogonal cells can make it blow up.

Wow, didn't know they could mess things up this badly. I will work on getting those non-orthognal faces out.

Originally Posted by akidess

Apart from that, I'm surprised you used fixedValue for k on "west" instead of atmBoundaryLayer stuff as on the other fields. Is the atmBoundaryLayer BC not suitable for the "top" boundary?

I will look into this.

[JeroenVanmassenhove]

Originally Posted by akidess

Apart from that, I'm surprised you used fixedValue for k on "west" instead of atmBoundaryLayer stuff as on the other fields.

In you're 'edit' and link to that discussion, it is stated that

The inlet condition used for the turbulent kinetic energy k is a uniform value equal to (U^*)^2/sqrt(cmu) where U^* is the friction velocity and cmu is the constant of the k-epsilon model that usually is used with the value 0.09.

So that's why it is fixedValue compared to atmBoundaryLayer stuff. Also, i'm using OpenFoam 2.3.0, since I have to use a package written by someone at our university concerning wind driven rain (Wdr is for after my windsim runs smoothly)