CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Programming & Development

GeometricField of a user defined class!

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   October 12, 2011, 15:16
Default GeometricField of a user defined class!
  #1
Senior Member
 
Hisham's Avatar
 
Hisham El Safti
Join Date: Apr 2011
Location: Braunschweig, Germany
Posts: 247
Blog Entries: 10
Rep Power: 8
Hisham is on a distinguished road
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:

Code:
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 is offline   Reply With Quote

Old   October 13, 2011, 02:45
Default
  #2
Senior Member
 
Tomislav Maric
Join Date: Mar 2009
Location: Darmstadt, Germany
Posts: 259
Blog Entries: 5
Rep Power: 11
tomislav_maric is on a distinguished road
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:

Code:
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

Quote:
Originally Posted by Hisham View Post
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:

Code:
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

Last edited by tomislav_maric; October 13, 2011 at 02:46. Reason: c++ grammar
tomislav_maric is offline   Reply With Quote

Old   October 13, 2011, 03:39
Default
  #3
Senior Member
 
Hisham's Avatar
 
Hisham El Safti
Join Date: Apr 2011
Location: Braunschweig, Germany
Posts: 247
Blog Entries: 10
Rep Power: 8
Hisham is on a distinguished road
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
Hisham is offline   Reply With Quote

Old   October 13, 2011, 04:34
Default
  #4
Senior Member
 
Tomislav Maric
Join Date: Mar 2009
Location: Darmstadt, Germany
Posts: 259
Blog Entries: 5
Rep Power: 11
tomislav_maric is on a distinguished road
Quote:
Originally Posted by Hisham View Post
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
tomislav_maric is offline   Reply With Quote

Old   October 13, 2011, 05:13
Default
  #5
Senior Member
 
Hisham's Avatar
 
Hisham El Safti
Join Date: Apr 2011
Location: Braunschweig, Germany
Posts: 247
Blog Entries: 10
Rep Power: 8
Hisham is on a distinguished road
Quote:
Originally Posted by tomislav_maric View Post

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.


Quote:
Originally Posted by tomislav_maric View Post
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)

Quote:
Originally Posted by tomislav_maric View Post
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 )

Quote:
Originally Posted by tomislav_maric View Post
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
Hisham is offline   Reply With Quote

Old   October 13, 2011, 06:20
Default
  #6
Senior Member
 
Tomislav Maric
Join Date: Mar 2009
Location: Darmstadt, Germany
Posts: 259
Blog Entries: 5
Rep Power: 11
tomislav_maric is on a distinguished road
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.
tomislav_maric is offline   Reply With Quote

Old   October 13, 2011, 06:41
Default
  #7
Senior Member
 
Hisham's Avatar
 
Hisham El Safti
Join Date: Apr 2011
Location: Braunschweig, Germany
Posts: 247
Blog Entries: 10
Rep Power: 8
Hisham is on a distinguished road
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

Gre
Hisham
Hisham is offline   Reply With Quote

Old   October 13, 2011, 07:13
Default
  #8
Senior Member
 
Tomislav Maric
Join Date: Mar 2009
Location: Darmstadt, Germany
Posts: 259
Blog Entries: 5
Rep Power: 11
tomislav_maric is on a distinguished road
Quote:
Originally Posted by Hisham View Post
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

Gre
Hisham
Hi Hisham,

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

Best regards,

Tomislav
tomislav_maric is offline   Reply With Quote

Reply

Tags
geometricfield, ioobject, ptraits, user defined class

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenFOAM static build on Cray XT5 asaijo OpenFOAM Installation 9 April 6, 2011 12:21
user defined turbulence model manuutin STAR-CD 5 October 14, 2009 05:29
Errors running allwmake in OpenFOAM141dev with WM_COMPILE_OPTION%3ddebug unoder OpenFOAM Installation 11 January 30, 2008 21:30
Gradient of a User defined Variable Ramadas CFX 2 August 21, 2007 09:19
User Defined Scalars - Returning Values Carlos V. FLUENT 0 April 19, 2006 18:18


All times are GMT -4. The time now is 02:49.