setExprFields with surfaceScalarFields

Hi,

I have been trying to create surfaceScalarFields from setExprFields.

This utility needs a flag for the oriented keyword (at least I recognize the dot product with the surface area vector and include the oriented keyword).

This will cause problems in multiprocessor calculations as the values seem to be wrong when the oriented keyword is not present.

Tested on OpenFoam: v2212 with pitzDaily tutorial.

If more information is required, please let me know.

Best Regards

changed the description

changed the description

What is your simple test case? ie, an example input dictionary...

made the issue visible to everyone

Hello Mr. Olesen,

Thanks for the reply.

I have attached a test case:

Steps to reproduce:

blockMesh

setExprField

simpleFoam  

The time step continuity errors are: time step continuity errors : sum local = 0.122440603503, global = 0.0185896674189, cumulative = 0.0185896674189

rm -r 1     # Remove the time directory
decomposePar 
mpirun -np 2 simpleFoam -parallel

time step continuity errors : sum local = 0.152353476633, global = -0.0172348480873, cumulative = -0.0172348480873

Edit the phi file in 0/ folder and place

oriented oriented;

rm -rf processor*
decomposePar 
mpirun -np 2 simpleFoam -parallel

time step continuity errors : sum local = 0.152424537135, global = -0.0172539915384, cumulative = -0.0172539915384

The continuity errors are different, so the oriented keyword plays a role somewhere in the calculation

pitzDaily_setExprFields.zip

This is interesting. I'm running with a clang-15 and don't even get that far. Mine segfaults within setExprFields

#1  Foam::sigFpe::sigHandler(int) in .../platforms/linux64Clang150DPInt32Opt/lib/libOpenFOAM.so
#2  ? in /lib64/libpthread.so.0
#3  void Foam::dot<Foam::fvsPatchField, Foam::fvsPatchField, Foam::Vector<double>, Foam::Vector<double> >(Foam::FieldField<Foam::fvsPatchField, Foam::innerProduct<Foam::Vector<double>, Foam::Vector<double> >::type>&, Foam::FieldField<Foam::fvsPatchField, Foam::Vector<double> > const&, Foam::FieldField<Foam::fvsPatchField, Foam::Vector<double> > const&) in .../platforms/linux64Clang150DPInt32Opt/lib/libfiniteVolume.so

I have gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

My setExprFields

Create time

Create mesh for time = 0


Time = 0
Set new field: phi time=0
Expression:
>>>>

            vector(fpos().x(), fpos().y(), fpos().z()) & Sf

<<<<

Dispatch ... surfaceScalarField
setField(phi): surfaceScalarField
Set all 24170 values
Setting dimensions to [0 3 -1 0 0 0 0]
Writing to phi

I will also attach the resulting phi (to replicate the rest of the observations)

phi

Hello Mr. Olesen,

Where you able to replicate my results given the phifile?

added community label

@kuti given that Mr.Olesen is not able to run the setExprFields with clang-15. Do you have a different compiler? Do you get the same error?

Did I code something wrong? Or this is a potential bug in the setExprFields utility?

Hi @theBananaTrick - I really haven't had any time free to look at this. There definitely is something wrong going on (within the code). However, I'm also afraid to say that the surfaceField aspects of expressions may still be quite lacking.

Here is some background
For discussion purposes, I'll explain in terms of volume fields (eg, volScalarField).

Internally, when a new field is defined within expression fields, it actually works by defining the internal field (eg, the cell values) with an initial value (eg, zero) and the boundaries are all treated as zero-gradient and uses correctBoundaryConditions() to the propagate the field value to the boundaries so that everything is consistent. In part it done like that to handle all sorts of do-it-yourself bits within the expressions. For example, the (condition ? a : b) expression. This bypasses a huge chunk of the regular OpenFOAM fields functions, which also means that boundaries are extremely difficult to get done properly, which is why the zero-gradient approach is used.

For surfaceField types (like phi), there is not a clean way to handle things in the same way. The zero-gradient and correctBoundaryConditions() (eg to push cell values to the boundaries) do not exist. This means there is a real possibility that the boundary parts of the surfaceFields (when used with expressions) are either not properly initialize, or not entirely done correctly.

With my particular compiler (clang), the failure occurs very early on. With yours, it seems to occur later. In either case, it is definitely an issue. However, since this problem doesn't seem to have been triggered very frequently, and I currently have extremely limited time to examine more closely, I think you will have to look for some other workarounds for now. Perhaps next year, you (or someone else) will find it to be a priority and then we can get some time and resources allocated for it.