[sajjjad]

hi my frinds
i have to use 2 AMI Cylinder (stick together) with Rotation opposite direction.
What should I do? someone have a example. please share with us.
please advise me

openfoam3.0.1
Greetings, sajad.

[sajjjad]

Let question other way to say.
I want use Ami between Two propeller(Sticking).
but Ami cylinder very near to blades and give error(text above) .(I think error for this)
now
1- how use AMI for Ami cylinder very near to Rotating body?
2-There is another way(simple and beter way) Instead AMI?
thank you
sajjad.

[wyldckat]

Quick answers: I got the PMs you sent me... with only the information you've provided, I'm unable to say much, because the "createPatchDict" seems OK.

If you could share the mesh, preferably one that is a lot simpler and without the blades, it would be easier to help.

The best I'm able to tell you is that:

1. Using MRF is another alternative, although it might not be as accurate.
2. With both MRF and AMI, you cannot have the blades too close to the interfacing patches, because that can lead to problems on how the fluid is going from one region to the other... it's sort of like the fluid will thrash about if the blades are too close to the interface boundary.
3. The only other alternative that I can think of is overset grid (chimera grid), which is available in OpenFOAM.com (v1806) and I believe that it's also in foam-extend 4.1 that is still in development (foam-extend.org, repo foam-extend 4.0, branch "nextRelease").
4. Last but not least: Perhaps you have the mesh in the wrong units? The mesh has to be in meters, not millimeters.

[sajjjad]

Originally Posted by wyldckat

Quick answers: I got the PMs you sent me... with only the information you've provided, I'm unable to say much, because the "createPatchDict" seems OK.

If you could share the mesh, preferably one that is a lot simpler and without the blades, it would be easier to help.

The best I'm able to tell you is that:

1. Using MRF is another alternative, although it might not be as accurate.
2. With both MRF and AMI, you cannot have the blades too close to the interfacing patches, because that can lead to problems on how the fluid is going from one region to the other... it's sort of like the fluid will thrash about if the blades are too close to the interface boundary.
3. The only other alternative that I can think of is overset grid (chimera grid), which is available in OpenFOAM.com (v1806) and I believe that it's also in foam-extend 4.1 that is still in development (foam-extend.org, repo foam-extend 4.0, branch "nextRelease").
4. Last but not least: Perhaps you have the mesh in the wrong units? The mesh has to be in meters, not millimeters.

hi Dear Bruno
thank you very much.
I cant use MRF becuse I must run unsteady.
this file is system folder please look this.
I can sent my complete file your mail address?
Greetings.sajad

[wyldckat]

Quick answers:

Originally Posted by sajjjad

this file is system folder please look this.

Without the STL files for the AMI patches, there isn't much I can do... that said, I strongly suggest that you set the refinement levels for the feature edges all down to "0", because refined edges are usually troublesome.

Originally Posted by sajjjad

I can sent my complete file your mail address?

No, it will simply get lost in the list of unread emails that takes me about a year to sift through...

Keep it simple and re-adapt the case to not have the blades, only have the STL cylinders. Or better yet, if possible, use the "cylinder" feature that snappyHexMesh provides, e.g.:

    cylinder
    {
        type searchableCylinder;
        point1 (0 -4 0);
        point2 (0 4 0);
        radius 0.7;
}

That way you wouldn't have to deal with discretization errors due to the precision on the STL cylinders...

If you were using OpenFOAM 5 or 6, you could create base meshes with blockMesh that were already cylindrical and more easily matching between sides, examples:

• https://github.com/OpenFOAM/OpenFOAM.../blockMeshDict
• https://github.com/OpenFOAM/OpenFOAM.../blockMeshDict

If it's still too large, then use a file sharing website... and if you don't want to make the case accessible to the public, then send me the link via private message. However, I will not be able to look at it before the next weekend

[sajjjad]

Originally Posted by wyldckat

Quick answers:

Without the STL files for the AMI patches, there isn't much I can do... that said, I strongly suggest that you set the refinement levels for the feature edges all down to "0", because refined edges are usually troublesome.


No, it will simply get lost in the list of unread emails that takes me about a year to sift through...

Keep it simple and re-adapt the case to not have the blades, only have the STL cylinders. Or better yet, if possible, use the "cylinder" feature that snappyHexMesh provides, e.g.:

    cylinder
    {
        type searchableCylinder;
        point1 (0 -4 0);
        point2 (0 4 0);
        radius 0.7;
}

That way you wouldn't have to deal with discretization errors due to the precision on the STL cylinders...

If you were using OpenFOAM 5 or 6, you could create base meshes with blockMesh that were already cylindrical and more easily matching between sides, examples:

• https://github.com/OpenFOAM/OpenFOAM.../blockMeshDict
• https://github.com/OpenFOAM/OpenFOAM.../blockMeshDict

If it's still too large, then use a file sharing website... and if you don't want to make the case accessible to the public, then send me the link via private message. However, I will not be able to look at it before the next weekend

hi Dear Bruno
Thank you so much for your advice. I set the refinement levels for the feature edges all down to "0" and made cylinder with snappyHexMesh
I see first time AMI for second AMI path. but Unfortunately give this AMI error(new error).
https://drive.google.com/open?id=1j6...93Esu3V7UlieHK
this address for my case.
Greetings.sajad

[wyldckat]

Greetings Sajad,

OK, I think I now understand the main issue: there are faces with a weight of zero that are not matching those on the other patch...

What I mean is that the actual combination of faces that exist are as follows:

• "innerCylinder-fore" matches with "innerCylinder-fore_slave"
• "innerCylinder-aft" matches with "innerCylinder-aft_slave"
• and the missing match is for example "innerCylinder-fore" with "innerCylinder-aft", namely the patches that are meant to match with each other between the 2 cylinders...

First, you need to check which patch names are actually meant to match, because I'm not sure if it's the master patch or the slave patches.



Then you will have to use topoSet with a "topoSetDict" that is configured to:

1. Create a new "faceSet" that is based on the first patch.
2. Then "subset" that "faceSet" to only select the faces that are within a certain box, namely the region where the patch you need on this side.
3. Then do the same for the other patch.

It should be something like this:

actions
(
    // gather all faces from patch
    {
        name    innerCylinderAftBetweenCyls;
        type    faceSet;
        action  new;
        source patchToFace;
        sourceInfo
        {
            name "innerCylinder-aft";
        }
    }

    //select only the faces that are within the box
    {
        name    innerCylinderAftBetweenCyls;
        type    faceSet;
        action  subset;
        source  boxToFace;
        sourceInfo
        {
            //You need to update these values
            box  (0 0 0) (1 1 1);
        }
    }


    // gather all faces from patch
    {
        name    innerCylinderForeBetweenCyls;
        type    faceSet;
        action  new;
        source patchToFace;
        sourceInfo
        {
            name "innerCylinder-fore";
        }
    }

    //select only the faces that are within the box
    {
        name    innerCylinderForeBetweenCyls;
        type    faceSet;
        action  subset;
        source  boxToFace;
        sourceInfo
        {
            //The box can be the same as above
            box  (0 0 0) (1 1 1);
        }
    }

);

The box must only be big enough to capture the face centres that are needed.


In case the box isn't practical or doesn't work, try using:

    // Faces with normal to within certain angle aligned with vector.
    source normalToFace;
    sourceInfo
    {
        normal (0 0 1);     // Vector
        cos     0.01;       // Tolerance (max cos of angle)
    }

Then you have to use createPatch to create a new pair of cyclicAMI based on these two "faceSets", e.g.:

    {
        //- Master side patch
        name            AMI_between1;
        patchInfo
        {
            type            cyclicAMI
            matchTolerance  0.0001;
            neighbourPatch  AMI_between2;
            transform       noOrdering;
        }
        constructFrom set;
        set innerCylinderAftBetweenCyls;
    }

    {
        //- Slave side patch
        name            AMI_between2;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  0.0001;
            neighbourPatch  AMI_between1;
            transform       noOrdering;
        }
        constructFrom set;
        set innerCylinderForeBetweenCyls;
    }

Then after you get it up and running, check if there are any 0 weights:

AMI: Patch source sum(weights) min/max/average = 0, 6.92893, 0.995144

If the first value is 0 then it will crash for the same reason. You need all faces to match with another face.



Best regards,
Bruno

[sajjjad]

Originally Posted by wyldckat

Greetings Sajad,

OK, I think I now understand the main issue: there are faces with a weight of zero that are not matching those on the other patch...

What I mean is that the actual combination of faces that exist are as follows:

• "innerCylinder-fore" matches with "innerCylinder-fore_slave"
• "innerCylinder-aft" matches with "innerCylinder-aft_slave"
• and the missing match is for example "innerCylinder-fore" with "innerCylinder-aft", namely the patches that are meant to match with each other between the 2 cylinders...

First, you need to check which patch names are actually meant to match, because I'm not sure if it's the master patch or the slave patches.



Then you will have to use topoSet with a "topoSetDict" that is configured to:

1. Create a new "faceSet" that is based on the first patch.
2. Then "subset" that "faceSet" to only select the faces that are within a certain box, namely the region where the patch you need on this side.
3. Then do the same for the other patch.

It should be something like this:

actions
(
    // gather all faces from patch
    {
        name    innerCylinderAftBetweenCyls;
        type    faceSet;
        action  new;
        source patchToFace;
        sourceInfo
        {
            name "innerCylinder-aft";
        }
    }

    //select only the faces that are within the box
    {
        name    innerCylinderAftBetweenCyls;
        type    faceSet;
        action  subset;
        source  boxToFace;
        sourceInfo
        {
            //You need to update these values
            box  (0 0 0) (1 1 1);
        }
    }


    // gather all faces from patch
    {
        name    innerCylinderForeBetweenCyls;
        type    faceSet;
        action  new;
        source patchToFace;
        sourceInfo
        {
            name "innerCylinder-fore";
        }
    }

    //select only the faces that are within the box
    {
        name    innerCylinderForeBetweenCyls;
        type    faceSet;
        action  subset;
        source  boxToFace;
        sourceInfo
        {
            //The box can be the same as above
            box  (0 0 0) (1 1 1);
        }
    }

);

The box must only be big enough to capture the face centres that are needed.


In case the box isn't practical or doesn't work, try using:

    // Faces with normal to within certain angle aligned with vector.
    source normalToFace;
    sourceInfo
    {
        normal (0 0 1);     // Vector
        cos     0.01;       // Tolerance (max cos of angle)
    }

Then you have to use createPatch to create a new pair of cyclicAMI based on these two "faceSets", e.g.:

    {
        //- Master side patch
        name            AMI_between1;
        patchInfo
        {
            type            cyclicAMI
            matchTolerance  0.0001;
            neighbourPatch  AMI_between2;
            transform       noOrdering;
        }
        constructFrom set;
        set innerCylinderAftBetweenCyls;
    }

    {
        //- Slave side patch
        name            AMI_between2;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  0.0001;
            neighbourPatch  AMI_between1;
            transform       noOrdering;
        }
        constructFrom set;
        set innerCylinderForeBetweenCyls;
    }

Then after you get it up and running, check if there are any 0 weights:

AMI: Patch source sum(weights) min/max/average = 0, 6.92893, 0.995144

If the first value is 0 then it will crash for the same reason. You need all faces to match with another face.



Best regards,
Bruno

hi dear Bruno
thank you so much.
I'll do your advise and I will report the result.
Greetings,sajad

[sajjjad]

hi Dear Bruno
I know you are very busy. but I cant fixed it and I have no another choice.sorry
I don't know my works is correct!!


in paraview patch AMI_between not exist .
please look at my file.
Greetings, sajad

[wyldckat]

Quick answer: I need 2 things:

1. The folder "0" and all files therein, right before starting the simulation.
2. The file "constant/polyMesh/boundary".

edit: Oh, and I need the output of using:

checkMesh -allTopology -allGeometry

Hopefully this reports any details that might be missing in the mesh...

[sajjjad]

Originally Posted by wyldckat

Quick answer: I need 2 things:

1. The folder "0" and all files therein, right before starting the simulation.
2. The file "constant/polyMesh/boundary".

edit: Oh, and I need the output of using:

checkMesh -allTopology -allGeometry

Hopefully this reports any details that might be missing in the mesh...

hi Dear Bruno
It does not seem to create AMI_between patch!
thank you.
Greetings, sajad

[wyldckat]

Quick answer: OK... this looks like it's going to be a bit of a tough diagnosis to do...

So, the one detail I'm able to see is that the log for createPatch told us this:

Adding new patch AMI_between1 as patch 12 from 
{
    type            cyclicAMI matchTolerance 0.0001;
    neighbourPatch  AMI_between2;
    transform       noOrdering;
}

Notice anything weird? There is a semi-colon missing after "cyclicAMI", which I can confirm in the "createPatchDict" file you attached in the previous post:

 {
        //- Master side patch
        name            AMI_between1;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  0.0001;
            neighbourPatch  AMI_between2;
            transform       noOrdering;
        }
        constructFrom set;
        set innerCylinderAftBetweenCyls;
    }

I added the semi-colon now, after the text in bold.

The reason as to why I also made this mistake in a previous post of mine, was because it was already a mistake in the AMI1 definition you have:

    {
        //- Master side patch
        name            AMI1;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  0.0001;
            neighbourPatch  AMI2;
            transform       noOrdering;
        }
        constructFrom patches;
        patches (innerCylinder-fore);
    }

It's the same exact error and I added the semi-colon in the code above.


Now, this is what I'm able to diagnose from just these files. The next step is something only you can diagnose. Run the following commands:

foamToVTK -faceSet innerCylinderAftBetweenCyls
foamToVTK -faceSet innerCylinderForeBetweenCyls

Then open the respective "VTK/*/*.vtk" files in ParaView, to see if these faces are actually the correct ones.
This is just in case the opposite sides of the cylinders were chosen, because if they are not on the same shared plane, then you need to correct the normals defined in "topoSetDict".

[sajjjad]

Originally Posted by wyldckat

Quick answer: OK... this looks like it's going to be a bit of a tough diagnosis to do...

So, the one detail I'm able to see is that the log for createPatch told us this:

Adding new patch AMI_between1 as patch 12 from 
{
    type            cyclicAMI matchTolerance 0.0001;
    neighbourPatch  AMI_between2;
    transform       noOrdering;
}

Notice anything weird? There is a semi-colon missing after "cyclicAMI", which I can confirm in the "createPatchDict" file you attached in the previous post:

 {
        //- Master side patch
        name            AMI_between1;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  0.0001;
            neighbourPatch  AMI_between2;
            transform       noOrdering;
        }
        constructFrom set;
        set innerCylinderAftBetweenCyls;
    }

I added the semi-colon now, after the text in bold.

The reason as to why I also made this mistake in a previous post of mine, was because it was already a mistake in the AMI1 definition you have:

    {
        //- Master side patch
        name            AMI1;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  0.0001;
            neighbourPatch  AMI2;
            transform       noOrdering;
        }
        constructFrom patches;
        patches (innerCylinder-fore);
    }

It's the same exact error and I added the semi-colon in the code above.


Now, this is what I'm able to diagnose from just these files. The next step is something only you can diagnose. Run the following commands:

foamToVTK -faceSet innerCylinderAftBetweenCyls
foamToVTK -faceSet innerCylinderForeBetweenCyls

Then open the respective "VTK/*/*.vtk" files in ParaView, to see if these faces are actually the correct ones.
This is just in case the opposite sides of the cylinders were chosen, because if they are not on the same shared plane, then you need to correct the normals defined in "topoSetDict".

I'm sorry for the my mistake.
Bruno seem that No matter which i normal to choose (I tried 4 modes. 2 modes at all doesnt create patchs and 2 modes...).nface BetweenAMI is zero!.and
innerCylinderForeBetweenCyls look outercylinder and innerCylinderaftBetweenCyls look propeller.
Greetings, sajad

[wyldckat]

Hi Sajad,

We are having some considerable difficulties in thinking about the same geometrical part...

I looked at the past posts and the geometry you had provided sometime ago... and apparently the problem is that we aren't thinking about the same patches.

So, what I ask you to do is the following steps:

1. Generate the mesh up to and including snappyHexMesh.
2. Do not do any additional changes to the mesh.
3. Now open the case in ParaView, by using the usual command:
   

   paraFoam

4. Now look at the several patches that should exist:
   • innerCylinder-fore
   • innerCylinder-fore_slave
   • innerCylinder-aft
   • innerCylinder-aft_slave
5. You know that each pair of these patches is a different side of each cylinder surface.
6. Look at each patch individually in ParaView and check if they have faces that are shared on the same side of the cylinders... I'm referring to the surface that is shared between the 2 cylinders.
7. Once you are able to find the name of the patches that share the same surface, then you can use those patches to go through the workflow that I indicated, namely to use topoSet and createPatch.

If you are still having difficulties, then please take a step back and create a simpler test case:

1. Only have the 2 cylinders that are meant to have AMI interfaces.
2. Mesh them with snappyHexMesh.
3. Then share this case.

This way it's easier for me or anyone else to look into this.

Best regards,
Bruno

[sajjjad]

Originally Posted by wyldckat

Hi Sajad,

We are having some considerable difficulties in thinking about the same geometrical part...

I looked at the past posts and the geometry you had provided sometime ago... and apparently the problem is that we aren't thinking about the same patches.

So, what I ask you to do is the following steps:

1. Generate the mesh up to and including snappyHexMesh.
2. Do not do any additional changes to the mesh.
3. Now open the case in ParaView, by using the usual command:
   

   paraFoam

4. Now look at the several patches that should exist:
   • innerCylinder-fore
   • innerCylinder-fore_slave
   • innerCylinder-aft
   • innerCylinder-aft_slave
5. You know that each pair of these patches is a different side of each cylinder surface.
6. Look at each patch individually in ParaView and check if they have faces that are shared on the same side of the cylinders... I'm referring to the surface that is shared between the 2 cylinders.
7. Once you are able to find the name of the patches that share the same surface, then you can use those patches to go through the workflow that I indicated, namely to use topoSet and createPatch.

If you are still having difficulties, then please take a step back and create a simpler test case:

1. Only have the 2 cylinders that are meant to have AMI interfaces.
2. Mesh them with snappyHexMesh.
3. Then share this case.

This way it's easier for me or anyone else to look into this.

Best regards,
Bruno

hi Dear Bruno
innerCylinder-fore pair of innerCylinder-fore_slave
innerCylinder-aft pair of innerCylinder-aft_slave
and those correct in paraview.
Bruno just surface that is shared between cylinder no exist!!!(please look picture).

and this file just AMI interfaces.

Greetings,sajad

[wyldckat]

Hi Sajad,

I started looking into this yesterday (Saturday), but didn't manage to try things for myself. Nonetheless, after snappyHexMesh is finished running, there is something you might not have noticed:

1. On one of the cylinders, there were only a few faces associated on the surface between the two cylinders.
2. On the other cylinder, the cylinder was almost closed, but was missing the faces that were on the other cylinder.
3. So what you need to do is collect the faces for both cylinders into a single face set, then get only the faces that matter in function of the normal...

I don't know if I'll have time later today (Sunday) to look into this more closely and try things for myself.


Best regards,
Bruno

[wyldckat]

Quick answer: I managed to find the time to look into this, because I was curious on whether we could get this to work or not... well, it seems to sort of work, but I haven't tested simulating with it, so the normals in "topoSetDict" could be incorrect.

Furthermore, I strongly suggest that you correct the base mesh to align properly with the cylinders, because not having a mesh aligned with the cylinders on the Y-Z plane is wreaking havoc on the patches we are trying to create, namely the "AMI*_between". If you look at the patches when it's done running, you will see that there are still faces missing and that is because the faces that are meant to be on these patches, are inclined due to having to respect the mesh quality.

Attached is the revised case. You can use Meld or Kompare to see the changes I've done.
It has "partially fixed" in the name, because I didn't correct the base mesh.

[sajjjad]

Originally Posted by wyldckat

Quick answer: I managed to find the time to look into this, because I was curious on whether we could get this to work or not... well, it seems to sort of work, but I haven't tested simulating with it, so the normals in "topoSetDict" could be incorrect.

Furthermore, I strongly suggest that you correct the base mesh to align properly with the cylinders, because not having a mesh aligned with the cylinders on the Y-Z plane is wreaking havoc on the patches we are trying to create, namely the "AMI*_between". If you look at the patches when it's done running, you will see that there are still faces missing and that is because the faces that are meant to be on these patches, are inclined due to having to respect the mesh quality.

Attached is the revised case. You can use Meld or Kompare to see the changes I've done.
It has "partially fixed" in the name, because I didn't correct the base mesh.

Hi Dear Bruno
Thank you very much.
You know, For a a few day I'm didn't working and I did not notice the new message.sorry man.
I listen to your advice and tell you the result of our work.
Greetings,sajad

[sajjjad]

Hi Dear Bruno
I'm embarrassed for bother,sorry Bruno.
i modification base mesh. and that is worked. thank you.
but when i added propellers to snappy, foam give this error. i searched and
some people tell is this bug foam but when alone cylinder it is worked.!!!


Bruno possible error for that propellers close to cylinder ami?

and one cylinder not rotating. i fixed just when i search for error some guys tell this error for axis rotation .i check cylinder and rotation is correct.
one file is your file with beter base mesh.that is ok and runed.
secend file(google drive) is propeller added to code.
https://drive.google.com/open?id=1eH...TKri18ktxUjNJ2
Greetings, sajad

[RafaelMN]

Hi sajjad
My name is Rafael and I am new using openFoam, I am doing the same thing, I am working with two amis (stick together) with opposite rotation, I used topoSet to create these AMIs and everything works, I did not have any error with this tool
I would like to know if you were able to solve your problem and if you obtained results.
This is part of my error.I don't know if it's a solver problem or if I put a wrong value. Could you help me?