|
[Sponsors] |
Foam crashes due to bug or dodgy mesh, or something else? |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
New Member
Join Date: Jan 2019
Posts: 2
Rep Power: 0 ![]() |
Hi, I'm new to OpenFOAM. I have run a few tutorials OK, but I am having trouble running a similar case to these, but with two concentric MRF/cyclicAMI zones. The problem I get is that after about 10 iterations OpenFOAM 6 crashes with:-
"#0 Foam::error: ![]() #1 Foam::sigFpe::sigHandler(int) at ??:? #2..." From the quick look I had online,it seems that the error message might relate to a floating point error (divide by 0 etc). To start simple I had set both the MRF zones to have zero speed (so stationary). In case having a zero speed was the cause of the crash, I re-ran it setting the motions to 0.001rad/sec, but still get the same error message. One of the reasons I wanted to have a zero speed is that the mesh I created with Salome 8.04 has an unwanted region of higher dense mesh in it. For want of a better word there is a 'seam' in the mesh of the solid cylinder I created in Salome (by New entity, Primitive, Cylinder). I had a go but could not repair it (Salome did not detect any error to repair). Images of the geometry are in this link: https://www.dropbox.com/sh/u12umxwgr...9GAAvhSna?dl=0 You'll see there is a 'seam' on the solid disc by the x-axis, that then means the mesh density increases here. This then appears on the objects it has cut. One of the reasons I was not too bothered by this at first is because the "Propeller tutorial" uses unstructured meshes that rotate within each other. I might be wrong as have not run this one, but it also seemed to be able to cope with different mesh densities between the rotor and stator mating faces, which impressed me. So, not knowing the limitations of OpenFOAM I'm a bit stuck as to what to do next. Before looking deeper, it would greatly help if the following questions could be answered:
The case is basically two concentric rotating zones (rotor boundary layer, rotor outer layer) in a "wind tunnel" (stator). Thank you. (this is OpenFoam6, Salome 8-4-0, running on Ubuntu 16-04) Last edited by unsteady-eddie; January 10, 2019 at 06:20. Reason: OS and package version info added |
|
![]() |
![]() |
![]() |
![]() |
#2 |
New Member
Felix Weiler
Join Date: Nov 2016
Location: Bremen
Posts: 22
Rep Power: 9 ![]() |
Hi,
I had a look at your case and the log file. You should probably start by increasing the number of nNonOrthogonalCorrectors (system/fvSolution, start with a value of 4) as your mesh is not a blockstructured one. Best regards, Felix |
|
![]() |
![]() |
![]() |
![]() |
#3 |
New Member
Join Date: Jan 2019
Posts: 2
Rep Power: 0 ![]() |
Hi Felix,
Thank you for your reply. I tried nNonOrthogonalCorrectors=4 Sadly this alone is not the fix. (I tried all the values from 1-7 too. Set to 2 it did the most iterations without crashing 20+. All values above 4 seemed to do was increase the calculation time per successful iteration, while reducing the number of these to 5 or so). I'll keep 4 for now but... 1) What is the reason you suggest 4 and not another value, say "2"? Sadly, from the User Guide (https://cfd.direct/openfoam/user-guide/v6-fvsolution/) I am none the wiser on how to go about choosing a "good" value for this setting. 2) Do I need to change pRefCell and pRefValue too; or change the setting from 10 in potentialFlow? (I haven't yet). 3) Are you able to comment from your experience on the likelihood of the seam/artefact in the mesh causing an issue? Thank you. ![]() Last edited by unsteady-eddie; January 19, 2019 at 09:42. Reason: correcting format |
|
![]() |
![]() |
![]() |
![]() |
#4 |
New Member
Felix Weiler
Join Date: Nov 2016
Location: Bremen
Posts: 22
Rep Power: 9 ![]() |
1) The value of 4 is merely a result of personal experience. It is often necessary to evaluate computational speed (less corrector loops) against accuracy/stability (more loops). There won't be a "best" value, that will make your simulation converge when other values wouldn't
2) Having pRefCell and pRefValue set to 0 seems to be common practice, no need to change 3) Mesh artifacts will often crash simulations. However, checkMesh -allGeometry didn't come up with anything significant. The AMI-patches are somewhat odd as they feature some very small cells next to larger ones. What you could do: - Write out timesteps and look if there are any artifacts in the results (e.g. cells with very high velocity) - Change the mesh generation procedure - Experiment with a simler case, 2d or maybe just one AMI-pair Best regards, Felix |
|
![]() |
![]() |
![]() |
Tags |
sigfpe |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
problem during mpi in server: expected Scalar, found on line 0 the word 'nan' | muth | OpenFOAM Running, Solving & CFD | 3 | August 27, 2018 04:18 |
[snappyHexMesh] How to define to right point for locationInMesh | Mirage12 | OpenFOAM Meshing & Mesh Conversion | 7 | March 13, 2016 14:07 |
[snappyHexMesh] No layers in a small gap | bobburnquist | OpenFOAM Meshing & Mesh Conversion | 6 | August 26, 2015 09:38 |
[Gmsh] Import problem | ARC | OpenFOAM Meshing & Mesh Conversion | 0 | February 27, 2010 10:56 |
[blockMesh] Axisymmetrical mesh | Rasmus Gjesing (Gjesing) | OpenFOAM Meshing & Mesh Conversion | 10 | April 2, 2007 14:00 |