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

apparent anomalies at ACMI interface

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

Reply
 
LinkBack Thread Tools Display Modes
Old   February 3, 2015, 13:57
Default apparent anomalies at ACMI interface
  #1
New Member
 
James
Join Date: Feb 2014
Location: London
Posts: 19
Rep Power: 4
jimteb is on a distinguished road
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
Attached Images
File Type: jpg modelOverview.jpg (15.3 KB, 78 views)
File Type: gif UX.gif (85.0 KB, 82 views)
File Type: gif T.gif (72.1 KB, 78 views)
File Type: gif p.gif (84.8 KB, 70 views)
Attached Files
File Type: txt fvSchemes.txt (2.3 KB, 13 views)
jimteb is offline   Reply With Quote

Old   April 24, 2015, 16:32
Default
  #2
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 9,747
Blog Entries: 39
Rep Power: 103
wyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of light
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: cyclicACMI boundary condition treatment

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);
    }
the blockage entries must strictly be set to fixed value and they will not work as intended with anything else .


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:
Originally Posted by jimteb View Post
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.
Why exactly shouldn't there be any mass flux across the cyclic part of the ACMI boundary?

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:
The problem with ACMI, in my case, seems to be limited to compressible flow solvers (i.e. rhoPimpleDyMFoam and sonicDyMFoam). I tried the same problem with pimpleDyMFoam and there are no pressure discontinuities.

It looks to me like it might be a conservation issue, which is introduced when a compressible solver is used, with the pressure anomalies behaving like a source.

Last edited by wyldckat; April 24, 2015 at 16:34. Reason: see "edit:"
wyldckat is offline   Reply With Quote

Old   April 25, 2015, 09:05
Default
  #3
New Member
 
James
Join Date: Feb 2014
Location: London
Posts: 19
Rep Power: 4
jimteb is on a distinguished road
Hi Bruno,

In response to your suggestions:
  • I previously tried changing the 'movingWallVelocity' BC on the ACMI blockage parts to 'fixedValue' for U. This made no apparent difference to the pressure discontinuities at the corner cells.
  • I also tried running with a lower translation speed (6 m/s vs. 60 m/s), with fixedValue for the U blockage patches . Again, this made no apparent difference to the pressure discontinuities.

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
jimteb is offline   Reply With Quote

Old   April 25, 2015, 15:26
Default
  #4
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 9,747
Blog Entries: 39
Rep Power: 103
wyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of light
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
wyldckat is offline   Reply With Quote

Old   April 29, 2015, 11:17
Default
  #5
Senior Member
 
Daniel Witte
Join Date: Nov 2011
Posts: 141
Rep Power: 7
danny123 is on a distinguished road
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
danny123 is offline   Reply With Quote

Old   April 29, 2015, 11:43
Default
  #6
New Member
 
James
Join Date: Feb 2014
Location: London
Posts: 19
Rep Power: 4
jimteb is on a distinguished road
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:
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.
I have thought about using this option, however the mesh deformation would be too great for the application I am interested in. It could be useful for isolating the problem I agree.

Quote:
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?
I've managed a work around (for the time being) using ACMI, by restructuring the mesh so the the problematic ACMI corner cells are as far away as possible from the region of interest. With this modification the results are closer to what I would expect, eliminating the pressure (and other fields) anomaly's from the region of interest. Therefore, I'm inclined to believe that those strange results were not physical. Ill try and test this further.

Cheers.

Hi Daniel,

Quote:
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.
I believe I did try running the model with the momentum predictor turned off a while back. If I recall properly, it didn't make much, if any difference to the pressure anomaly's.

Cheers,

James
jimteb is offline   Reply With Quote

Old   April 30, 2015, 03:45
Default
  #7
Senior Member
 
Daniel Witte
Join Date: Nov 2011
Posts: 141
Rep Power: 7
danny123 is on a distinguished road
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
danny123 is offline   Reply With Quote

Old   April 30, 2015, 11:21
Default
  #8
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 9,747
Blog Entries: 39
Rep Power: 103
wyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of light
Greetings to all!

@James:
Quote:
Originally Posted by jimteb View Post
I've managed a work around (for the time being) using ACMI, by restructuring the mesh so the the problematic ACMI corner cells are as far away as possible from the region of interest.
I read about that in one of your comments on a bug report... and I forgot to ask this before, so I'll ask now: can you provide an image to what you're referring to?

Because from what I can figure out, either:
  1. You've made the non-conformal mesh both sides to always have the mesh corners coincident...
  2. Or your moving part never goes outside of the working zone, i.e. the overlap is always the same over the main domain?
Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   March 16, 2016, 10:40
Default
  #9
Member
 
Antonio Liggieri
Join Date: Aug 2010
Posts: 71
Rep Power: 7
alfa_8C is an unknown quantity at this point
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
Attached Images
File Type: jpg pic1.jpg (138.3 KB, 29 views)
File Type: jpg Pic3.jpg (153.7 KB, 28 views)
File Type: jpg Pic5.jpg (153.4 KB, 23 views)
alfa_8C is offline   Reply With Quote

Old   March 28, 2016, 12:57
Default
  #10
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 9,747
Blog Entries: 39
Rep Power: 103
wyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of light
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
__________________
wyldckat is offline   Reply With Quote

Old   July 6, 2016, 09:01
Default
  #11
Senior Member
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Leoben (Austria)
Posts: 1,552
Blog Entries: 6
Rep Power: 27
Tobi will become famous soon enoughTobi will become famous soon enough
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
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: Object of type GeometricBoundaryField

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).
__________________
Best regards,
Tobias Holzmann

Some interesting OpenFOAM tutorials, publications and videos on www.Holzmann-cfd.de
OpenFOAM Beginners should check out the new wiki on wiki.openfoam.com
A list of some active OpenFOAM contributers can be found »here«
A book about the basics of »Mathematics, Numerics, Derivations and OpenFOAM« can be found on www.Holzmann-cfd.de
Tobi is offline   Reply With Quote

Old   July 19, 2016, 07:44
Default
  #12
Senior Member
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Leoben (Austria)
Posts: 1,552
Blog Entries: 6
Rep Power: 27
Tobi will become famous soon enoughTobi will become famous soon enough
Send a message via ICQ to Tobi Send a message via Skype™ to Tobi
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.

__________________
Best regards,
Tobias Holzmann

Some interesting OpenFOAM tutorials, publications and videos on www.Holzmann-cfd.de
OpenFOAM Beginners should check out the new wiki on wiki.openfoam.com
A list of some active OpenFOAM contributers can be found »here«
A book about the basics of »Mathematics, Numerics, Derivations and OpenFOAM« can be found on www.Holzmann-cfd.de

Last edited by Tobi; July 19, 2016 at 12:02.
Tobi is offline   Reply With Quote

Reply

Tags
acmi, moving mesh., rhopimpledymfoam

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


Similar Threads
Thread Thread Starter Forum Replies Last Post
Wind turbine simulation Saturn CFX 45 February 8, 2016 05:42
sliding mesh problem in CFX Saima CFX 45 September 22, 2015 10:53
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 05:05


All times are GMT -4. The time now is 16:56.