CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Problem using AMI

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree28Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   July 21, 2013, 14:37
Default
  #181
Member
 
reza1980's Avatar
 
reza
Join Date: Jan 2013
Location: Goteborg-Sweden
Posts: 79
Rep Power: 4
reza1980 is on a distinguished road
Bruno,
my guess to approach bad result is due to being these non-overlapped cells.Whats your idea to improve this problem.
reza1980 is offline   Reply With Quote

Old   July 21, 2013, 17:31
Default
  #182
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,301
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
Attached Images
File Type: jpg twoInternalFacesCells.jpg (86.0 KB, 64 views)

Last edited by wyldckat; August 18, 2013 at 18:27. Reason: Forgot to add the attachment
wyldckat is offline   Reply With Quote

Old   July 21, 2013, 17:37
Default
  #183
Member
 
reza1980's Avatar
 
reza
Join Date: Jan 2013
Location: Goteborg-Sweden
Posts: 79
Rep Power: 4
reza1980 is on a distinguished road
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.
reza1980 is offline   Reply With Quote

Old   August 18, 2013, 19:10
Default
  #184
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,301
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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:
    Code:
    cd rotor
    mergeMeshes -overwrite . ../stator
  4. Created the file "system/changeDictionaryDict" with the following content:
    Code:
    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:
    Code:
    changeDictionary
  6. And did a full mesh check:
    Code:
    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:
Code:
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:
Code:
topoSet
Then use mergeMeshes.


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


Best regards,
Bruno
linnemann, Alhasan and Jetfire like this.
wyldckat is offline   Reply With Quote

Old   August 19, 2013, 01:38
Default
  #185
Senior Member
 
linnemann's Avatar
 
Niels Nielsen
Join Date: Mar 2009
Location: NJ - Denmark
Posts: 450
Rep Power: 15
linnemann will become famous soon enough
If you just want the cellZones of each mesh this will be easier than topoSet

Code:
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 and Jetfire like this.
__________________
Linnemann

PS. I do not do personal support, so please post in the forums.
linnemann is offline   Reply With Quote

Old   August 19, 2013, 05:05
Default
  #186
Member
 
reza1980's Avatar
 
reza
Join Date: Jan 2013
Location: Goteborg-Sweden
Posts: 79
Rep Power: 4
reza1980 is on a distinguished road
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 is offline   Reply With Quote

Old   August 20, 2013, 06:13
Default
  #187
Member
 
reza1980's Avatar
 
reza
Join Date: Jan 2013
Location: Goteborg-Sweden
Posts: 79
Rep Power: 4
reza1980 is on a distinguished road
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







Quote:
Originally Posted by linnemann View Post
If you just want the cellZones of each mesh this will be easier than topoSet

Code:
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 is offline   Reply With Quote

Old   August 21, 2013, 06:55
Default
  #188
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,301
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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: how should we remove the Concave cells from the mesh? post #2

Best regards,
Bruno

Last edited by wyldckat; August 21, 2013 at 06:57. Reason: see "edit:"
wyldckat is offline   Reply With Quote

Old   August 23, 2013, 19:03
Default
  #189
Member
 
Join Date: Aug 2013
Posts: 50
Rep Power: 3
nash is on a distinguished road
hi could someone please help me with the problem creating AMI here :

Propeller case in AMI tutorial post #49
nash is offline   Reply With Quote

Old   September 5, 2013, 06:00
Unhappy Very low source and target patch Weights
  #190
New Member
 
Aditya
Join Date: May 2013
Location: Munich Germany
Posts: 27
Rep Power: 4
kingmaker is on a distinguished road
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
kingmaker is offline   Reply With Quote

Old   September 7, 2013, 09:43
Default
  #191
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,301
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   September 14, 2013, 16:05
Default
  #192
Senior Member
 
Robert
Join Date: Sep 2010
Posts: 154
Rep Power: 6
lordvon is on a distinguished road
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.
wyldckat likes this.
lordvon is offline   Reply With Quote

Old   September 24, 2013, 00:51
Default
  #193
Senior Member
 
Robert
Join Date: Sep 2010
Posts: 154
Rep Power: 6
lordvon is on a distinguished road
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.
lordvon is offline   Reply With Quote

Old   February 4, 2014, 12:15
Default AMI interface
  #194
Member
 
arash mahboubi
Join Date: Jun 2013
Location: Iran
Posts: 37
Rep Power: 4
arashfluid is on a distinguished road
Send a message via Yahoo to 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.
Attached Images
File Type: jpg gambit mesh.jpg (98.6 KB, 38 views)
arashfluid is offline   Reply With Quote

Old   February 4, 2014, 13:33
Default
  #195
Senior Member
 
Robert
Join Date: Sep 2010
Posts: 154
Rep Power: 6
lordvon is on a distinguished road
Arash, can you post your 'constant/dynamicMeshDict'? I am wondering if you defined only your inner zone to move in this file.
lordvon is offline   Reply With Quote

Old   February 4, 2014, 13:57
Post
  #196
Member
 
arash mahboubi
Join Date: Jun 2013
Location: Iran
Posts: 37
Rep Power: 4
arashfluid is on a distinguished road
Send a message via Yahoo to arashfluid
Quote:
Originally Posted by lordvon View Post
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.
Attached Files
File Type: zip dynamicMeshDict.zip (608 Bytes, 9 views)
arashfluid is offline   Reply With Quote

Old   February 4, 2014, 14:03
Default
  #197
Senior Member
 
Robert
Join Date: Sep 2010
Posts: 154
Rep Power: 6
lordvon is on a distinguished road
Ok, try defining the cellZone to be the region you want to rotate. (i.e.: cellZone insideZoneName)

and comment out 'faceZone...'
lordvon is offline   Reply With Quote

Old   February 4, 2014, 14:18
Post
  #198
Member
 
arash mahboubi
Join Date: Jun 2013
Location: Iran
Posts: 37
Rep Power: 4
arashfluid is on a distinguished road
Send a message via Yahoo to arashfluid
Quote:
Originally Posted by lordvon View Post
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?
arashfluid is offline   Reply With Quote

Old   February 4, 2014, 14:21
Default
  #199
Senior Member
 
Robert
Join Date: Sep 2010
Posts: 154
Rep Power: 6
lordvon is on a distinguished road
Can you upload the case? I will try it out.
lordvon is offline   Reply With Quote

Old   February 4, 2014, 14:28
Post
  #200
Member
 
arash mahboubi
Join Date: Jun 2013
Location: Iran
Posts: 37
Rep Power: 4
arashfluid is on a distinguished road
Send a message via Yahoo to arashfluid
Quote:
Originally Posted by lordvon View Post
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.
arashfluid is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
UDF compiling problem Wouter Fluent UDF and Scheme Programming 6 June 6, 2012 04:43
Gambit - meshing over airfoil wrapping (?) problem JFDC FLUENT 1 July 11, 2011 05:59
natural convection problem for a CHT problem Se-Hee CFX 2 June 10, 2007 06:29
Adiabatic and Rotating wall (Convection problem) ParodDav CFX 5 April 29, 2007 19:13
Is this problem well posed? Thomas P. Abraham Main CFD Forum 5 September 8, 1999 14:52


All times are GMT -4. The time now is 06:25.