[Hisham]

Hi Foamers,

Is it possible to declare a GeometricField of an object derived from a user defined class? I tried but got errors with regard to pTraits. I used the following for declaration:

GeometricField <myClassName, fvPatchField, fvMesh > myField
(
     IOobject
     (
        "myField"
         runTime.timeName(),
         mesh,
         IOobject::NO_READ,
         IOobject::NO_WRITE
       ),
       mesh,
       myClassName
);

It seems that objects of the user defined class cannot be, of course, initialized in pTraits. Is there a work around? I would like to know?

Regards
Hisham

[tomislav_maric]

The pTraits are traits classes for primitives in OpenFOAM. Tratis carry additional information about the type (class) which is not provided in the public interface of the type. This makes it easier to write generic algorithms that operate on containers, and need information on the templated type of the container.

Trait classes are used in c++ (among other things) to extend the information related to the built in types such as a float, or a double, so that this information may be used by a generic algorithm. A good example of this (and an interesting example of using macros for metaprogramming) is the scalar primitive, where the macros are used to metaprogram the partial specialization of the primitive traits (read: characteristics classes for primitive types in OpenFOAM), based on the chosen precision.

What this all means for you is that you need to write a partial specialization of the pTraits for your primitiveClass, in the same manor it has been done for other primitives.

If you want to specialize your type:

template<>
class pTraits<class myClass>
{
   public:
         // Appropriate public typedefs such as cmptType, etc. 
         // Look into the Scalar.H and see how the partial specialization is 
        // done for the Scalar, and do the same for your type. 
}

Without pTraits, the algorithms working on Field<T>, thus GeometricField<Type...> will not know about the properties of elements.

Just out of curiosity: are the numerous primitives not enough for you? What is the motivation behind this?

Hope this helps,
Tomislav

Originally Posted by Hisham

Hi Foamers,

Is it possible to declare a GeometricField of an object derived from a user defined class? I tried but got errors with regard to pTraits. I used the following for declaration:

GeometricField <myClassName, fvPatchField, fvMesh > myField
(
     IOobject
     (
        "myField"
         runTime.timeName(),
         mesh,
         IOobject::NO_READ,
         IOobject::NO_WRITE
       ),
       mesh,
       myClassName
);

It seems that objects of the user defined class cannot be, of course, initialized in pTraits. Is there a work around? I would like to know?

Regards
Hisham

[Hisham]

Hi Tomislav,

In my solid model (multisurface plasticity), there are some calculations that need to be done individually and explicitly for each cell with a lot of thresholds, and results of which need to be stored for next time steps. Therefore, I thought it would be better to encapsulate these calculations and data in objects.
I was trying to compare between having a field of objects or just an array of them. Looking at it now, it seems that it is better be an array of pointers because I will be using different types of classes that inherit a base class.

Nevertheless, I am so glad that I got an answer for my question.

With regards to primitive types: Yes I would surely like a 4th order tensor to be around as it can be conveniently used in solid dynamics.

Thanks a lot
Hisham

[tomislav_maric]

Originally Posted by Hisham

Hi Tomislav,

In my solid model (multisurface plasticity), there are some calculations that need to be done individually and explicitly for each cell with a lot of thresholds, and results of which need to be stored for next time steps. Therefore, I thought it would be better to encapsulate these calculations and data in objects.
I was trying to compare between having a field of objects or just an array of them. Looking at it now, it seems that it is better be an array of pointers because I will be using different types of classes that inherit a base class.

Nevertheless, I am so glad that I got an answer for my question.

With regards to primitive types: Yes I would surely like a 4th order tensor to be around as it can be conveniently used in solid dynamics.

Thanks a lot
Hisham

Hi Hisham,

thanks for the info on the background!

First of all, I would recommend not using arrays of pointers, or other kind of built in types, simply because this is discouraged in general when one works in C++.

If your values are mapped to cells, and especially if they relate to the domain boundaries, the GeometricField is definitely a good choice.

"
Looking at it now, it seems that it is better be an array of pointers because I will be using different types of classes that inherit a base class."

Does this mean that on a cell level, you need to store different objects (type-wise)? In this case, you can just have multple geometric fields defined by the different types that you store in each cell. If you need 4 scalar and a tensor value in every cell, why don't you just create 4 volScalarFields and one volTensorField?

Are the thresholds that you need to store special in any kind of way, when compared to those available?

Of course, these are just my first thoughts, so I may be way off.

Best regards,
Tomislav

[Hisham]

Originally Posted by tomislav_maric

If your values are mapped to cells, and especially if they relate to the domain boundaries, the GeometricField is definitely a good choice.

I think the GeometricField will be excellent if I don't have to manipulate original FOAM code to implement my class.

Originally Posted by tomislav_maric

Does this mean that on a cell level, you need to store different objects (type-wise)? In this case, you can just have multple geometric fields defined by the different types that you store in each cell.

Yes! I need to be able to define various material models (classes) for different regions. Nevertheless, they all have a mother abstract class (at least that is my current plan)

Originally Posted by tomislav_maric

If you need 4 scalar and a tensor value in every cell, why don't you just create 4 volScalarFields and one volTensorField?

Actually, I thought of that as well and it is not a bad idea. It will just hinder generalization (so keeping it as a backup )

Originally Posted by tomislav_maric

Are the thresholds that you need to store special in any kind of way, when compared to those available?

In a way! Because the number of thresholds is arbitrary (= number of yield surfaces for a region or zero for elastic regions)

I am also considering coding a collection class. I need to investigate the topic more from a C++ point of view!

Best regards,
Hisham

[tomislav_maric]

Hi Hisham,

if you are implementing a model, this means that you will introduce a mutual explicit dependance between the variables (fields) that you are solving for? I have no clue about your field, so forgive me for asking stupid questions, or simply stating something obviously wrong (for you at least)..

If this is the case, you can model your design based on the existing models in OpenFOAM, for instance the viscosity models, or turbulence models. When such classes introduce functional relationship between dependant variables in some way, they must have access to those variables as well (usually via the object registry).

What does this mean for your problem? Well, if this is the case, you just need a model structure that is similar to the one present for the existing models in OF (of course, an abstract class if the derived classes share an interface, etc), and additional data which is registered in the object registry and accessible by the model (with standard fields and primitives this is not a problem, if you need rank 4 tensor its a bit more work). This is the way I would choose to go. More standard fields, and a functionality on top driven by the models.

Best regards,
Tomislav

P.S. Never stop looking into C++. Ever.

[Hisham]

Hi Tomislav,

Thanks a lot! That is really helpful. I will investigate copying from turbulence models. I will keep you informed here if you don't mind some inconvenience

Grüße
Hisham

[tomislav_maric]

Originally Posted by Hisham

Hi Tomislav,

Thanks a lot! That is really helpful. I will investigate copying from turbulence models. I will keep you informed here if you don't mind some inconvenience

Grüße
Hisham

Hi Hisham,

it's not an inconvenience at all, I'm learning stuff as well, and that's always fun!

Best regards,

Tomislav