[reza1980]

Hi Dear Foamers,

I face with a problem in my results for AMI. the flow behind the blade is not accelerated .I am wondering that perhaps AMI implementation is not used correctly .
To make sure I state my method as below,

-crate two parts as rotor and stator.
-merge meshes.
-change the AMI from patch to cyclic and update the boundary dict.
-uses this command to create CellZones.
splitMeshRegions –makeCellZones –overwrit.

But, in this regard,I don't know the createAMIFaces.topoSetDict is necessary? If so,how it should be updated ?
One more thing is this message in my log file;
[21] AMI: 8 non-overlap faces identified
[22] AMI: 10 non-overlap faces identified
[23] AMI: 16 non-overlap faces identified

I look froward to hearing from you
Best
Reza

[giovanidiniz]

Reza, how are you?

I've been having the same problem you described with the AMI. Did you figure out what was the issue?

I'm running a few cases now to verify my mesh and see if it's a refinement problem and I'll let you know.

Best
Giovani

[reza1980]

Hi,
I am fine . I will be happy if I can help you.
Reza

[giovanidiniz]

Hi, thanks for your reply.

I've been trying to analyze marine propellers using OF 2.2.0 and faced the same issue you did with the non-overlapped faces.

I use snappyHexMesh to generate my mesh and it seems quite good so far. When I run checkMesh, I have a couple of highly skewed faces, but that' s about it. All seems good.

However, when I reach a certain time step, the simulation kept blowing up due to Floating point exception. I changed my mesh a few times (refining the boundaries of the rotating mesh) and I don't get the non-overlapping faces warning anymore, but the simulation still keeps blowing up at the same time step.

So, as I read your thread, I wondered what you did to solve the issue, if you did. that would help me a lot to try to figure out what is the issue in my case.

Unfortunately, I cannot share the files for the content and geometry are confidential.
I am using k-omega model for turbulence and running pimpleDyMFoam for the analysis.

Any info you could share would be of great help.

I appreciate your time and hope you have a good day.

Cheers

[Artur]

A few tips for generating a working sHM for using AMI (all of them based on my individual experience and may not necessarily be true):

- coarser meshes seem to crash less often
- increasing the match tolerance in the AMI setup makes the case more stable (I tend to use quite high values, up to 0.1, and still get good results)
- push up the no. featureSnapIterations to make your mesh conform to the cylindrical shapes better (I use between 30 and 35)
- keep the no. smoothing iterations fairly low
- use a high no. solverIters (300 should do)
- it seems to help a bit if you have the same level of refinement all over the AMI boundary
- also, when you see some skewed faces next to the edge of your AMI try to move it a bit with respect to the background blockMesh; it seems to help quite a bit too in avoiding the f.p. exception

Hope some of this will help you out.

Cheers,

A

[giovanidiniz]

Artur,

First of all, thank you SO MUCH for your reply. Really appreciated, mate!
It took me a while to get back here because I was testing my case with the tips you posted.

It actually was a bit of a problem in my geometry that was holding the simulation. I was creating the geometries and the stl files in matlab, and not in a CAD software, so I did not realize what was going on.

In fact, the hub must be divided so that there's no face "in the middle" of the intersection with the cylinder (that defines the dynamic mesh). I only noticed that I had put those segments into different regions of my stl file and not in different files. And that was causing all the trouble.

It took me VERY LONG time to understand because I ran a case before without dividing the hub, but without layers. So, when I ran the full case with layers, it was blowing up all the time. When I separated the hub in different files, it worked like a charm.

I just would like to thank you again for your assistance. I keep a log file with all the comments (mine and now, yours) so I can quickly diagnose problems in the future. So I appreciate your comments a lot!

Now, I have left the case running in parallel (16 processors) and it took 30 hours to run 360deg. How does that sound to you?

I fixed the Courant number to 1 and the average timestep is in the order of 1e-5. I do have very small cells because I refined a lot on the leading/trailing edges area, in order to get the edges correctly.
But, it is the first time I'm running a simulation in parallel, so I'm not sure if that has been taking too long.

I appreciate any comments you have and hope you have a great week, mate!

Cheers

Giovani

[Artur]

Yes, I divide my hub and shaft as well, I guess I forgot to mention that, glad you figured it out yourself

I've found that you can retain stability with a higher Courant number. By default I run at 2.5 and it converges without problems most of the time (takes about 6-8 hrs more or less for one revolution with the props that I've been testing). When I see problems with stability I reduce it (don't usually go below 2.0 though). Once, out of sheer curiosity, I had the Potsdam propeller test case running with k-omega SST at max Co of 6.0 and quite unexpectedly it seemed to be doing OK (not that I'd recommend doing that on a regular basis ).