[Lesson]

Hello
I'm working with OpenFOAM to study the behaviour of automatic valves in reciprocating compressors.
The first problem encountered is the interface beetween two non conformal and non-overlap mesh ( lateral cylinder surface and pocket valve ), the first is dynamic mesh, the second is fixed. Each non-overlap zone is wall.
I'm using,as a starting point, oscillating2DACMI modified with rhoPimpleDyMfoam.
I have the problem with overlap zone.
You can see that with the 3 pictures attached.

thanks a lot

Fely

[Lesson]

I solved it using GGI interface with foam-extend version.
Now the problem is: how to define walls for non-overlap face?
And how to simulate in parallel if I have more than 1 couple of GGI interfaces.

[gaza]

Originally Posted by Lesson

I solved it using GGI interface with foam-extend version.
Now the problem is: how to define walls for non-overlap face?
And how to simulate in parallel if I have more than 1 couple of GGI interfaces.

Hi Lesson
You wrote that you solved your problem with use rhoPimpleDyMFoam and GGI?
Can you tell me how did you do that?
best regards

[Mojtaba.a]

I think it can be done using AMI in OpenFOAM 2.3.
Its all about defining cellZones and cyclic boundaries.
You obviously must have two regions, each region must be defined as a cellZone so we can use it later in dynamicMeshDict.

After that in dynamicMeshDict you can use,

dynamicFvMesh   solidBodyMotionFvMesh;

motionSolverLibs ( "libfvMotionSolvers.so" );

solidBodyMotionFvMeshCoeffs
{
    cellZone        cellZoneName; //Change to your cellZone name.

    solidBodyMotionFunction  oscillatingLinearMotion; //Use any motion you desire
    oscillatingLinearMotionCoeffs
    {
        omega           1;
    amplitude    (0 1 0);
    }
}

I hope it helps a bit,
Best.

[gaza]

Hi Mojtaba.a,
Yes I set up my case in the OF2.3 with AMI.
However my case runs only if I use lowWeightCorrection 0.2
After 0.2 s solver crashes. I wanted to make rhoPimpleDyMFoam in OpenFOAM extended 3.0 but I cannot. I do not know how to solve my problem.
best regards
Przemek

[Mojtaba.a]

Originally Posted by gaza

Hi Mojtaba.a,
Yes I set up my case in the OF2.3 with AMI.
However my case runs only if I use lowWeightCorrection 0.2
After 0.2 s solver crashes. I wanted to make rhoPimpleDyMFoam in OpenFOAM extended 3.0 but I cannot. I do not know how to solve my problem.
best regards
Przemek

Well does mesh deforms while running? because it shouldn't since you use ACMI.
First try testing your mesh movement with "moveDynamicMesh" to make sure everything is fine and then start simulation using rhoPimpleDyMFoam.
Tell me what happens when you run moveDynamicMesh.

[ovie]

Originally Posted by Mojtaba.a

Well does mesh deforms while running? because it shouldn't since you use ACMI.
First try testing your mesh movement with "moveDynamicMesh" to make sure everything is fine and then start simulation using rhoPimpleDyMFoam.
Tell me what happens when you run moveDynamicMesh.

Hi Mojtaba:

From your earlier post, it appears you are suggesting that its not possible to use ACMI with deformable meshes i.e. when the dynamic mesh is not a solid body motion. Do you by chance have any idea how sliding interface with deformable mesh motion can be implemented either in OF or the extended version?

Thanks.

[Mojtaba.a]

Originally Posted by ovie

Hi Mojtaba:

From your earlier post, it appears you are suggesting that its not possible to use ACMI with deformable meshes i.e. when the dynamic mesh is not a solid body motion. Do you by chance have any idea how sliding interface with deformable mesh motion can be implemented either in OF or the extended version?

Thanks.

Dear Ovie,
I am afraid I cannot help you on this, but just for curiosity does your case really needs both methods at once to be solved?
For typical problems just one of them would suffice.

Best.

[ovie]

Thanks for your response.

Originally Posted by Mojtaba.a

Dear Ovie,
but just for curiosity does your case really needs both methods at once to be solved?

Frankly I dont know at the moment, but let me break it down to see if you can provide any insight.

The problem I am trying to simulate involves two concentric cylinders : a smaller diameter cylinder (SDC) initially positioned at the top of a second larger diameter cylinder (LDC).

The top surface of SDC is a piston that moves up and down to compress or expand the air inside SDC.

SDC is initially empty while LDC contains liquid up to some some level.

At time > 0; SCD slides into LDC and as it slides down, the piston surface simultaneously moves upwards to create suction pressure inside SDC so as to aspirate liquid from LDC into SDC.

After aspirating a certain volume of liquid, SDC starts moving upwards while piston surface at the same time moves downwards to create pressure for expelling aspirated liquid from SDC into LDC.

This cycle is repeated multiple times.

So there is the problem I am trying to simulate. Do you have any pointers on how to use the current capabilities of OF/extend to model this?

Thanks again for your time.

[Mojtaba.a]

Well it is a little bit hard to imagine, two further questions,

1. Does your problem includes two phase?
2. Is bottom surface of SDC always open?

Maybe you can provide a simple sketch for better insight?

Best.

[Lesson]

Hi everyone
Sorry for my late reply
i tried to solve my problems with OF 2.3 ( ACMI )
This kind of solution is not good for body that have sliding interface and deformation mesh ( maybe It's better to say that I'm not able to do it with ACMI ).
So I started playing with OpenFOAM extend -version . The great advantage of this release is the GGI interfaces. You can manage two separate bodies with all kinds of mesh motion. The disadvantage is that you can't put no slip condition for wall in non-overlap interfaces.
The second disadvantage is that in OpenFOAM-exetend version there isn't rhoPimpleDyMFoam implemented, you have to build it.
There is a tutorial: mixerggi, that explain you how to setup the case with GGI interface.

Bye
Fely

[simin_ds]

Hi lesson
I hope a good night for you!

I am simulating a valve motion like you but in a pipe. I used ACMI and I have a problem like yours. Also I used GGI in extend version of 1.6 that by moving the valve down the until after some time the negative cell volume occur and the non-overlap patches can not be considered as wall. Have you solved your problem?
If yes can you adise me in this regards?

[Tobi]

Originally Posted by Mojtaba.a

I think it can be done using AMI in OpenFOAM 2.3.
Its all about defining cellZones and cyclic boundaries.
You obviously must have two regions, each region must be defined as a cellZone so we can use it later in dynamicMeshDict.

Dear Mojtaba,

I have just a question to you. You told that it is all about cellZones and correct cyclic boundaries. I think I made everything well (checked ACMI interface and surface normals). Everything seems fine but moveDynamicMesh result in distortion of the interface (it is not sliding - it is connected).

In the attachment you find a picture. I have also two cellZones (rotating and static zone). Anyway it is not working :/ Any suggestions.

Thanks in advance,
Tobi

[Mojtaba.a]

Originally Posted by Tobi

Dear Mojtaba,

I have just a question to you. You told that it is all about cellZones and correct cyclic boundaries. I think I made everything well (checked ACMI interface and surface normals). Everything seems fine but moveDynamicMesh result in distortion of the interface (it is not sliding - it is connected).

In the attachment you find a picture. I have also two cellZones (rotating and static zone). Anyway it is not working :/ Any suggestions.

Thanks in advance,
Tobi

Dear Tobias,

Maybe I was not clear before. Actually you have to have separate regions to make them slide relative to each other. To do this you have to try to disconnect rotor and static zones in your meshing tool.

The best alternative would be using splitMeshRegions utility. This utility can separate your domain by your cellZones.

splitMeshRegions -cellZones -overwrite

To check if everything is alright, try to do checkMesh and you have to see this line:

   *Number of regions: 2
    The mesh has multiple regions which are not connected by any face.

It should be fine now.
Hope it helps.

[Tobi]

Thank you for the replay.
I will check it out today evening but I checked it with checkMesh yesterday and I already got 2 regions. Anyway I will try. Interesting that you mention splitRegions. If I am doing AMI I never used it before and everything was fine (thats the reason why I am confused a bit). Maybe snappyHexMesh is doing the stuff for me; thanks in advance.

[Tobi]

Hi,

as I expected, ... if I use splitMeshRegions -cellZones I will get two different meshes but normally I only need this using chtMulti***Foam. So after that you have to combine the meshes again? Is there some other work-around?

Will check the tutorial case tomorrow again.

[Mojtaba.a]

Originally Posted by Tobi

Hi,

as I expected, ... if I use splitMeshRegions -cellZones I will get two different meshes but normally I only need this using chtMulti***Foam. So after that you have to combine the meshes again? Is there some other work-around?

Will check the tutorial case tomorrow again.

So splitMeshRegions couldn't solve the distortion problem?
I haven't used the cht solvers for a long time, not very much sure how to set it up. I should check it in tuts. But I couldn't actually get from your posts if the moving mesh problem is now solved or not. I can take a look at the case if you can attach it.

All the best.

[Tobi]

Hi,

no if I really split the mesh I end up with two polyMesh's. Finally I only need one with cellZone of the moving area (for dynamicLib) and the duplicated interface points. In my case, the interface points are still connected. In the evening I will upload the case and you can check out what I did. Maybe you will find the problem.

[Tobi]

The case can be downloaded here: http://holzmann-cfd.de/cfd-online/cases/ACMI.tar.gz

This download will be only temporary and will move to the official tutorial section.
It will stay there till the case will run (:

[Mojtaba.a]

Originally Posted by Tobi

The case can be downloaded here: http://holzmann-cfd.de/cfd-online/cases/ACMI.tar.gz

This download will be only temporary and will move to the official tutorial section.
It will stay there till the case will run (:

Hi Tobias,

I took a look at your case. First of all nice run file. I liked it .
Actually your cellZones are connected to each other and I don't know why checkMesh shows two separate regions. Not sure on that. When I loaded only the moving cellZone, I saw no cells but faces:



Further I looked at your case, I remembered how I got this to work on my own case some times ago. I did it by producing two separate meshes in two separate cases (using SHM) and then merging them together by mergeMesh utility. It is very much more straight forward than doing it all in a single case. So what you should now do is:

1- Make two separate cases each containing the stl files and snappyHexMesh files to mesh only one of the regions (Moving and Stationary).

2- Remember that you have to choose different patch names for the interfaces, walls, front and back patches. For example, interface1 for the Moving region mesh and interface2 for the Stationary region Mesh, or wall1 and wall2 ... (As told before these mesh are stored in separate cases for now). Boundaries with the same name will be merged into a single boundary after the merging process that is not desired in our case for the mentioned boundaries.

3- Mesh both cases using SHM or any other tool you prefer to use. Do extrudeMesh, flattenMesh and ... for both cases.

4- Merge meshes using mergeMesh utility. To do this I would do sth like this:

cd stationary
mergeMeshes -overwrite "." "../moving/"

Now you have both meshes merged together and stored in the stationary case.

5- Now you have to make some faceZones referring to interface patches. We want to put interface1 and interface2 patches into movingFaces and fixedFaces faceZones. I do this by topoSet:

actions
(
    {
        name    fixedFaceSet;
        type    faceSet;
        action  new;
        source  patchToFace;
        sourceInfo
        {
            name    interface2;
        }
    }
    {
        name    fixedFaces;
        type    faceZoneSet;
        action  new;
        source  setToFaceZone;
        sourceInfo
        {
            faceSet fixedFaceSet;
        }
    }

    {
        name    movingFaceSet;
        type    faceSet;
        action  new;
        source  patchToFace;
        sourceInfo
        {
            name    interface1;
        }
    }

    {
        name    movingFaces;
        type    faceZoneSet;
        action  new;
        source  setToFaceZone;
        sourceInfo
        {
            faceSet movingFaceSet;
        }
    }
);

And run topoSet:

topoSet -constant

6- Next we have createBaffles. We are making the ACMI boundaries now.

internalFacesOnly false;

baffles
{
    fixedACMI
    {
        type        faceZone;
        zoneName    fixedFaces;

        patches
        {
            master
            {
                name            fixedACMI_couple;
                type            cyclicACMI;
                matchTolerance  0.0001;
                neighbourPatch  movingACMI_couple;
                nonOverlapPatch fixedACMI_blockage;
                transform       noOrdering;
            }
            slave
            {
                name            fixedACMI_couple;
                type            patch;
            }

            master2
            {
                name            fixedACMI_blockage;
                type            patch;
            }
            slave2
            {
                name            fixedACMI_blockage;
                type            patch;
            }

        }
    }

    movingACMI
    {
        type        faceZone;
        zoneName    movingFaces;

        patches
        {
            master
            {
                name            movingACMI_couple;
                type            cyclicACMI;
                matchTolerance  0.0001;
                neighbourPatch  fixedACMI_couple;
                nonOverlapPatch movingACMI_blockage;
                transform       noOrdering;
            }
            slave
            {
                name            movingACMI_couple;
                type            patch;
            }

            master2
            {
                name            movingACMI_blockage;
                type            patch;
            }
            slave2
            {
                name            movingACMI_blockage;
                type            patch;
            }
        }
    }
}

Be careful that patch names are different from your case. So change them relative to your own case.

7- Last step would be an empty createPatch to clean everything up.

pointSync false;

patches
(
    // none
);

That would be all.
Give me some feedback if you could make it work.

Hope it helps.
Best.