strange behaviour in the "interface" between two reference frames (simpleFoam MRF)
1 Attachment(s)
Hi Foamers!
I have been exploring the use of the Multiple Reference Frame in OpenFoam but there's something I am doing wrong and I couldn't find what it is. I was hoping you could help. I did the mixerVessel2D tutorial and I wanted to try a simple 3D example. I am simulating a propeller in a circular domain (I know I could simulate this in a single reference frame but I want to learn about MRF). My problem is I get a strange velocity field close to the "interface" between the rotating and stationary part. I have attached an image for the mesh and vertical velocity. The rotating part of the mesh is the shaded area. By the way, I am using OpenFoam-3.0. Anyone can tell me what is wrong with the simulation? Thank you. Carla 0/U file: Code:
#include "../system/runConditions" Code:
#include "../system/runConditions" Code:
4 Code:
MRF1 |
Hi,
I am testing simple geometry using MRFSimpeFoam and AMI interface. However, my solution was diverged due to a large value of "time step continuity errors". I wonder if you can share your experience to solve this issue. I looking forward to hearing from you soon. Quote:
|
Hi davidtran,
I am not sure I understand what you are trying to achieve. As fas as I am aware, you don't need to use AMI with MRFsimpleFoam (what OF version are you using?). AMI is used when you've got a part of the mesh moving and a stationary one. In MRFsimpleFoam nothing is moving, simply Navier Stokes equations are solved in two different reference frames: for the cells in the rotating region (which are defined by a cellZone in OF) NS equations are solved in a rotating reference frame, and for the cells outside the rotating region, stationary (same as ever) NS equations are solved. Regarding my issue I had to refine more the rotating region and the region around the rotating region. But I am not sure you've got the same issue. If you could post your case I might be able to tell if it's the set up, mesh, boundary conditions or numerics what is causing your divergence. |
Hi cvillescas,
Thank you for your response. I want to perform MRFSimpleFOAM with AMI because the convergence result of MRF simluation will be used for unsteady simulation later (pimpleDyMFoam solver). I think that AMI technique is to interpolate flux between two interfaces of different fluid region. So it does not matter as a fluid domain is modeled as rotationary or stationary. Am I right? I uploaded both cases including MRFSimpleFoam only and MRFSimpleFoam with AMI interface. Both of them was not converged. Please help me figure out the problem. 1. MRFSimpleFoam only https://www.dropbox.com/s/xs3ooxsjdw...ly.tar.gz?dl=0 2. MRFSimpleFoam with AMI interface https://www.dropbox.com/s/r8jcnssyw4...am.tar.gz?dl=0 I looking forward to hearing from you. Quote:
|
Do you still have this problem?
If so, Can I ask you how do you create your mesh? I feel like it seems the mesh interface is ill-defined and this is why you get spurious velocities at the interface. Have you tried using the same mesh for AMI? AMI usually gives you a better idea if somehting is going wrong because you can do a transient analysis and you can also see the mesh motion (which makes everything much more clear). I suggest you try and design your own 2D test case first before moving to 3D. The tutorials for AMI and MRF are quite poor I find. I have one lying around for a Taylor-Couette flow, I could try to find it! Cheers BB Quote:
|
That makes sense :) Let's focus on converging the case without AMI and we can move on from there then.
I had a quick look at your case and I reckon your boundary conditions at the inlet are not quite right. If you fix pressure and velocity at the same time the solver might not be able to find a solution that complies with all the restrictions (that would explain the continuity errors). Try zeroGradient for pressure at the inlet. If you still have problems after this we can have a look at the numerics. |
Hi Bruno,
I created the mesh with snappyHexMesh and I overcame the problem refining. Also, I later found out that my omega velocity was an order of magnitude greater of what it was meant to be. I reckon decreasing the omega also helped. Later on, I started using AMI and I started seeing again some spurious velocities, but not as high as the ones I showed here. I've been told GGI in foam-extend is much better than AMI but haven't tried yet. And yes, it would probably be better to study a 2D case first :) Thanks for your answer! CV |
1 Attachment(s)
Hi cvillescas,
I have followed your guide by changing zeroGradient BC for pressure at the inlet. In addition, I also reduced "relTol" in fvSolution to 1e-5. However, the solution was blow-up at Time = 22. You can see from the attached file. I looking forward to hearing from you. Quote:
|
Hi davidtran,
Can you try with this fvSchemes? Code:
ddtSchemes I am not 100% sure of this but I think linear scheme is a central differencing scheme, which wouldn't be suitable for velocity. You need and upwind-biased scheme. linearUpwind is as accurate as limitedLinear and is upwind-biased. If this doesn't work, upwind is only first order accurate but will most certainly work. You could run upwind for the first iterations and then switch to linearUpwind. I hope that helps!! |
Hi cvillescas,
I am sorry for my late response. Firstly, there is a good new. I got a good convergence as the leastSquares of gradScheme was used only. Now I am trying to test the second case which involves the use of MRFsimpleFoam and AMI interface. In this case, the solution was converged up to roughly 500 time step. After that, it was gradually diverged due to time step continuity error. Any idea? I looking forward to hearing from you. Quote:
|
Hi Carla,
Do you have experience in varying the domain around the propeller to see how that changes results? I get very different results depending on how far I extend it up- and downstream. Would you mind sharing your case? I also still have some issues with my snappyHexMesh, which I think are memory related. Do you use a .stl cylinder to define the rotating zone? Do you add layers to that or only to the propeller? Many thanks, Greetings, Bruno |
Hi Bruno,
I saw your question and I think it's a very interesting exercise but I've never studied how the size of the rotating region affects results. I didn't answer your question because I don't know how to properly explain this, I was hoping some else would. The thing is I went to the last OF workshop and one of the founders and developers of foam-extend said there's a term in the equations (I think is the time derivative of phiCorrect) that is added at a given time step and substracted at the next time step. He said that when you have a rotating mesh, you are adding and substracting different things and you shouldn't be. He said that's the reason why you get different results when you run at different Courant numbers and I think that could be the reason why you are getting different results. Following this reasoning, I would say the smaller the rotating region the better, I don't know if that matches your experience. Do you have experimental data? Are you also simulating a propeller? I've been trying to find the slides he was putting when he presented this but I haven't, sorry. He also said this would be solved with the next foam-extend release, foam-extend 4.0. It should be released shortly. Myself I've been focusing on how the numerics affect the results, and at the moment my simulation highly depends on the gradient scheme and limiter that I choose, which is not acceptable. I've tried both rotating mesh and rotating reference frame and I get similar variations in propeller forces depending on the grad scheme and limiter, so the stated above is not the (only) reason why I get bad results. I've uploaded the case here so that you can have a look, If you can spot anything that's wrong please tell me! I've been told it's the mesh but no luck in that front so far. I still have some things to try, though. And davidtran, I tried the fvSchemes that I posted here and with the BC for pressure at the inlet of zeroGradient and it runs past the 500 iterations (up to 1000 at least). If you still want to use your settings, why don't you create the AMI from the converged solution of your run without AMI? I've never done it but it should work. You should be able to do it with Code:
createBaffles Code:
mergeOrSplitBaffles -split |
Hi Caria,
Thank you so much for sharing your experience. They help me a lot. I will try to test my simulation based on your comments. Best regards, |
Quote:
But with the single core, it gives good converging without any problem. |
Quote:
Thanks for the reply. I'm using MRF, not AMI, so I don't think that applies to my case. Good to know in case I do switch to AMI though. I'm just a bit scared a bit about calculation times. I'm not working on a loose propeller, I'm working on a fully modeled quadcopter, with 4 MRF zones. I do have flight data but before even attempting to calibrate/validate, I want to find out how the size of the MRF domain dictates the result. Will keep an eye on it and keep you posted! Will also have a look at your case :) *edit* Quickly comparing meshes (I haven't gotten your results in yet) there's some things that may point me in the right direction already. You have a whole lot more domain finely meshed behind the propeller. Obviously, when I increase my MRF domain size, the refinement increases as well, as my refinement is linked to my MRF cylinders, which may cause some of the differences between the cases with different MRF domain sizes. I'd say your domain overall seems relatively small though, meaning the height and width of the bounding box related to the diameter of your propeller. Also, the mesh quality of the propeller seems relatively low? Other random things I notice; Why do you have U=0 fixedValue on the side walls, is this the case in the physical, real-life scenario? Rotation speed really around 600rpm? (I'm not used to ship propellers so could be). Seems so high as U is only 3.6. |
Hi Bruno,
Thank you for your answer. Definitely not your case if you are not using AMI, sorry. Good guess with the refinement, that could be it. Let us know if you confirm this. Thanks for your advice. I will try increasing the domain size and obviously propeller refinement (that was my main front up to now, but I find the quality of the AMI decreases when I refine and my simulation crashes, I might need to define AMI further away from the propeller). I thought I had slip walls on the sides, I don't think it makes much of a difference but thank you for spotting that. In the experiments they do have walls but I don't want to be simulating that. And yes, rotation speed is 600rpm and is a normal speed for a marine propeller, you could even have 1000rpm. Carla |
Quote:
Thanks. Your suggestions worked for me Cheers, |
Hello,
I think I am facing the same issue. I am trying to simulate a propeller using MRF +simpleFoam. I have described my problem in this post. I am getting zero velocity field outside the whole domain except on the blade. My question is do we need some kind of interface between MRF zone and statioanry zone? Normally, I was thinking we don't need it but seeing the results I think I am missing something. Any comments? |
All times are GMT -4. The time now is 08:37. |