[jimteb]

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

[wyldckat]

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":

    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:

Originally Posted by jimteb

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:

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.

[jimteb]

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

[wyldckat]

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

[danny123]

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

[jimteb]

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:

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.

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,

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

[danny123]

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

[wyldckat]

Greetings to all!

@James:

Originally Posted by jimteb

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

[alfa_8C]

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

[wyldckat]

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

[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: 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).

[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.

[MarcusNHofer]

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

[Tobi]

No. See the bug tracking system.

[Anouk]

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.

[simrego]

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

[Tobi]

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).

[simrego]

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).

[Anouk]

@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).)

[simrego]

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.