Virtual inheritance problem while adding public member function to LES SGS Model
 

Dear Foamers,

I have a really strange programming issue concerning virtual inheritance.

What I want to do:

• Add a member function to the LES SGS Model I implemented, so that I can access a certain field in my actual solver

What I basically did to achieve this goal:

• Added a virtual function to the header of compressible::turbulenceModel by appending it to the end of the rest of the functions in the header file:

virtual tmp<volScalarField> myCoolFunction() const = 0;

• Added the corresponding function to my LES SGS Model header file and implementation file

virtual tmp<volScalarField> myCoolFunction(); // header

tmp<volScalarField> myCoolFunction() // implementation file
{
return myCoolvolScalarField_;
}

My code compiles and seems to make sense from a programming point of view, if I got virtual inheritance correctly.

However: When I call my new function with turbulence->myCoolFunction() in my solver code, I do not get myCoolvolScalarField_. Interestingly, what happens instead is that some random(?) other function from compressible:turbulenceModel gets called (e.g. printing some LES SGS model coefficients).
By changing the order of the functions in the compressible:turbulenceModel header file, I can influence, which function from compressible::turbulenceModel gets called (so it is not that random at all), which means that the order of functions header file seems to matter! This is weird and doesn't make sense!

Anyhow, I can't call my function, also after having done some fancy reordering.

After a long while of googling without any useful results, I found that the construction of the virtual tables for the involved classes can produce the behavior I experienced, caused by peculiarities of some compilers. I run OpenSuse 12.1 and my compiler is gcc 4.6.2. I still use OpenFOAM 2.1.1.

What I would like to know is:

• whether I made a programming mistake
• if there is a related bug, potentially caused by the combination of my OF version and the compiler
• if anyone had similar experiences

I would be very happy about any advice or hint!

Cheers,

Konrad

Update
 

I also tried to trick the virtual function table and added a couple of other dummy functions and put my actual function in between. Unfortunately, without success.

Furthermore, I added some dummy function input parameter (e.g. bool dummy), with the same idea in mind, again without success.

This is really weird and doesn't make any sense to me.

Good evening,

I suppose that myCoolVolScalarField is a volScalarField, so why do you return it as a tmp<volScalarField>?

Try do the following instead (using a reference):

Of course, you can remove any of the "const", which do not suite your needs.

Kind regards

Niels

Thanks ngj,

I basically followed the function declaration of the other standard return function, e.g:

virtual tmp<volScalarField> alphaEff() const = 0;

.. which is why I return a tmp<volScalarField>


I tried your solution, unfortunately, it does not solve my problem. I still get the same behavior (call of some other function in turbulenceModel).

Thanks, anyway!

Solved
 

I solved the problem:

It wasn't a programming issue, but basically a conflict between parts of our OpenFOAM being compiled on a server with a slighty different architecture. My locally compiled solver and libraries accessed libraries from the server, which is the root cause for my problem.

By compiling a local version on my machine, I got a consistently compiled OpenFOAM, and my weird error is gone.

Lesson learned: Either keep your architecture PC<-->server the same or compile everything on the machine, where you want to run your code.