incorrect number of patch type specifications error in fallingDrop test case

[kwardle]

I had some time to revisit this and so I downloaded the most recent version of both the library and OF-2.3.x yesterday and tried to get it working. In the fallingDrop test case if set it to run on 4 processors, as soon as it gets to a redistribution, it dies with an error saying the number of patch type specifications is wrong. Is there some changes I missed in the source that need to be made to fix this? The README file did not mention this specific error.
THANKS
-Kent

---

....
Starting time loop

Interface Courant Number mean: 0 max: 0
Courant Number mean: 2.560914e-06 max: 2.862741e-05
deltaT = 1.197605e-08
Time = 1.197605e-08

Calculating internal refinement field
Adding cells with center within boxes 1((-1 0.001 0.002) (1 0.005 0.003))
Min,max refinement field = 0, 707.1068
Selected 181 cells for refinement out of 625.
Refined from 625 to 1892 cells.
Selected 0 split points out of a possible 181.
Maximum imbalance = 18.18182 %
Re-balancing dynamically refined mesh
Selecting decompositionMethod ptscotch
Execution time for mesh.update() = 0.1 s
[0] [3]
[3]
[3] --> FOAM FATAL ERROR:
[3] Incorrect number of patch type specifications given
Number of patches in mesh = 5 number of patch type specifications = 6
[3]
[3] From function GeometricField<Type, PatchField, GeoMesh>::GeometricBoundaryField::GeometricBoundaryField(const BoundaryMesh&, const DimensionedField&, const wordList&, const wordList&)
[3] in file /home/wardke/OpenFOAM/OpenFOAM-2.3.x/src/OpenFOAM/lnInclude/GeometricBoundaryField.C at line 312.
[3]
FOAM parallel run aborting
[3]

[0]
[0] --> FOAM FATAL ERROR:
[0] Incorrect number of patch type specifications given
Number of patches in mesh = 5 number of patch type specifications = 6
[0]
[0] From function GeometricField<Type, PatchField, GeoMesh>::GeometricBoundaryField::GeometricBoundaryField(const BoundaryMesh&, const DimensionedField&, const wordList&, const wordList&)
[0] in file /home/wardke/OpenFOAM/OpenFOAM-2.3.x/src/OpenFOAM/lnInclude/GeometricBoundaryField.C at line 312.
[0]
FOAM parallel run aborting
[0]
[3] #0 Foam::error::printStack(Foam::Ostream&)[0] #0 ----------

[kwardle]

Is this perhaps related to item 3 from the old README file which calls for changes in src/finiteVolume/fvMesh/nearWallDist.C?

[tgvoskuilen]

Look under the "Notes" section. You have to edit interDyMFoam by moving the call to createPrghCorrTypes inside correctPhi since that uses the number of patches.

[kwardle]

Tyler,
Thanks for pointing this out. My apologies for missing this in the README file---now that you point it out I recall reading it and forgetting to make the change. With this change, the fallingDrop case appears to be working just fine with no warnings or errors. Unfortunately, my own case which also uses interDyMFoam does not work. When it gets to the first balancing step it dies with the following error:

[5] --> FOAM FATAL ERROR:
[5] Cell 7063 is not visible
[5]
[5] From function refinementHistory::parentIndex(const label)
[5] in file /home/wardke/OpenFOAM/OpenFOAM-2.3.x/src/dynamicMesh/lnInclude/refinementHistory.H at line 296.
[5]
FOAM parallel run aborting

Perhaps there are some additional changes I have missed? I suppose it is also possible this is due to something unique about my case setup you have not yet encountered. I am simulating the turbulent breakup of a liquid drop using periodic boundaries in all directions--specifically, I am using cyclicAMI patch types though a straight cyclic type might work as well. Any problems with this?
-Kent

---

From: tgvoskuilen [[email protected]]
Sent: Thursday, June 19, 2014 7:16 AM
To: tgvoskuilen/meshBalancing
Cc: Wardle, Kent E.
Subject: Re: [meshBalancing] incorrect number of patch type specifications error in fallingDrop test case (#3)

Look under the "Notes" section. You have to move the call to createPrghCorrTypes inside correctPhi since that gets the number of patches.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-46553085.

[tgvoskuilen]

Kent,

That's not an error I've seen before, but if I had to guess I'd say it's related to the cyclic patches somehow not being updated properly during the redistribution. You could turn on the debug flags for refinementHistory, polyTopoChange, and polyTopoChanger in etc/controlDict to see where it is failing. Is cell 7063 on a boundary?

-Tyler

[kwardle]

Tyler,
I added the debug flags, but the output is excessive and not particularly useful (to me anyway). As an alternative, I have put together a minimal case attached here which will reproduce this error for you. If you are able to take a look at it, that would be super helpful. In addition I will take a look at other ways of configuring the cyclic BCs. I set this case up some time back, but believe I had to use cyclicAMI because there was a mismatch resulting from refinement on the boundary faces. That said, at the same time there was also a bug that was making the boundary cells not update correctly. This was corrected in #1218 so maybe standard cyclic will work, but I am not sure why that would behave differently in this case. Any help would be awesome.
I do appreciate your work on this library and your willingness to share it. I am jumping back into this part of my work again this summer and will be really excited to get this problem working with load balancing.
-Kent

---

From: tgvoskuilen [[email protected]]
Sent: Friday, June 20, 2014 9:58 AM
To: tgvoskuilen/meshBalancing
Cc: Wardle, Kent E.
Subject: Re: [meshBalancing] incorrect number of patch type specifications error in fallingDrop test case (#3)

Kent,

That's not an error I've seen before, but if I had to guess I'd say it's related to the cyclic patches somehow not being updated properly during the redistribution. You could turn on the debug flags for refinementHistory, polyTopoChange, and polyTopoChanger in etc/controlDict to see where it is failing. Is cell 7063 on a boundary?

-Tyler

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-46687707.

[tgvoskuilen]

It doesn't look like the attachment came through. You can just email that to me directly.

[kwardle]

I mailed you the file directly on 6/20. Have you had a chance to take a look and see how to go about fixing this?
Thanks,
Kent

---

From: tgvoskuilen [[email protected]]
Sent: Friday, June 20, 2014 11:24 AM
To: tgvoskuilen/meshBalancing
Cc: Wardle, Kent E.
Subject: Re: [meshBalancing] incorrect number of patch type specifications error in fallingDrop test case (#3)

It doesn't look like the attachment came through. You can just email that to me directly.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-46697986.

[tgvoskuilen]

I have gotten it, but have been traveling for interviews/conferences for
the past 2 weeks and haven't had a chance to look at it yet.

On Thu, Jul 3, 2014 at 5:36 PM, kwardle [email protected] wrote:

I mailed you the file directly on 6/20. Have you had a chance to take a
look and see how to go about fixing this?
Thanks,
Kent

---

From: tgvoskuilen [[email protected]]
Sent: Friday, June 20, 2014 11:24 AM
To: tgvoskuilen/meshBalancing
Cc: Wardle, Kent E.
Subject: Re: [meshBalancing] incorrect number of patch type specifications
error in fallingDrop test case (#3)

It doesn't look like the attachment came through. You can just email that
to me directly.

—
Reply to this email directly or view it on GitHub<
https://github.com/tgvoskuilen/meshBalancing/issues/3#issuecomment-46697986>.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[kwardle]

Tyler,
I realize this is a little stale and you have perhaps moved elsewhere by now (best of luck to you wherever you may be), but I thought I would check in with you on this in case you are still actively developing the load balancing library.
-Kent

---

Kent E. Wardle
Principal Nuclear Engineer
Nuclear Engineering Division
Argonne National Laboratory
630-252-4638
[email protected]
www.mcs.anl.gov/~wardlehttp://www.mcs.anl.gov/~wardle

---

From: tgvoskuilen [[email protected]]
Sent: Thursday, July 03, 2014 5:26 PM
To: tgvoskuilen/meshBalancing
Cc: Wardle, Kent E.
Subject: Re: [meshBalancing] incorrect number of patch type specifications error in fallingDrop test case (#3)

I have gotten it, but have been traveling for interviews/conferences for
the past 2 weeks and haven't had a chance to look at it yet.

Tyler Voskuilen, Ph.D.
Purdue University
[email protected]
Lab: (765) 494-1541
Office: (765) 494-0065
Cell: (765) 414-5695

On Thu, Jul 3, 2014 at 5:36 PM, kwardle [email protected] wrote:

I mailed you the file directly on 6/20. Have you had a chance to take a
look and see how to go about fixing this?
Thanks,
Kent

---

From: tgvoskuilen [[email protected]]
Sent: Friday, June 20, 2014 11:24 AM
To: tgvoskuilen/meshBalancing
Cc: Wardle, Kent E.
Subject: Re: [meshBalancing] incorrect number of patch type specifications
error in fallingDrop test case (#3)

It doesn't look like the attachment came through. You can just email that
to me directly.

—
Reply to this email directly or view it on GitHub<
https://github.com/tgvoskuilen/meshBalancing/issues/3#issuecomment-46697986>.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-47991547.