[reza1980]

Bruno,
my guess to approach bad result is due to being these non-overlapped cells.Whats your idea to improve this problem.

[wyldckat]

Hi Reza,

The cells that have been identified as "twoInternalFacesCells" as shown in attachment. They already exist on the rotor side of the mesh.
What happens here, if I'm not mistaken, is that these cells have not only one face of the boundary, they have got at least 2 faces on the boundary. What I've seen so far is that OpenFOAM is able to calculate with these cells, but their existence is nonetheless a reason of concern...

Unfortunately, this case is too big for me to experiment things easily. I didn't manage to get enough time to try and create the faceZone and the cellZone that createBaffle needs for making sure that the AMI patches are properly connected.

If you can provide a simple case, I'll try to have another look into this next weekend.

Best regards,
Bruno

[reza1980]

Bruno,
Thanks again. what is your strategy to make cellZones and faceZones.
It is not strange that these cells are concerned rotor because the files you have are not-merged and needs to create AMI interaction faces.

[wyldckat]

Hi Reza,

I've finally managed to get to this post of yours.
OK, while I was busy these past few weeks, I found out about a really neat feature that OpenFOAM has got with AMI: technically you only need to merge the meshes! No stitching required!

I tried it by chance, because I was also having a hard time stitching the meshes together. But based on this hint from OpenFOAM 2.1: https://github.com/OpenFOAM/OpenFOAM...DictionaryDict - I deduced that the "cyclicAMI" could be able to handle the data transfer between regions, without the existing stitching. Specially because it doesn't make much sense that AMI patches should need to be stitched together.

The steps I took to do the merge were:

1. Created two case folders based on the cavity tutorial, without the "0" folder.
2. Placed the meshes you had sent me some weeks ago into the respective case sub-folders "constant/polyMesh".
3. Then merged one case into the other:
   

   cd rotor
   mergeMeshes -overwrite . ../stator

4. Created the file "system/changeDictionaryDict" with the following content:
   

   FoamFile
   {
       version     2.0;
       format      ascii;
       class       dictionary;
       object      changeDictionaryDict;
   }
   // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
   
   dictionaryReplacement
   {
       boundary
       {
           AMI1
           {
               type            cyclicAMI;
               neighbourPatch  AMI2;
               transform       noOrdering;
           }
           AMI2
           {
               type            cyclicAMI;
               neighbourPatch  AMI1;
               transform       noOrdering;
           }
       }
   }

5. Ran:
   

   changeDictionary

6. And did a full mesh check:
   

   checkMesh -constant -allGeometry -allTopology

And AFAIK, that's all you need to get the mesh ready for the case.


Oh, right, about the face zones and cell zones. It's simple. If you run the following command:

cp FOAM_UTILITIES/mesh/manipulation/topoSet/topoSetDict system/topoSetDict

you'll get a copy of a well documented "topoSetDict" dictionary file. Now it depends on what you need to do. Keep in mind to perform this operation before merging the meshes!

• If you want a "faceSetZone": you can create a "faceSet" based on patches and then create the "faceSetZone" based on the "faceSet".
• If you want a "cellSetZone": you can create a "cellSet" based on a box that selects all cells. The create a "cellSetZone" based on both the "cellSet".

Once each "system/topoSetDict" is properly configured, you can run:

topoSet

Then use mergeMeshes.


You can examine the resulting zones in ParaView, by selecting the respective option.


Best regards,
Bruno

[linnemann]

If you just want the cellZones of each mesh this will be easier than topoSet

splitMeshRegions -makeCellZones -overwrite

This will create cellZones of the different regions in the mesh.

The first mesh before mergeMeshes will be called region0 the mesh that was merged will be region1. If you merge more meshes that will be the same order.

[reza1980]

Thanks Bruno,
But I think using the folowing command is enough and doesnt need to create faceset and... isn't it?

splitMeshRegions -makeCellZones -overwrite

[reza1980]

Dear Niels and Bruno,

Thanks for help. would you please let me know it is a mandatory to create faceSetZone ? I just used the following command for merged mesh and made cellZones .

splitMeshRegions -makeCellZones -overwrite
further, I don't know how to be sure that the implementation is OK?
Reza

Originally Posted by linnemann

If you just want the cellZones of each mesh this will be easier than topoSet

splitMeshRegions -makeCellZones -overwrite

This will create cellZones of the different regions in the mesh.

The first mesh before mergeMeshes will be called region0 the mesh that was merged will be region1. If you merge more meshes that will be the same order.

[wyldckat]

Hi Reza,

If my memory doesn't fail me, you only need faceZoneSets if you are going to need to create an explicit interface, such as a patch or baffle. But if you already have a patch assigned to the interface, then I don't think you'll need the faceZoneSets.

edit: to check if things are in place, if you are using dynamic mesh, then you can use moveDynamicMesh to solve only the mesh motion and to check if the right cells go along for the ride As for seeing the cells that are part of a zone or set, see this post: http://www.cfd-online.com/Forums/ope...tml#post446982 post #2

Best regards,
Bruno

[nash]

hi could someone please help me with the problem creating AMI here :

http://www.cfd-online.com/Forums/ope...tml#post447758 post #49

[kingmaker]

Hello I am trying to run a similar case to propeller (with AMI) but with much complicated propeller geometry.

I followed the same procedure of tutorial of propeller and generated mesh using sHM and block mesh, using stl files for the propeller.

When I run the case with pimpleDyMFoam

1. Initially the weights are like this :

AMI: Creating addressing and weights between 35960 source faces and 35960 target faces
AMI: Patch source weights min/max/average = 1, 1.54876, 1.0002
AMI: Patch target weights min/max/average = 1, 1.52417, 1.0002
AMI: Creating addressing and weights between 55930 source faces and 55930 target faces
AMI: Patch source weights min/max/average = 1, 2.61619, 1.00016
AMI: Patch target weights min/max/average = 1, 1.76824, 1.00015

• Is it possible to have weight in the rage of 1.5 ~ 2.5 as my maximum values show .. ?

2. But for the first time step the weights fall very drastically to

AMI: Creating addressing and weights between 35960 source faces and 35960 target faces
AMI: Patch source weights min/max/average = 8.86522e-11, 1.54876, 0.994352
AMI: Patch target weights min/max/average = 1.54121e-06, 1.52417, 0.994342
AMI: Creating addressing and weights between 55930 source faces and 55930 target faces
AMI: Patch source weights min/max/average = 1.03257e-10, 2.61278, 0.993669
AMI: Patch target weights min/max/average = 5.03742e-06, 1.74141, 0.993662

NOTE : I have two AMI interfaces. Both have same rotational speeds.
(The time step is of the order 1e-5 and max corrent number is specified as 2 in controlDict)


The weights are not reducing further .. but increasing slowly. But the simulation at the end diverges giving abnormal mass flows at the outlet.

Also I am not able to run the simulation parallel. The simulation crashes in the beginning (even before starting of time loop) saying some points are bad points.

I am using OF 2.1.1.

Can any one help me what is happening wrong with the simulation process ??


Thanks in advance

[wyldckat]

Greetings Aditya,

You have both weights that are very high "2.61278" and others very low "8.86522e-11". This looks like you have faces on one side that are barely contacting the faces on the other side, and probably also have very large faces that are in contact with 2 or more faces at the same time.

My advice: step back to a simpler geometry first and then gradually increase the complexity of the case. This way it'll be easier to assess what the problem is.

Best regards,
Bruno

[lordvon]

I just wanted to add a case of my own:

I was simulating two rotors in 2D and it worked perfectly in most cases. However, occasionally when I changed geometric configurations it would crash via minimum and maximum patch weights of 0 and O(10^2), respectively, on one of the rotors. The other rotor would have minimum and maximum patch weights of 1 (working perfectly). The mesh around the two rotors were always of the same mesh density.

I was using Gmsh to generate unstructured mixed quad/tris (2D extruded into 3D). Sometimes if I just changed the mesh density the problem would go away, but not in any predictable way. 'checkmesh -constant -allGeometry -allTopology' returned no errors. The moveDynamicMesh appeared to be giving perfectly fine mesh movement when viewed in paraview, but the patch weights were off. One error message in the runtime output was that 1 or 2 non-overlapping faces were found. I thought maybe if I slightly expanded the rotor region or slightly contracted the stator region the problem would be solved, but I did not try it out because I was using createBaffles and splitOrMergeBaffles on one mesh to create the interfaces and this convenience was too great to give up (If i tried to resize the mesh using openfoam utilities I would have to create two different meshes and use mergeMeshes, and then manually assign zones, sets, etc.).

So, I found a solution finally by only producing tris instead of both tris and quads (quads in Gmsh are made by the 'Recombine' command). I could still produce quads in regions that did not include the interface. Later testing found that I could also recombine the rotors (moving meshes) and no error would occur. It was only the stator that I had to leave completely composed of tris. So, the problem was with the mesh, but I was not able to pinpoint exactly why.

[lordvon]

Another tip that I think may have been mentioned before by other users:

Sometimes the simulation will unexpectedly crash, after running stably for a long time. The patch weights are very close to 1 (within +/- 0.001 in my case), except on the time step it crashes, where the patch weights suddenly go crazy. I found that if you just restart the case from the last saved time step with a different Courant number, you can continue to run the simulation.

It seems that (very) specific angular orientations with your mesh can be problematic for AMI. If you just skip over these problematic orientations, you can run the simulation normally. Once past the problematic time step, you can change the Courant number back to what it originally was.

[arashfluid]

Hi friends,
I want to use AMI for interface between two region(rotating and stationary) of oscillating airfoil domain. For this purpose,I've created a mesh using Gambit.
Mesh consists of two regions that is defines two Walls on interface.One is for rotating region and another is stationary region.Then I convert mesh to OF by fluent3DMeshToFoam.Then I separated two regions with:
splitMeshRegions -makeCellZones -overwrite
and modify AMI interface in boundary file as follow:

statorAMI
{
type cyclicAMI;
nFaces 240;
startFace 48279;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch rotorAMI;
}
rotorAMI
{
type cyclicAMI;
nFaces 190;
startFace 48519;
matchTolerance 0.0001;
transform noOrdering;
neighbourPatch statorAMI;
}

But when I run moveDynamicMesh the whole of domain rotating with oscillatingRotatingMotion,While just rotating region should be rotated.
mesh file is attached.
please help me friends.

[lordvon]

Arash, can you post your 'constant/dynamicMeshDict'? I am wondering if you defined only your inner zone to move in this file.

[arashfluid]

Originally Posted by lordvon

Arash, can you post your 'constant/dynamicMeshDict'? I am wondering if you defined only your inner zone to move in this file.

yes,this file is my dynamicMeshDict.

[lordvon]

Ok, try defining the cellZone to be the region you want to rotate. (i.e.: cellZone insideZoneName)

and comment out 'faceZone...'

[arashfluid]

Originally Posted by lordvon

Ok, try defining the cellZone to be the region you want to rotate. (i.e.: cellZone insideZoneName)

and comment out 'faceZone...'

I was initially put cellzone,but I get the following error:
Applying solid body motion to cellZone airfoil
#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigSegv::sigHandler(int) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::solidBodyMotionFvMesh::solidBodyMotionFvMesh (Foam::IOobject const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libdynamicFvMesh.so"
#4 Foam::dynamicFvMesh::addIOobjectConstructorToTable <Foam::solidBodyMotionFvMesh>::New(Foam::IOobjec t const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libdynamicFvMesh.so"
#5 Foam::dynamicFvMesh::New(Foam::IOobject const&) in "/opt/openfoam211/platforms/linux64GccDPOpt/lib/libdynamicFvMesh.so"
#6
in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
#7 __libc_start_main in "/lib/libc.so.6"
#8
in "/opt/openfoam211/platforms/linux64GccDPOpt/bin/pimpleDyMFoam"
Segmentation fault
When I changed to faceZone,The error has been resolved.Where is the problem exactly?

[lordvon]

Can you upload the case? I will try it out.

[arashfluid]

Originally Posted by lordvon

Can you upload the case? I will try it out.

yes,please give me your mail.File size is 5 MB and can not upload here.