I understand how to add public
 

I understand how to add public members functions to classes already implemented in OP. But, I need to add the declaration in H. and I can not add my own code to the original source code but to do totally independent. It is possible to add member functions outside the original class declaration ?

Thanks

Hi Sergio! Yep. C++ has a m
 

Hi Sergio!

Yep. C++ has a mechanism for that: it's called inheritance.

You create a new class that is derived from the original class and add/modify all the functionality you require.

Bernhard

Hi, Thanks. Yes, I know that.
 

Hi, Thanks.
Yes, I know that.
What I want to do is to modify an already implemented class (i.e. LES Model) to add an extra virtual member function and define it on one of the derived class. But, all these not into the original definition and implementation of LES model. H or LES Model.c, but on an independent file structure. This is useful for geting use made code without touching any bit of the original.

Hi Sergio! Sorry for sugges
 

Hi Sergio!

Sorry for suggesting you didn't know basic C++.

Still: what you are suggesting would suggest the very idea of data encapsulation (apart from technical problems) because your new methods could access for instance private variables of the original class. Don't get me wrong: I don't have a problem with subversion. C++ has ;)

My suggestion would be: make your own copy of the OF-installation (call it for instance: OpenFOAM-1.4.1-sergio). Do the modifications you're intending there and try them. Once they're working you can wonder about the technicalities of making them compatible with a vanilla OF-installation.

The other way would be generating a subclass of the original turbulence model that would contain a pointer to a turbulence model which it would dynamically create at construction time (from a parameter). All calls to methods of that class would be delegated to the pointer except the ones you're modifying (plus the methods you're adding). The problem is that I don't know the turbulence classes that well to tell whether this is feasable (there might be necessary constructors missing from the original class .... etc). So stick with the first approach and worry about the technicalities later.

Bernhard

PS: this is about adding switchable wall-functions, is it?

Hi Bernghard, Thanks. You ar
 

Hi Bernghard,
Thanks.
You are right. I dont know c++, I just struggle with it and beat it now and then!
OK.

I know that the variations works because I tried them in the original files before.

It is simply to pass an scalar field to solve the transport equation for k in a slightly different way as OP does. I need to change a bit the solution for k (turbulent intensity).

The classes are: LES Models.H (abstract) <----- SGS Eddy Vis(k) <---KEq.H (this solve k)

I need to add a member to KEq.H, I can do it in other file (Keq_sergio.c) but I need to modify KEq.H for the interface. The same applies to LES Models.H, where I have to add the virtual function. This is the point I dont want to change LES Models.H and Keq.H in the OF original folder but just to "add" functionallity.

The seconf way you mentioned is when C++ beat me.
What is it a sub-class, is it a derived class or a class inside a class?

I am in charged of the research at Kingston University, London, and I am setting the way for the PhD students to work well with OP, in a way to develope the models 100% independenly of the original source code (this means without touching it at all). This will help to compatibility in the future for our group.

Thanks
very much
Sergio

Dear Sergio, What i underst
 

Dear Sergio,

What i understood from this conversation is that the priority for you is to keep the original source code of OF untouched. In this case, i think, the only solution is the second suggestion by Bernhard. Create a derived class from the original turbulence model and define your new method here. Then, later, when you refer to this method (function) in your solver code, refer to the derivedClass.method() or derivedClass->method(). For the unmodified methods, refer to parentClass.method() or parentClass->method(). This is not as elegant as refering to the virtual method of parent class, but for me it is the only way how to avoid the implementation of virtual method to the existing parent class.

Anyone, please correct me if i'm wrong.

David

I was thinking of a delegation
 

I was thinking of a delegation. Not exaktly like the examples in http://en.wikipedia.org/wiki/Delegation_(programming)

This is just a sketch:

class SergioTurbClass : public OrigTurbClass {
OrigTurbClass *orig;
public:
virtual void sergiosMethod()=0;
void delegatedVirtualMethod() {orig->delegatedVirtualMethod(); }
void modifiedVirtualMethod() {
this->sergiosMethod(); orig->modifiedVirtualMethod();
}
};

The problem with this approach (still havn't looked at the turbulence hierarchy) is that there is some data in the base class and with that approach it would be duplicated (once by inheritance, once by the object orig refers to). Keeping that in sync might be painful

Bernhard

David and Bernhard, thanks fo
 

David and Bernhard,
thanks for your help. I will try both approaches and tell you later. Although, I though that it was going to be easier.I believed that the object oriented concept permited to leave untouch and and extra functionality externally.
I think that David's idea is problably simpler tov understand and implement and as I am looking for some rule to follow it looks neater. Even when you need to modify the main code and check that it does all what the original method did.

I will be in contact short.

Thanks very much
Sergio

Another alternative. Create a
 

Another alternative. Create a new user library called say sergioLib. Add the modified turbulence model to this library under a new name - e.g. newkModel. Pull the new library into your applications via the controlDict functionality - libs ("libsergioLib.so").

Hi, Following the discussion
 

Hi,
Following the discussion about extending a class functionality I derived a class from the one I wanted to extend the functions and re-implemented the same virtual class but with extra parameters. In this way, I don't change the interface of the virtual base class. What I am expecting is that when I call the member function from the base it should realised that it is the modified version (the one in the derived class) and not the original. For this I created an extra member function to set the value of the extra parameter which will be used by the modified member.

Do you think it might work?

Other problem I had is an unexpected error in the constructor of the derived class.

This is the constractor with a base class oneEqEddy from where I derived oneEqEddyKU.
I followed the same sintaxis as in other occasions but it does not compile so far.


oneEqEddyKU::oneEqEddyKU
(
const volScalarField& rho,
const volVectorField& U,
const surfaceScalarField& phi,
const basicThermo& thermoPhysicalModel
)
:
LESmodel(typeName, rho, U, phi, thermoPhysicalModel),
oneEqEddy(rho, U, phi, thermoPhysicalModel),

ck_(LESmodelProperties().lookup("ck"))
{}