Failure of cuttingPlane sampled surface with "point" isoMethod due to the way the SlicedPatchField constructor is used in SlicedGeometricField::makeBoundary function

Summary

Using a cuttingPlane sampled surface with isoMethod point; will cause an "out of range" error when run with WM_COMPILE_OPTION=Debug in v2306. Thus possibly causing a WM_COMPILE_OPTION=Opt case to fail with a segmentation fault or floating point error. The problem appears to be caused by code change in v2206.

Steps to reproduce

Take the simpleFoam/pitzDaily tutorial for v2306
Replace the streamline functions by a single cuttingPlane function, such as

   planes
   {
       type            surfaces;
       libs            (sampling);
       writeControl    writeTime;
       fields          (p U);
       surfaceFormat    vtk;
       interpolationScheme cellPoint;
       surfaces
       {
           planeZ
           {
               type            cuttingPlane;
               interpolate     true;
               isoMethod point;
               point (0 0 0);
               normal (0 0 1);
           }
       }
   }

Run the case in v2306 with WM_COMPILE_OPTION=Debug.
The case will abort with a start 24170 out of range [0,30] error.

(Please note that this case will run without a reported error when using WM_COMPILE_OPTION=Opt with my compilation)

Example case

As described above.

What is the current bug behaviour?

Out of range error

What is the expected correct behavior?

No out of range error!

Relevant logs and/or images

Environment information

OpenFOAM version : v2206|v2212|v2306|v2312
Operating system : Linux Centos 6
Hardware info : x86_64
Compiler : gcc 8.5

The error was discovered and fix tested in v2306, but it is thought to be an issue in all versions since v2206 including v2312.

Possible fixes

In v2206 there was a change in the second SlicedGeometricField::slicedBoundaryField function (In v2306 this function is called SlicedGeometricField::makeBoundary where the problem is at around lines 176-181 in SlicedGeometricField.C). Reverting this to the form in earlier versions removes the issue. i.e. replacing

           // Create unallocated copy of patch field
           bf.set
           (
               patchi,
               new SlicedPatchField<Type>
               (
                   p,
                   DimensionedField<Type, GeoMesh>::null(),
                   bField[patchi]
               )
           );

with

            // Create unallocated copy of patch field
            bf.set
            (
                patchi,
                new SlicedPatchField<Type>
                (
                    p,
                    DimensionedField<Type, GeoMesh>::null()
                )
            );
            bf[patchi].UList<Type>::shallowCopy(bField[patchi]);
        }

causes the test case described above to run without error in Debug mode.

On viewing the SlicedPatchField constructor called in this extract of the v2306 code, by default it appears to be expecting a complete field for which it shallow copies a patchSlice. However the supplied field is already in the form of a patch field, so it only needs to take a shallow copy as done outside the constructor in the older code.

Admin message