CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

Run A propeller case with AMI and not accelerated flow behind the blades...

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 1 Post By Artur
  • 1 Post By giovanidiniz

Reply
 
LinkBack Thread Tools Display Modes
Old   July 2, 2013, 16:12
Default Run A propeller case with AMI and not accelerated flow behind the blades...
  #1
Member
 
reza1980's Avatar
 
reza
Join Date: Jan 2013
Location: Goteborg-Sweden
Posts: 79
Rep Power: 4
reza1980 is on a distinguished road
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
Attached Images
File Type: jpg ami1.jpg (79.1 KB, 57 views)
File Type: jpg mrf1.jpg (85.7 KB, 61 views)
File Type: jpg ami2.jpg (59.8 KB, 54 views)
File Type: jpg ami3.jpg (69.5 KB, 46 views)
File Type: jpg ami4.jpg (70.8 KB, 38 views)
reza1980 is offline   Reply With Quote

Old   September 1, 2013, 16:46
Default Ami
  #2
New Member
 
Giovani Diniz
Join Date: Jun 2013
Location: Boston
Posts: 13
Rep Power: 4
giovanidiniz is on a distinguished road
Send a message via Skype™ to 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
giovanidiniz is offline   Reply With Quote

Old   September 2, 2013, 04:17
Default
  #3
Member
 
reza1980's Avatar
 
reza
Join Date: Jan 2013
Location: Goteborg-Sweden
Posts: 79
Rep Power: 4
reza1980 is on a distinguished road
Hi,
I am fine . I will be happy if I can help you.
Reza
reza1980 is offline   Reply With Quote

Old   September 4, 2013, 10:19
Default
  #4
New Member
 
Giovani Diniz
Join Date: Jun 2013
Location: Boston
Posts: 13
Rep Power: 4
giovanidiniz is on a distinguished road
Send a message via Skype™ to 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
giovanidiniz is offline   Reply With Quote

Old   September 5, 2013, 04:20
Default
  #5
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 226
Rep Power: 6
Artur is on a distinguished road
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
holodeck10 likes this.

Last edited by Artur; September 5, 2013 at 04:22. Reason: One final thought
Artur is offline   Reply With Quote

Old   September 10, 2013, 16:24
Default Thanks!!
  #6
New Member
 
Giovani Diniz
Join Date: Jun 2013
Location: Boston
Posts: 13
Rep Power: 4
giovanidiniz is on a distinguished road
Send a message via Skype™ to 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
holodeck10 likes this.
giovanidiniz is offline   Reply With Quote

Old   September 11, 2013, 03:09
Default
  #7
Senior Member
 
Artur's Avatar
 
Artur
Join Date: May 2013
Location: Southampton, UK
Posts: 226
Rep Power: 6
Artur is on a distinguished road
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 ).
Artur is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -4. The time now is 07:08.