Kratos: Accessors for Property-contents manipulation

[philbucher]

Start of the discussion was in #1645

In a nutshell: We would like a mechanism with which the properties can give intepolated values (e.g. from tables).

This week we were discussing this with @RiccardoRossi @jcotela and @armingeiser and now the idea is the following:
We define an object Accessor that can do data manipulation. It is in the property, same as the ConstitutiveLaw, and the elements / conditions would in the future access the properties through the accessor instead of accessing the properties directly

In a standard case the accessor is empty (=> the baseclass of the accessor), the users can define their own accessors to do basically anything. One thing would be the interpolative stuff I am intending to do here

The plan to proceed is that we discuss in this issue a bit abt it and then (I guess myself) can do a draft implementation

we said that we would change all accesses to the properties in the StructuralMechancisApplication to accessing the Accessor

One of the main questions was what to pass to the Accessor for the data manipulation. So far we came up with this list:

• Geometry
• DataContainer
• ProcessInfo
• (Some things related to the current GP (e.g. GP-Index or SF-Values))

@KratosMultiphysics/technical-committee @loumalouomega

[RiccardoRossi]

@philbucher a few comments to clarify my personal view on this:

1 - I would modify the properties themselves to have as a member an "Accessor" object (very open to find a better name)
2 - The idea is that FROM OUTSIDE THE ELEMENT one can call something like

     Accessor.Configure( VARIABLE, custom_function ( ... funct_params... ) )

so that if one tries to access

    GetProperties().GetAccessor().GetValue(VARIABLE, ... funct_params... )

then the custom function is actually called without having to know it from within the element (or the call site for the properties)
3 - One can still do GetProperties().GetValue(VARIABLE) thus getting access to VARIABLE without the cost of going through the accessor

[philbucher]

thx for the additions @RiccardoRossi

1. I agree
2. I agree very much, the Configure fct seems a good solution
3. Seems good

The only thing we have to make sure is that the elements that would use the accessor instead of directly the properties have to be modified

[armingeiser]

One comment to 3.:

This seems dangerous to me, because if both calls are possible, a user would not know (and also should not know imho) which one is implemented in the element he is using.
So if he is used to use such tables with some elements, and he switches the element type, he would encounter differnt behaviour without knowing why...

[philbucher]

@armingeiser yes I agree, thats why we have to / should do it for the entire application at once

[RiccardoRossi]

@armingeiser the point is that we cannot add additional overhead for people who favor speed over flexibility.

for example we could decide that the StructuralMechanics always goes through the accessor, since element cost is low compared to solution cost, however this may not be the case for example for the case of fluid.

[loumalouomega]

Maybe we can combine the use of accesor or not with the definition of a new flag

[philbucher]

FYI
I will make a draft for the implementation towards the end of next week unless there are major concerns by @KratosMultiphysics/technical-committee

[philbucher]

referencing @KlausBSautter since he also needs sth like this

[pooyan-dadvand]

For me the weak point of this proposal is the argument list for the accesor function... They are a lot of possible parameters... At least we may pass the element itself and process info.

[RiccardoRossi]

Hi @pooyan-dadvand i though a bit and even though i am not really in favor i would accept the case for passing a Element*

my problem however with passing the element itself is that we can access the properties both from an element and a condition. What would we do then for a condition?

As of now i think that the parameters should be

   const Geometry& geom,
   cosnt Vector& ShapeFunctionValues,
   const int GaussPointIndex,
   const ProcessInfo& CurrentProcessInfo

If we could substitute the first by the suggestion of @pooyan-dadvand than we would have

   const Element* pelem,
   cosnt Vector& ShapeFunctionValues,
   const int GaussPointIndex,
   const ProcessInfo& CurrentProcessInfo

[pooyan-dadvand]

Good point @RiccardoRossi, we may pass GeometricalObject in order to be able to pass also conditions but then you may only access the base class interface.

[philbucher]

we also have to pass the DataContainer

If we pass Geometry and the DataContainer then it works both for Elements and Conditions

[philbucher]

I opened a small PR for this => #2349

[maceligueta]

Maybe it's a crazy idea, but... can this Accessor be added to the ProcessInfo as well?
I've always perceived the Propertiesand the ProcessInfoas very similar objects, but I also perceive that they are slowly diverging (is this on purpose?). Actually, both use the DataValueContainer(in different ways: ProcessInfoderives from DataValueContainer, while Propertieshas a pointer to it), but the ProcessInfodoes not have tables so far (is this on purpose?).
I just thought that the Accessormight be added to the DataValueContainerobject, so the technology would be available for all those objects. However, I am also aware that it would be using tables from who knows where, and this could block the whole idea.

[josep-m-carbonell]

@maceligueta, nobody answer your point of view. It is true that are similar objects. Tables are contained by the modelpart but not in the processinfo. The addition of tables in properties was done later on, I think.
Another important aspect is that processinfo is the same object for modelparts and submodelparts. However each submodelpart have their own properties. I think this is confussing and can be the origin of some mistakes.

[maceligueta]

Oh yes, I forgot to say that ModelParthas the same structure as well. It is worth mentioning it.
I understand that the information in ProcessInfoand the one in ModelPartcan be confused, but I think the distintion is useful: the variables in ProcessInfocan be queried by any SubModelPart, while each SubModelParthas its own information, independent from the rest.

[josep-m-carbonell]

Yes, the problem occurs when you think that the parent modelpart contains the properties of the submodelparts, which is not like this.

[loumalouomega]

Huuum, this is not very consistent with the mesh heritage of the model parts

[pooyan-dadvand]

I admit that they are several inconsistencies between these objects mainly because of heterogeneous developments done in recent years (mostly by me....) So I am open to your suggestions on it.

Saying that, about the table, still there are some minor details to be cleared in Properties before being copied to the rest of the similar objects.

[philbucher]

closing, reason see #2349