View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001218 | OpenFOAM | Bug | public | 2014-03-12 20:27 | 2014-05-30 16:04 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Ubuntu 12.04 LTS | OS Version | (please specify) |
| Summary | 0001218: Crash on use of cyclicAMI with interDyMFoam | ||||
| Description | When 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 Reproduce | The 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. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-03-12 20:27 |
|
New Issue | |
| 2014-03-12 20:27 |
|
File Added: damBreakWithObstacle.tar.gz | |
| 2014-05-30 16:04 |
|
Note Added: 0003098 | |
| 2014-05-30 16:04 |
|
Status | new => resolved |
| 2014-05-30 16:04 |
|
Fixed in Version | => 2.3.x |
| 2014-05-30 16:04 |
|
Resolution | open => fixed |
| 2014-05-30 16:04 |
|
Assigned To | => user2 |
