[Tobi]

Many thanks to you.

thanks for the feedback and good to know that you like the run-file. It is always the same in all my tutorials (if you don't know, check out my website).

So finally what you suggested (splitMeshRegions) should work, too (using mergeMesh at the end). I will make a work-around on that too. As far as I remember (what I did 2-days ago), the cellZone was visible in my case. But I will also check it again (do you use paraFoam or paraview + *.foam file?).

Thanks for the really clear instructions (:
I got each point and I also tried different methods (really similar to your suggestion but I always had one mesh).

I give it a try and due to your excellent explanation I think it will finally work.

[Mojtaba.a]

Originally Posted by Tobi

Many thanks to you.

thanks for the feedback and good to know that you like the run-file. It is always the same in all my tutorials (if you don't know, check out my website).

So finally what you suggested (splitMeshRegions) should work, too (using mergeMesh at the end). I will make a work-around on that too. As far as I remember (what I did 2-days ago), the cellZone was visible in my case. But I will also check it again (do you use paraFoam or paraview + *.foam file?).

Thanks for the really clear instructions (:
I got each point and I also tried different methods (really similar to your suggestion but I always had one mesh).

I give it a try and due to your excellent explanation I think it will finally work.

I am happy it was useful.
I used paraFoam in this case. Maybe paraview + *.foam would show the cellZone correctly.
If there were any problems, you may just inform me.

All the best.

[Tobi]

Hi,

tilll now I had no time to check it out ... (unfortunatelly). So I think I will investigate into that on sunday evening. One thing that I checked, paraFoam also shows the cellZone in the oscillatingInletACMI2D wrong (only faces).

Just wanted to mention that.

[Tobi]

Hi all,

just made a simple test now. Replacing the keyword (in snappyHexMeshDict):

type baffles;

to

type boundary;

The sliding is working now. I had no time to check it in detail but I will investigate into that the next week.

[Tobi]

Hi all,

here the first news. Using the boundary type, I am able to move my cellZone without the connected points. Now I will check the ACMI interface. I keep you updated.

[Tobi]

Hi all,

I figured it out. Here is the first imagination of the tutorial! The simulation will run for the next hours and then I will publish it if everything is fine.

working.0009.png

[Tobi]

Dear all,

I will remove the case from my homepage (so the link before will not be anymore available). After cleaning up everything and checking if everything works fine, I will upload it again and publish it in the tutorial section. Here is the first result:

https://www.facebook.com/14282653587...4014057425297/

[Tobi]

Dear all,

today I finished the ACMI tutorial and uploaded it. You can find it on www.holzmann-cfd.de.

For impressions, here the video: https://www.youtube.com/watch?v=KCIBzVWyqzg

Thanks for all the feedback. Project finished (:

[atoof]

Dear Tobias,

Thanks for your useful case. I have a question. Is it possible to define cyclic for nonOverlapPatch in master and slave side patches such as following:

           master
            {
                //- Master side patch
                name            ACMI1_blockage;
                type            cyclic;//wall;
            }
            slave // not used since we're manipulating a boundary patch
            {
                //- Slave side patch
                name            ACMI1_blockage;
                type            cyclic;//wall;
            }

This boundary condition is suitable for periodic rotor stator case.

Regards,

Hossein

[arjun]

Is your calculation compressible flow.

If its incompressible I wonder what happened to disconnected region's pressure when it is in disconnected state.

Should not that region has all neuman pressure bc. Interesting that it did not cause any problems.

Originally Posted by Tobi

Hi all,

here the first news. Using the boundary type, I am able to move my cellZone without the connected points. Now I will check the ACMI interface. I keep you updated.

[Tobi]

Dear Hossein,

it is possible to use cyclic but I do not know if it will work. Normally the cyclic patches are static (only if you have cyclicAMI or cyclicACMI, it supports motion of the faces). The problem that might occur is based on face addressing. At the moment I only know how the ACMI is working (more or less) and I do not think, that the cyclic BC supports motion. GGI from the extend project could be the choice, if it is not working with the Foundation version. I also made a few - feature reports to the bug-tracking system, maybe in the next FOAM version we will see some new stuff.

@arjun: The pressure BC for the disconnected interfaces are Neumann (zeroGradient) conditions. Just check the 0/p file.

[arjun]

Originally Posted by Tobi

Dear Hossein,
@arjun: The pressure BC for the disconnected interfaces are Neumann (zeroGradient) conditions. Just check the 0/p file.

This is why I asked.

The problem is that if you used amg and coarsened to 1 equation you will have diagonal = 0.

In your simulation velocities look smooth so pressure is not affecting, but there are two questions
1. Why the simulation is not affected by pressure fluctuation when the disconnected region connects again.
2. Why the linear solver is stable. (This probably has to do with convergence falling down globally or for the full system).

In ccm any disconnected region is automatically given a pressure fixer. So may be this is what happens here in openfoam too.

[Tobi]

Hi,

well, I am not so familiar with the matrix solvers (only the basic ones). Till now I had not time to check out the AMG behavior or read something about that (I know how it works but not in detail). So this is just a natural feeling that I have but why we get a diag = 0 ? AFAIK, with AMG we first solve a coarse problem map this to the next level and so on... for the matrix it would be something like: Solve a coarse matrix, then map to a bigger matrix and solve that one. Well, as I told you, I am not familiar with the AMG solver.

And finally I do not know what ccm is - seems to be a software toolbox, isn't it?

The ACMI is working like we would use a groovy BC and change the faces of e.g. the outlet to a different behavior for the velocity and pressure in the same time. Here we also do not get any problems. An example would be, pressure face become zeroGradient (from fixedValue) and the velocity become fixedValue (from zeroGradient).

[arjun]

Originally Posted by Tobi

Hi,

well, I am not so familiar with the matrix solvers (only the basic ones). Till now I had not time to check out the AMG behavior or read something about that (I know how it works but not in detail). So this is just a natural feeling that I have but why we get a diag = 0 ? AFAIK, with AMG we first solve a coarse problem map this to the next level and so on... for the matrix it would be something like: Solve a coarse matrix, then map to a bigger matrix and solve that one. Well, as I told you, I am not familiar with the AMG solver.

And finally I do not know what ccm is - seems to be a software toolbox, isn't it?

The ACMI is working like we would use a groovy BC and change the faces of e.g. the outlet to a different behavior for the velocity and pressure in the same time. Here we also do not get any problems. An example would be, pressure face become zeroGradient (from fixedValue) and the velocity become fixedValue (from zeroGradient).

For a pure neuman problem if coarsening in AMG is done properly and it is coarsened to 1 equation, then that equation will look like this

ax = b

Now if a is non 0, then x = b/a exists. But pure neumann problem is singular and you can not find solution to it ie x should not exist. To avoid it pressure is fixed.

So if the coarsening was done till the coarsest level possible, in the problem you are solving you would get 2 equations at coarsest level (because of disconnection) and one of the equations would have a = 0, that is it would result in floating point exception.

In fact due to precision issues this a = 0 occurs many times and linear solver crashes out.
This has been known for Fluent and for CCM too

CCM is short for StarCCM+ .

PS: In my code it provides fix for this situation but assumes that linear system was never singular (assumes that ap = 0 is just due to precision issue).

[Tobi]

Okay I get your point now. That means, the rotating zone should make problems after disconnecting based on the fact that the problem is not well defined (in that case). Maybe the solver would crash, if the disconnection time would be long enough to get some singularity within the matrix. Did not checked that out but an interesting point. Never thought about that but now it is obvious.

I think the BC that I chose helping for stabilization because the fluxes into the domain are adjusted by the pressure. If the pressure is uniform, the fluxes are going to zero. If the solution is smooth, it might happen that the solver crashes or (i think that will happen) end up with the result that we can not find an accurate solution (iteration = 1000). The same happen if we solve for laplace equation and we have a uniform field.

In my opinion, the ACMI is (till now) designed for rotating and sliding interfaces, that are not loosing the connections for a long time (or even never loose connection). If I would make a fixed value for the velocity, I am sure, that the result is not as smooth as we could observe in the original case.

[arjun]

Interestingly though the velocity looks good in your simulation. Thats why I asked you.

I have been thinking how this type of simulation be handled with making sure that simulation is stable and produce meaningful results.

[khedar]

Hi Arjun and Tobi,
I am doing a simulation with ACMI but there is not movement in the mesh. Reason for using ACMI is because of complication in the geometry.
Following is half of the geometry and the other half is symmetric to this.
Now the problem I keep facing is GAMG solver crashing after 1 iteration and I am unable to solve it no matter what changes i make to my boundary conditions and solution parameters.

Do you have some suggestion.

http://i66.tinypic.com/whcrdg.png

EDIT::
After changing the non-overlap patch BC for p_rgh from zero-gradient(it should be) to fixed pressure value, the simulation runs for one-more iteration but the continuity errors grow to very large values.

[Tobi]

It seems that you want to do something like the moving-Inlet tutorial? If yes, do it like in the tutorial and everything is fine. However, before starting your simulation, you should use moveDynamicMesh to ensure that everything is set up fine (especially the mesh and the decoupling of the regions).

Good luck.

[khedar]

No, in my case nothing is moving. The smaller part is the inlet and flow goes into the longer part which is at 90 degree to the inlet section. I am trying to make some changes in the meshing parameters to see if it improves the solution.

[Tobi]

So why ACMI? It just will slow down your simulation!

Sent from my HTC One mini using CFD Online Forum mobile app