[pbryant]

I converted the dam break tutorial to an axi-symmetric problem and got virtually the same result as with the unmodified version. So either I did something wrong or else there is a serious problem with the way that the 2D axi-symmetric cases are being processed.

More specifically, dam break is part of the tutorial for interFoam for processing two incompressible fluid phases, in this case water and air. I modified the geometry by rotating about the y axis so that the water is now initially in a cylindrical shape and is allowed to flow out radially. (So it might now be more accurately described as "tank break".) The radial flow will quickly disperse the water so that it will be a much thinner layer when it hits the outer wall than in the standard case. But this does not occur in the simulation. Further, the log file shows that the volume fraction for the water varies drastically over time from the initial value of 0.0289 to as high as 0.127. This might suggest a problem with the processing of the continuity equation for the axi-symmetric case.

I created a wedge straddling the x-y plane with the axis of symmetry being the y axis. In BlockMeshDict I replaced the vertices with the following slightly modified set to produce a wedge angle of +- 0.01 rad:

vertices
(
(1e-2 0 -1e-4)
(2 0 -2e-2)
(2.16438 0 -2.16438e-2)
(4 0 -4e-2)
(1e-2 0.32876 -1e-4)
(2 0.32876 -2e-2)
(2.16438 0.32876 -2.16438e-2)
(4 0.32876 -4e-2)
(1e-2 4 -1e-4)
(2 4 -2e-2)
(2.16438 4 -2.16438e-2)
(4 4 -4e-2)
(1e-2 0 1e-4)
(2 0 2e-2)
(2.16438 0 2.16438e-2)
(4 0 4e-2)
(1e-2 0.32876 1e-4)
(2 0.32876 2e-2)
(2.16438 0.32876 2.16438e-2)
(4 0.32876 4e-2)
(1e-2 4 1e-4)
(2 4 2e-2)
(2.16438 4 2.16438e-2)
(4 4 4e-2)
);

Note that I clipped 0.01 off of the sharp edge of the wedge so that there is still a left wall as before, though now too narrow to have any real effect on the dynamics.

I also added the following patches in that file

wedge side1
(
(4 5 1 0)
(12 13 17 16)
)
wedge side2
(
(6 7 3 2)
(14 15 19 18)
)
wedge side3
(
(8 9 5 4)
(16 17 21 20)
)
wedge side4
(
(9 10 6 5)
(17 18 22 21)
)
wedge side5
(
(10 11 7 6)
(18 19 23 22)
)

To the files alpha1, alpha1.org, p_rgh, and U I added the following boundary fields:

side1
{
type wedge;
}

side2
{
type wedge;
}

side3
{
type wedge;
}

side4
{
type wedge;
}

side5
{
type wedge;
}

I also deleted the boundary file and then processed with blockMesh, setFields, and interFoam | tee log1. It seemed to run normally but produced the wrong result as I described.

I also tried for comparison to replace all occurrences of "wedge" in the above files with "cyclic". This seemed to work and produce a sensible result, but perhaps it will require a longer run time than the true 2D method if that was working properly. It is also unclear whether cyclic is intended to work with a single cell thickness.

Other things I tried: Using a single sharp wedge block with 6 vertices and using the z axis as the symmetry axis.

I would greatly appreciate any help in figuring out what the problem is and/or fixing the bug if there is one.

Thanks - Paul

[pbryant]

Apparently the software will run even if the wedges patches have not been properly identified and paired up by the software. Running checkMesh detects a problem (pointed out by Henry). Grouping the 10 wedges for this case into back and front categories seems to work and fixes the problem. I had previously had them grouped into 5 matching pairs. That approach works when using cyclic patches instead of wedge patches. It would be good if the software would not run if the wedge patches have not been properly paired up.