cyclicAMI and interDyMFoam for periodic box

kwardle · March 6, 2014, 16:38

Hi All,
I am using interDyMFoam (2.3.x) for the first time in conjunction with cyclicAMI boundaries to try to simulate the flow in a periodic box (cyclicAMI patch pairs on each side). If I 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 I 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, perhaps I have set up something incorrectly? As a brute force alternative, is there a way to stop refinement happening on the boundaries?
Thanks!
-Kent

kwardle · March 11, 2014, 14:40

For anyone who is curious, I still haven't completely sorted this out but I did find one workaround. If you make a cellSet for the boundary cells and refineHexMesh on this up to the maxRefinement level in dynamicMeshDict at the beginning before decomposing, then it will not be able to refine any more. It 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), but oddly---and conveniently in this case---the cells are NOT automatically marked for unrefinement. This works, but wastes mesh on the boundaries. Still trying to to sort out and document what is happening and plan to submit a bug once I do. There is something in dynamicRefineFvMesh which makes a cellSet called protectedCells--before looking at the code itself, I had thought perhaps I could just make this set on my own and it would read it in and not refine those cells, but that does not seem to be how it works.

March 6, 2014, 16:38	cyclicAMI and interDyMFoam for periodic box	#1
kwardle Senior Member Kent Wardle Join Date: Mar 2009 Location: Illinois, USA Posts: 219 Rep Power: 21	Hi All, I am using interDyMFoam (2.3.x) for the first time in conjunction with cyclicAMI boundaries to try to simulate the flow in a periodic box (cyclicAMI patch pairs on each side). If I 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 I 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, perhaps I have set up something incorrectly? As a brute force alternative, is there a way to stop refinement happening on the boundaries? Thanks! -Kent

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
AMI interDyMFoam for mixer	danny123	OpenFOAM Running, Solving & CFD	4	June 19, 2013 05:49
Problem with inconsistent patches (AMI, interDyMFoam)	jrrygg	OpenFOAM Running, Solving & CFD	3	February 1, 2013 04:23
pimpleDyMFoam VS interDyMFoam.	sharonyue	OpenFOAM Running, Solving & CFD	0	January 21, 2013 05:31

March 11, 2014, 14:40		#2
kwardle Senior Member Kent Wardle Join Date: Mar 2009 Location: Illinois, USA Posts: 219 Rep Power: 21	For anyone who is curious, I still haven't completely sorted this out but I did find one workaround. If you make a cellSet for the boundary cells and refineHexMesh on this up to the maxRefinement level in dynamicMeshDict at the beginning before decomposing, then it will not be able to refine any more. It 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), but oddly---and conveniently in this case---the cells are NOT automatically marked for unrefinement. This works, but wastes mesh on the boundaries. Still trying to to sort out and document what is happening and plan to submit a bug once I do. There is something in dynamicRefineFvMesh which makes a cellSet called protectedCells--before looking at the code itself, I had thought perhaps I could just make this set on my own and it would read it in and not refine those cells, but that does not seem to be how it works.