|
[Sponsors] |
February 3, 2015, 12:57 |
apparent anomalies at ACMI interface
|
#1 |
New Member
Jim
Join Date: Feb 2014
Location: UK
Posts: 22
Rep Power: 12 |
Hi,
I am investigating using the ACMI patch for a fairly simple 2D case as illustrated in the attached picture. The model is being solved using rhoPimpleDyMFoam and the solidBodyMotion FvMesh class. The translating mesh region (translating speed of 60 m/s) is 'empty', therefore one would expect mass fluxes across the ACMI face to be near-zero. However, I am getting quite significant values of velocity/density/temperature at the ACMI boundary. I have attached my fvSolution and fvSchemes and some results pictures to show this. Would anyone be able to suggest the cause of these apparent anomalies and how I might be able to get rid of them? On top of this, would someone be able to explain how the ACMI blending works in greater detail? Thanks |
|
April 24, 2015, 16:32 |
|
#2 | ||
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128 |
Hi James,
Ah, OK, I think I now understand the problem. I came to this thread from the other one you have on this topic: http://www.cfd-online.com/Forums/ope...tml#post543658 Continuing the idea from the other thread, the problem is very likely that you've defined the ACMI wall part as a "movingWall", which is not supported for the blockage parts. If you look at the boundary conditions in "0/u" for the tutorial "incompressible/pimpleDyMFoam/oscillatingInletACMI2D": Code:
ACMI1_blockage { type fixedValue; value uniform (0 0 0); } ACMI1_couple { type cyclicACMI; value uniform (0 0 0); } ACMI2_blockage { type fixedValue; value uniform (0 0 0); } ACMI2_couple { type cyclicACMI; value uniform (0 0 0); } By the way, 60 m/s is very fast! Did you check how it behaves with 6 m/s or 1 m/s? ... wait... I'm not understanding this statement: Quote:
Best regards, Bruno ---------- PS: For future reference, you've also commented about this here: http://www.openfoam.org/mantisbt/view.php?id=1335#c4651 edit: And sent me via private message a few more details: Quote:
Last edited by wyldckat; April 24, 2015 at 16:34. Reason: see "edit:" |
|||
April 25, 2015, 09:05 |
|
#3 |
New Member
Jim
Join Date: Feb 2014
Location: UK
Posts: 22
Rep Power: 12 |
Hi Bruno,
In response to your suggestions:
The odd thing is that the model runs fine when using pimpleDyMFoam, with no anomalies at the corner cells. Regarding the comment on mass flux across the ACMI coupled patch: from memory the model was telling me that there was non-negligible mass flux across the ACMI patch, which seemed odd to me as there could not have been sufficient time for the pressure wave initiated by the moving object to reach that part of the model. I had a look on mantis and a similar issue has cropped up: http://www.openfoam.org/mantisbt/view.php?id=1335 Thanks, James |
|
April 25, 2015, 15:26 |
|
#4 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128 |
Hi James,
I kinda lost track of it all, which was why I tried to point out as much as possible on each post. I knew I had read something you had written about compressible vs incompressible, but only finally managed to connect the dots after the previous post of mine... hence the edit... but I was already too sleepy to think more about it. Well, ACMI has issues, as pointed out in several bug reports. They (OpenCFD, I think) do have scheduled fixing it... including some details regarding AMI. As to when it will be fixed? I have no idea. It's also possible that ACMI simply wasn't tested with compressible solvers at all and that there might be a dynamic mesh update step missing somewhere in the ACMI stack of code. Ascertaining if this was the origin of the problem, or to try to isolate the problem, requires a test case. If you can provide one, preferably a simple one, I or anyone else can try and have a look into this. Beyond this, have you tried something like the tutorial "incompressible/pimpleDyMFoam/movingCone"? It would use complete dynamic mesh and not use ACMI or AMI. The downside is that the mesh would compress and expand... but it could help isolate the origin of the problem. Nonetheless, I can't help but not want to rule out that there is something else... if the air is compressible, it means that it can more easily move and go into the backward/forward step that your geometry is creating. Have you tried to isolate if this problem also occurs with a conventional static mesh? Possibly by using 120 m/s flow, to compensate for the fact that the translating region is in fact static? Best regards, Bruno |
|
April 29, 2015, 11:17 |
|
#5 |
Senior Member
Daniel Witte
Join Date: Nov 2011
Posts: 148
Rep Power: 14 |
Hello,
maybe that helps: - switch off the momentum predictor. This reinitializes the pressure equation each time step to a 0 field. This can cause problems. It is better to resolve the pEq to an acceptable tolerance. - there is a bug in cyclicAMI, the boundary field is applied twice. Maybe that applies for cyclicACMI too. Regards, Daniel |
|
April 29, 2015, 11:43 |
|
#6 | |||
New Member
Jim
Join Date: Feb 2014
Location: UK
Posts: 22
Rep Power: 12 |
Hi Bruno,
Thanks for your suggestions. I shall maybe have a greater look into a test case when I can. A couple of thoughts on your points: Quote:
Quote:
Cheers. Hi Daniel, Quote:
Cheers, James |
||||
April 30, 2015, 03:45 |
|
#7 |
Senior Member
Daniel Witte
Join Date: Nov 2011
Posts: 148
Rep Power: 14 |
Hi James,
In my case it helped changing the pressure level p to a different level than 0. Since interDymFoam that I use is an incompressible solver, the pressure differential should be the same, so you should get the same results shifted by the pressure level you have added at time 0. Then you plot out pEq and identify the cells that deviate. If they do, you know where to look at. This method will not work using a compressible solver, since in this case you have a coupling of the p level to density and therefore the U field. It also helps to keep U to 0 for this test case. Another suggestion is to use another matrix solver. GAMG is good since it is fast in particular if your guess is far away to the final iterated solution. But it is a complicated solver and maybe not the best choice in finding problems in your BCs. Regards, Daniel |
|
April 30, 2015, 11:21 |
|
#8 | |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128 |
Greetings to all!
@James: Quote:
Because from what I can figure out, either:
Bruno |
||
March 16, 2016, 09:40 |
|
#9 |
Member
Antonio Liggieri
Join Date: Aug 2010
Posts: 76
Rep Power: 15 |
Hello FOAMers,
I am building up a simple model with so called "scavenging ports", which are typically applied in two stroke engines. The principle is, that a "flow port" is either blocked or unblocked depending where the piston currently is. This behaviour is very similar to that shown in the "oscillatingInletACMI2D" tutorial: http://www.openfoam.org/version2.3.0/ami.php where ACMI's are used. However, in my case I have not a dynamicMesh region where the mesh topology of that region remains unchanged (solidBodyMotionFvMesh). My dynamicMesh region has dynamic Motion where cells are skewd and streched according to a moving boundary. The problem is, that the mesh is only moved up to the cell, where the ACMI coupling takes place. Please find attached a few figures for better understanding. Does anybody know, whether this is an issue/bug or whether ACMI is simply not made for a combination with dynamicMotionSolverFvMesh. Thank you in advance for your effort. Kind regards Antonio |
|
March 28, 2016, 12:57 |
|
#10 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128 |
Greetings Antonio,
As far as I know, the current implementation of ACMI has a lot of limitations. As for this feature in particular, I suspect that this is not yet fully tested with either. Nonetheless, you might want to test this as well with OpenFOAM+ 3.0+ from OpenCFD, because they are the ones mostly responsible for the ACMI and AMI developments... although I'm not seeing any details related to this in the release notes: http://openfoam.com/version-v3.0+/index.php Beyond these, I expect that foam-extend has this feature already implemented and fully tested (GGI and sliding interfaces), although I haven't tested this myself. By the way, when inspecting a section cut of the mesh, you might prefer to use the "Extract Cells by Region" instead of the "Slice" filter, as explained here: http://openfoamwiki.net/index.php/FA...is_in_ParaView Best regards, Bruno
__________________
|
|
July 6, 2016, 09:01 |
|
#11 |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 51 |
Dear all,
I also build a simple case for a 2 stroke engine using FOAM-2.3.x and FOAM-v3+ without success. In my case the problem was that the ACMI patch type is also used for the point and cell motion field that lead to distortion of the mesh after both interfaces share some faces. Even the ACMI interface had problems as you can (slightly) see here: https://www.youtube.com/watch?list=P...&v=lNavcJb6Pn8 At the corners of the interface I got unphysical results (-70K less than allowed. This can not really be observed due to the fact that I scaled T to good values ). Anyway... in Foam 4.x this bug is now removed. To the 2-stroke engine. Due to the usage of ACMI for the motion fields, I tried to manipulate the fvMotionSolvers (not Top-Level) with (partly) success. My fields look much better now but still I get the ACMI interpolation even if I set the field patch types explicit to zeroGradient for the point and cell motion fields. If you are interested, the related thread is here: http://www.cfd-online.com/Forums/ope...tml#post604241 Maybe this was bugfixed in 4.x, too. Till now I did not check it but it is promising. As Bruno told, GGI should do the work too (but I also did not use it in the past).
__________________
Keep foaming, Tobias Holzmann |
|
July 19, 2016, 07:44 |
|
#12 |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 51 |
Dear all, I managed to get it work yesterday night for moveDynamicMesh solver. Now I know where I have to manipulate the code. I keep you up to date...
Even you can check the updated on researchgate.com The left animation shows the ACMI behavior with the manipulated libraries and the right one the original one.
__________________
Keep foaming, Tobias Holzmann Last edited by Tobi; July 19, 2016 at 12:02. |
|
February 23, 2018, 05:39 |
|
#13 |
New Member
Marcus N Hofer
Join Date: Jan 2015
Location: Austria, close to Vienna
Posts: 8
Rep Power: 11 |
Hello all,
are these problems with ACMI/AMI patches together with moving meshes and compressible solvers solved with OpenFoam 5.x, has anyone tried? Kind regards, Marcus |
|
June 18, 2018, 10:47 |
|
#15 |
New Member
Join Date: Jan 2018
Posts: 12
Rep Power: 8 |
Yes, I'd like to know whether this issue https://bugs.openfoam.org/view.php?id=1664#bugnotes is resolved as well.
I have test case with pitching wings and a rotating disc perpendicular to the sides of the wings (on one end, on the other end of the wings, there is a symmetry b.c.). In the forces at the disc, I observe pressure jumps when the ACMI interface is split over multiple cores. I have defined a non-zero velocity on the nonOverlapPatch (as the disc is rotating), which should not be possible according to this thread.... When I run the simulation with the ACMI on a single core, no pressure jumps occur. So, is the above issues resolved? Because it doesn't seem to be. |
|
June 18, 2018, 12:50 |
|
#16 |
Senior Member
anonymous
Join Date: Jan 2016
Posts: 416
Rep Power: 14 |
Hi!
I was able to modify the oscillatingInletACMI case with this type of motion using displacementLayeredMotion with linear interpolation scheme. (With oneSided you should have layering which is also possible but for me OF was only able to do layering on the stationary wall which is not the best. If you use displacementLayeredMotion you won't have that weird mesh motion since it will solve the displacement only in the given region. (You can find an example case for layering+ACMI in v1712: $FOAM_TUTORIALS/multiphase/compressibleInterDyMFoam/laminar/sphereDrop/) If i understand your problem that's what you want (ofc this is a toy case): https://youtu.be/mcWCuTLolFg Last edited by simrego; June 18, 2018 at 14:21. Reason: video added |
|
June 18, 2018, 16:36 |
|
#17 |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 51 |
Nice video, once I wanted to do a two stroke engine but it was not working because the ACMI was connected to the motion point/cell field. Interesting to know that it is working now. Did you modify the code? I am asking, because I was going deep into the code without any solution (there is also a bug report which is not resolved yet).
__________________
Keep foaming, Tobias Holzmann |
|
June 18, 2018, 17:10 |
|
#18 |
Senior Member
anonymous
Join Date: Jan 2016
Posts: 416
Rep Power: 14 |
Thanks, but this video is far from nice, but enough to show you it's working.
No. This is the basic code without any modification. Since they included that motion solver (don't know when) I think it's working. Yes, I saw that bug report. They wrote there the problem is in the motion solver, and if I understood well, most of the solvers (ie.: displacementLaplacian) solve for the whole domain which makes the problem. But in the displacementLayeredMotion solver you solve only in the cellZone (I hope i'm correct), so it shouldn't affect the other regions. So I think it works with any motion solver which can be limited into a region where you move the mesh (don't know if there are others). |
|
June 19, 2018, 05:44 |
|
#19 |
New Member
Join Date: Jan 2018
Posts: 12
Rep Power: 8 |
@simrego: thank you for your reply.
However, in my case both the disc and the pitching wings are moved using a rigid body motion (multiSolidBodyMotionSolver) instead of mesh deformation. Do you know if the issue is resolved there? (I checked the git commit history and made sure that the issue I mentioned is resolved in the OpenFOAM version I'm using (OpenFOAM-5.0).) |
|
June 19, 2018, 05:56 |
|
#20 |
Senior Member
anonymous
Join Date: Jan 2016
Posts: 416
Rep Power: 14 |
How did you made the mesh? I have played a bit with it. I'm using snappy and if i create internal faceZone or baffle/createBaffles, it fails. But if i split the mesh with boundary patches and then createBaffles, it works. Maybe internal wall is the only possible solution to absolutely detach the 2 surfaces. It's just a guess yet.
Check the oscillatingInletACMI tutorial. There you have solid body motion and it works perfectly. So you must miss something. |
|
Tags |
acmi, moving mesh., rhopimpledymfoam |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Wind turbine simulation | Saturn | CFX | 60 | July 17, 2024 05:45 |
sliding mesh problem in CFX | Saima | CFX | 46 | September 11, 2021 07:38 |
Question about heat transfer coefficient setting for CFX | Anna Tian | CFX | 1 | June 16, 2013 06:28 |
Error finding variable "THERMX" | sunilpatil | CFX | 8 | April 26, 2013 07:00 |
RPM in Wind Turbine | Pankaj | CFX | 9 | November 23, 2009 04:05 |