wmake error when compiling my own boundary condition

[gregnordin]

Thank you so much for making this project available! I have come across the following issue:

I just brew installed openfoam2206, started it up, and tried to use wmake to compile my own boundary condition (which compiles fine when I use your openfoam-docker-arm docker image--thanks for that project too!) and got this error:

warning: overriding currently unsupported use of floating point exceptions on this target [-Wunsupported-floating-point-opt]
approxPoiseuilleRectFvPatchVectorField.C:139:17: error: conversion from 'tmp<Field<double>>' to 'Foam::scalarField' (aka 'Field<double>') is ambiguous
    scalarField ycoord = 2 * ((c - ctr) & y_) / ((bb.max() - bb.min()) & y_);
                ^        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
/Volumes/OpenFOAM-v2206/src/OpenFOAM/lnInclude/tmp.H:270:9: note: candidate function
        operator const T&() const { return cref(); }
        ^
/Volumes/OpenFOAM-v2206/src/OpenFOAM/lnInclude/Field.H:232:16: note: candidate constructor
        inline Field(const tmp<Field<Type>>& tfld);
               ^

It looks like there is a problem trying to create a variable of type scalarField (ycoord), which is necessary for my boundary condition. For some reason the variable type is not being accepted (compiler flag issue?). Is there a way to get this to work? By the way, the same error occurs with openfoam2112, which I also brew installed.

Also, I have the latest XCode version (13.4.1), command line tools, and system software (macOS Monterey 12.5.1) installed on my MacBook Pro M1 Max.

[gerlero]

This looks like a case of different compilers having slightly different behaviors: Clang (the system compiler on macOS) is refusing to compile the code because it finds an ambiguity when applying the required type conversions, while GCC (the default compiler on Linux, including Docker) does not see the same code as ambiguous.

In this case, initializing ycoord using braces or parentheses instead of an equals sign should fix the ambiguity for Clang, and thus should work with both compilers. E.g.:

scalarField ycoord {2 * ((c - ctr) & y_) / ((bb.max() - bb.min()) & y_)};

[gregnordin]

I just tried your fix, and it now compiles and the boundary condition runs as expected.

I also tried replacing scalarField with tmp<Field<double>> in the code before I saw your comment, and that also compiled and ran just fine, but I understand that would not be a preferred approach because it doesn't make use of the normal Openfoam type.

Thank you so much!

[gerlero]

You're welcome.

I also tried replacing scalarField with tmp<Field> in the code before I saw your comment, and that also compiled and ran just fine, but I understand that would not be a preferred approach because it doesn't make use of the normal Openfoam type.

tmp objects are tricky... they might work in your particular case, but switching to tmp-typed variables in the general case can easily lead to crashes. They have their uses, but they require knowing your code and knowing where it's safe to use them.

[gregnordin]

While my first college programming class used punch cards and I have done a lot of programming over the course of my academic career, I haven't done much with C++ so I'm still a newbie when it comes to anything beyond just surface issues. I therefore really appreciate your comments and suggestions, especially since Openfoam is such a well-developed software system that makes intensive use of C++ features, and is therefore somewhat daunting to dive into. 😄

[meteozond]

JFYI HiSA contributor shows another approach - "changed from initialiser assignment to copy construction"

https://gitlab.com/hisa/hisa/-/merge_requests/3/diffs

[gerlero]

JFYI HiSA contributor shows another approach - "changed from initialiser assignment to copy construction"

https://gitlab.com/hisa/hisa/-/merge_requests/3/diffs

It's just the equals sign that you don't want there (FWIW the equals sign does "copy initialization" instead of "direct initialization", which has different semantics). Braces vs. parentheses is a different discussion and mostly (although not always!) a matter of the project's style. More details here.