[unsteady-eddie]

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:rintStack(Foam::Ostream&) at ??:?
#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:

1. has anyone got openFOAM to work with zero speed set for a cyclicAMI zone?
2. can openFOAM handle rotating meshes inside each other?
3. can openFOAM handle cyclicAMI zones with miss-matching meshes?
4. looking at my mesh, is that "seam/artifact" likely to be the issue?
5. does anyone know a method of removing/preventing these 'seams' from appearing in a Salome mesh?
6. is there a better alternative mesher to use which can also create geometry?

The whole folder is also on the same dropbox link.

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)

[benchwell]

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

[unsteady-eddie]

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.

[benchwell]

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