Feature evaluation check
Summary
Make sure that values of patchFields are consistent with internals. This is currently not enforced for 'local' field operations (e.g. multiplying two fields)
Resolved bugs (If applicable)
Details of new models (If applicable)
- switch to old behaviour
OptimisationSwitches
{
//- Enable enforced consistency of constraint bcs after 'local' operations.
// Default is on. Set to 0/false to revert to <v2306 behaviour
localConsistency 0;
}
- add checking for consistency:
DebugSwitches
{
volScalarField::Boundary 1;
volVectorField::Boundary 1;
volSphericalTensorField::Boundary 1;
volSymmTensorField::Boundary 1;
volTensorField::Boundary 1;
areaScalarField::Boundary 1;
areaVectorField::Boundary 1;
areaSphericalTensorField::Boundary 1;
areaSymmTensorField::Boundary 1;
areaTensorField::Boundary 1;
}
Risks
- indicator fields:
Some fields are in fact just indicators and are volScalarFields only for convenience. E.g. one such field is the one returned by the
sign
function. It might easily evaluate to 0 if the coupled cells on either side have different signed values. In general this is not a problem since boundary values of indicator fields are not used but if e.g. the sign result is used to divide it might give problems. The solution is to have the indicator field as aDimensionedField
instead so there are no boundary conditions. - geometry fields:
on boundary faces the value is the actual face geometry (e.g. for mesh.C() the boundary values are the face-centres) and not the interpolate of the neighbouring cell geometry. Hence these values are not consistent with the constraints from e.g.
cyclic
. Workarounds:- recognise 'Sliced' (boundary conditions on mesh.C()) to avoid interpolation. However any operation on mesh.C() reverts back to the underlying constraint type so looses the 'sliced' type.
- store bit on GeometricField (like oriented()) to keep track of not needing to apply constraints after any local operation