CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Pre-Processing

decomposePar fails: supplied field size is not equal to target patch size

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 11, 2016, 02:55
Default decomposePar fails: supplied field size is not equal to target patch size
  #1
New Member
 
Andrew Furmidge
Join Date: Sep 2016
Posts: 1
Rep Power: 0
AndrewF is on a distinguished road
Hello everyone,

This is my first post on the forums, although I have lurked for some time. I have searched for this problem, but I could not find an instance that was exactly specific to my problem. I am trying to mimic the propeller tutorial.

The basics of my case:
I am trying to simulate a rotating turbine with the rotating axis perpendicular to the oncoming air. I used blockMesh to create the background mesh for snappyHexMesh. SHM resulted in a good mesh that I could view in paraview. Then I created two patches for the dynamic mesh: AMI1 and AMI2. I used moveDynamicMesh -checkAMI to create multiple meshes at incremental timesteps. The mesh was moving as it should.

The problem/symptom:
When I used decomposePar to prepare the mesh for parallel execution, I received a fatal error because the supplied field size is not equal to target patch size. The target patch size = 0 and the supplied field size = 309032.

Upon my own investigation:
In case>constant>polymesh>boundary this is what I see for the two cyclicAMI patches...
Code:
    AMI1
    {
        type            cyclicAMI;
        inGroups        1(cyclicAMI);
        nFaces          0;
        startFace       12629396;
        matchTolerance  0.0001;
        transform       noOrdering;
        neighbourPatch  AMI2;
    }
    AMI2
    {
        type            cyclicAMI;
        inGroups        1(cyclicAMI);
        nFaces          309032;
        startFace       12629396;
        matchTolerance  0.0001;
        transform       noOrdering;
        neighbourPatch  AMI1;
    }
It is strange that AMI2 was created from innerCylidner_slave patch which was created from innerCylinder patch which created AMI1. I think that AMI1 and AMI2 should have the same amount of faces. As seen below in my createPatchDict...
Code:
    {
        //- Master side patch
        name            AMI1;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  0.0001;
            neighbourPatch  AMI2;
            transform       noOrdering;
        }
        constructFrom patches;
        patches (innerCylinder); 
    }

    {
        //- Slave side patch
        name            AMI2;
        patchInfo
        {
            type            cyclicAMI;
            matchTolerance  0.0001;
            neighbourPatch  AMI1;
            transform       noOrdering;
        }
        constructFrom patches;
        patches (innerCylinder_slave);
    }
After this, I went back into paraview and realized that the cyclicAMI group existed as did AMI2 patch, but AMI1 was not created. I assume this is because AMI1 has 0 faces and essentially does not exist. I have seen posts here where people had 0 faces for either AMI.

What I have tried:
I have tried changing nFaces of AMI1 in the boundary file to 309032 like the code requests and running decomposePar, but that does not help obviously because the patch is still actually made of 0 faces. I will try to remesh with SHM again tonight, but I do not think that will help.

Are there any other files that I can post to help you help me find a solution to my problem, such as my SHM dict? Has anyone else had problems with one side of the interface not being created and the other side being created just fine? Thank you in advance for your help.

EDIT:
I remeshed the case, now both AMI1 and AM2 have some non-zero number of faces. Both patches can be seen in paraview now. I may have changed something between runs that I do not remember. It decomposes correctly among processors, and now I have different problems when solving that I will research (not mesh related problems).

Last edited by AndrewF; September 11, 2016 at 14:25.
AndrewF is offline   Reply With Quote

Reply


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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Superlinear speedup in OpenFOAM 13 msrinath80 OpenFOAM Running, Solving & CFD 18 March 3, 2015 05:36
Moving mesh Niklas Wikstrom (Wikstrom) OpenFOAM Running, Solving & CFD 122 June 15, 2014 06:20
critical error during installation of openfoam Fabio88 OpenFOAM Installation 21 June 2, 2010 03:01
Problem with rhoSimpleFoam matteo_gautero OpenFOAM Running, Solving & CFD 0 February 28, 2008 06:51
Phase locked average in run time panara OpenFOAM 2 February 20, 2008 14:37


All times are GMT -4. The time now is 04:27.