Kratos: Passing Element* in the ConstitutiveLaw::Parameters

[RiccardoRossi]

This is not a new idea, however i would like to propose passing a raw pointer to the Element in the ConstitutiveLaw::Parameters.

that would have a number of advantages, and in particular:

• allow accessing element database
• allow accessing element Id

[loumalouomega]

[josep-m-carbonell]

@loumalouomega ... the structure of the code does not feel so good

[loumalouomega]

I know, but with great power comes great responsibility. Sure, you can break everything this way, but the idea is that the user knows what is doing

[josep-m-carbonell]

In that case it will be better to pass a void* argument. But if this argument is pointing to the element itself, you are doing something wrong. So if your argument is Element* you are inviting people to do wrong things that you can not imagine now. In my opinion it is not a good idea, I am sorry.

[RiccardoRossi]

@josep-m-carbonell your point is fair.

this is also the reason i don t love it.

note nevertheless that the situation is slightkt sifferent:

element OWNs CL while CL woukd USE an element RAW pointer, which we d make to be a pointer to const (surely pointer to const would be a better solution that just Element*)

[philbucher]

@RiccardoRossi this seems like a duplicate of #2349
Good thing I am not the only one needing such capabilities

2349 would be very intrusive, therefore I am not sure if this might be the better solution ... it's not the cleanest though, for the reasons @josep-m-carbonell is pointing out

=> Why not rather than passing the element itself, passing the DataValueContainer, id, ... separately? Then it would not be as bad I think and also would work for conditions (in case use CLaws)

[RiccardoRossi]

@philbucher the accessor discussion is very active, actually the same discussion is also valid there.

passing the datavalue container and id is surely an option, however by passing the element pointer one woild be actually be passing at once geoemtry, id and datavaluecontainer.
my latest thought is that if we pass this as const it would not be too bad (although it is true that we wouldn t be able to pass condition*)

actually to be fair, the discussion started with the CL team telling that they needed the element id to be passed...

[RiccardoRossi]

let's try it another way though.
How would be the feeling about
1 - passing "element" Id in the CL::Parameters?
2 - passing "DataValueContainer const*" in the CL::Parameters

[frastellini]

The CL wants to know which was his father element (at least the element ID). For example when an error happens in the CL we would like to know the location (element ID should be enough).

If it is decided to pass a pointer to the father element, the idea is that the CL could only READ the element data. The CL must not use the element methods. Can we allow "READ only access" to element data from the CL ?

[pooyan-dadvand]

If id is only needed for error reporting I don't agree in passing it. You may re-throw the error from element adding the id info.

IMO, passing a const Element * to constitutive law is a better option than passing all data stored in element to CL

[pooyan-dadvand]

In @KratosMultiphysics/technical-committee we considered the Condition case as an important problem and we think that we should create a common base class for Element and Condition with all their common interface in it, So we can pass that pointer to this case and all other similar cases.

While the above solution would be the long period solution, at this moment we can go ahead with const Element * which will be change to the common base class of Element and Condition in future.

[josep-m-carbonell]

Can somebody explain which element information is needed in the constititive law, and why? Just too see if there is any alternative.

[RiccardoRossi]

The discussion began with people saying that they would need the Id. That would be useful for debugging purposes but not just, for example to be able to eventually pass a table "element vs data"
in the properties.

As Pooyan, i also do not love the idea of passing the Id as such.

Some of the advantages of passing this would be to give access to the "DataValueContainer".
also at the same time one would avoid passing
"Properties", "Geometry", "DataValueContainer", "Id"

[jcotela]

I know it is not the main design goal of the CL, but I can see a use-case in fluids. If the constitutive law could see the elemental data I would be able to implement LES eddy viscosity models as strain-rate constitutive laws (maybe even composite laws added on top of a Newtonian law, but lets not get too far ahead here). These typically require some data that is local to the element (not its nodes or its property).

At any rate, if the choice is between passing all data managed by an element through some custom interface or passing a const Element *, I think that the element pointer is the less bad option at this point. The circular dependency problem of @josep-m-carbonell would only be an issue if the implementer of the constitutive law decides to store the pointer internally. The only way I can think of preventing that is declaring the ConstitutiveLaw methods that get an Element* as an argument as const, but I do not know if this is a viable option in this case.

Otherwise, we could not prevent developers from doing that if they want to, but hopefully there will be documentation warning about potential problems.

[josep-m-carbonell]

Thank you for your explanations. However in all of them you are missing the fact that a CL and element is not something that is going one-one. The one-one relationship is between CL and Integration point.

This means that the integration point Id also must be passed to the CL if you want to acces the element information of data base Variables. According for the most general case, without thinking only on linear elements.

I have not seen a table element_id vs constitutive_law _data. I guess it can be hard to build a table of this type. May be it would be better to supply this information in another way.

It would be good to know which variables defined in the element, not for integration points, are needed direcly in the CL and in which Kratos Variable will be stored. If the data you want to acces is a private member of the element, then you will need this GetValuesOnIntegrationPoints method, that most of you propose to eliminate from the element base class. Or to create a similar one.

I think that if you want to know the element id, you can pass it to the Constitutive law, once is cloned into the Element, using SetValue.

[RiccardoRossi]

The point is that the information of the number of gauss point is not not relevant for a number of reasons. I see at least 3 out of the box:

1 - the element may use a non standard intengration rule. (this is done for example by the B-bar eleemnt or by all of the "embedded" elements
2 - the element is in charge of the kinematics, so the calculation of the shape function and shape function derivatives needs to be done by the element and passed on to the CL (as it is done now)
3 - calculation of F and detF, also depends on how the kinematics is handled, and hence depends from the element and not from the geometry

note that these are not an argument in favor of passing Element*, it is simply the reason for which i think we should not pass the gauss point id.

[jcotela]

The point that the CL is related to the integration point is true, but then we find the fact that no dedicated container for integration point data exists in Kratos. As you say, data must be stored either on the CL itself or somewhere else. Data specific to a given integration point should be managed by the CL itself, in my opinion (this would also go a long way in preventing the problem of having to pass the integration point index that @RiccardoRossi is mentioning).

The problem we are concerned with here is more general data. If it is in the element data container (or the property or some of the other things that we are already passing to the CL), then you need to pass it to the CL somehow. The option of just passing it through a SetValue is inefficient (you are storing the same quantity in memory N times for all integration points, multiply times the number of parameters you need to pass) and error-prone (what happens if the source data changes? you need to update everything to stay consistent).

[pooyan-dadvand]

The decision about this issue depends on if we agree on #3244. On hold until that decision.

[roigcarlo]

Closing since we have decided to move DataValue container into Geometry