CFD Online Discussion Forums - Porting foundation->ESI: "‘area’ is not a member of ‘Foam::face’"

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Programming & Development (https://www.cfd-online.com/Forums/openfoam-programming-development/)

- - Porting foundation->ESI: "‘area’ is not a member of ‘Foam::face’" (https://www.cfd-online.com/Forums/openfoam-programming-development/235771-porting-foundation-esi-area-not-member-foam-face.html)

Porting foundation->ESI: "‘area’ is not a member of ‘Foam::face’"

I'm trying to port some code from the OpenFOAM-Dev github repository to work with my ESI installation.

Upon running wmake it's thrown two errors - one was easily fixed by substituting "vSmall" for "VSMALL", which I did by comparing equivalent files and noticing that the only difference was the capitalisation. Unfortunately the other error seems to be less easily fixed. It's complaining about the following:

Code:

MPLIC/MPLICfaceI.H: In member function ‘const vector Foam::MPLICface::Sf() const’:

MPLIC/MPLICfaceI.H:117:18: error: ‘area’ is not a member of ‘Foam::face’

     return face::area(subPoints_);

                  ^~~~

Have had a rummage in the source, it looks to me that what it needs is defined in src/OpenFOAM/meshes/meshShapes/face/face.C. Comparing the two forks versions of this file it looks like ESI have a "areaNormal" in an equivalent place in the file to foundations "area"; I don't understand the full workings, but comparing to other surrounding functions it initially looks equivalent.

Unfortunately my optimistic 'swap them over' didn't work - it produces this error:

Code:

MPLIC/MPLICfaceI.H:117:39: error: cannot call member function ‘Foam::vector Foam::face::areaNormal(const Foam::UList<Foam::Vector<double> >&) const’ without object

     return face::areaNormal(subPoints_);

                                       ^

My C++ isn't great, but it seems that these are actually not equivalent functions. Does anyone know if this is a simple case of substituting one thing for another, or do the incompatibilities between forks actually run much deeper here?

Thanks,
Mike

I've been doing some further digging, and it looks like there are two different area() functions in the foundation version of face.H - one static and one member. It seems that actually it's the static one that the MPLICfaceI code is trying to use; unfortunately the ESI version of face.H doesn't really have anything in terms of static functions. This would (I think) fit with the second error in my post above, in that it falls-back to a member function when the context only works with a static one.

It's unclear to me why only the foundation fork has the static one, and if a simple change can make the MPLIC code use the member one instead of the static. I could of course also be barking up the wrong tree and it's actually using the member one anyway and I've screwed something else up...

A quick look at the ESI code and this comment pops up :

Code:

//- The area normal - with magnitude equal to area of face

So you could presumably do something like :

Code:

return mag(face::areaNormal(subPoints_))

Note that I've not tested this, and guessing from the comment... it looks like a bit more work might be necessary to make use of that function, as you've noted, but the ::area functionality looks like it could be replicated. Given that you're using an ESI variant (although we don't know the version), though, why not just use isoAdvector (i.e., interIsoFoam, where plicRDF is available as a reconstructionScheme)? That seems to be what the MPLIC code is going for.

Caelan

If you already have a face, just use its mag() method

https://develop.openfoam.com/Develop...ce/face.H#L221