View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001218OpenFOAM[All Projects] Bugpublic2014-03-12 20:272014-05-30 15:04
Reporterkwardle 
Assigned Toandy 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
PlatformLinuxOSUbuntu 12.04 LTSOS Version(please specify)
Product Version2.3.x 
Target VersionFixed in Version2.3.x 
Summary0001218: Crash on use of cyclicAMI with interDyMFoam
DescriptionWhen using interDyMFoam in conjunction with cyclicAMI boundaries (e.g. to simulate the flow in a periodic box with cyclicAMI patch pairs on each side) if you start the simulation with no interfaces near the boundaries, it runs fine for some time and then when the interface reaches a boundary and causes refinement it crashes with an error:

[1] --> FOAM FATAL ERROR:
[1] Supplied field size is not equal to source patch size
source patch = 311
target patch = 0
supplied field = 317

If you initialize the alpha field with an interface crossing a boundary, it crashes immediately with a similar error. I had thought that dynamic mesh and cyclicAMI could work together?

As a brute force workaround, I had thought perhaps that there is a way to stop refinement happening on the boundaries. There is something in dynamicRefineFvMesh which makes a cellSet called protectedCells but it does not seem that is intended for this particular purpose and simply creating in advance a cellSet of this name had no effect.

Incidentally, one workaround is to set up a cellSet for the cyclic patches and refineHexMesh these up to the maxRefinement level in dynamicMeshDict at the beginning before decomposing, then it will not be able to refine any more. The solver appears to discover on its own the cellLevel for the newly refined cells (though you must delete constant/polyMesh/refinementHistory or it throws an error--though only when running in parallel, in serial it just crashes with the 'Supplied field...' error if you don't remove this file), but oddly---and conveniently in this case---the cells are NOT automatically marked for unrefinement. This works, but wastes mesh on the boundaries.

The ideal solution would be changes which enable cyclicAMI patches to work with dynamicMesh. It appears that there is some issue with how the patches are refined and the fields interpolated on these patches that causes the crash.
Steps To ReproduceThe uploaded case is a slight modification to the damBreakWithObstacle tutorial in which the left and right sides have been set as cyclicAMI patches. Two scripts are included to show the behavior of the code. For the case where the patches are not refined (setupUniform) it crashes on the first refinement. When the cyclic patches are refined (setupRefined) it runs without issue. This only works because for some reason the refined cells are NOT automatically selected for unrefinement though one would actually expect them to be. Perhaps that is a bug which is truly an 'unintended feature' in this case.
TagsNo tags attached.
Attached Filesgz file icon damBreakWithObstacle.tar.gz [^] (4,145 bytes) 2014-03-12 20:27

- Relationships

-  Notes
(0003098)
andy (manager)
2014-05-30 15:04

Thanks for the report - fixed by commit 0fb2aba

- Issue History
Date Modified Username Field Change
2014-03-12 20:27 kwardle New Issue
2014-03-12 20:27 kwardle File Added: damBreakWithObstacle.tar.gz
2014-05-30 15:04 andy Note Added: 0003098
2014-05-30 15:04 andy Status new => resolved
2014-05-30 15:04 andy Fixed in Version => 2.3.x
2014-05-30 15:04 andy Resolution open => fixed
2014-05-30 15:04 andy Assigned To => andy