Kratos: shall Geometry hold DataValueContainer instead of Element?

[RiccardoRossi]

I am opening this issue to echo an idea that was expressed last week by @jrubiogonzalez and @ddiezrod.
It looks like they are shy and they didn't open this during the last week...so i'll do it in their stead (guys...i am citing you as sources...so you still take the blame :-p )

The problem that is currently being faced is that in complex applications there can be multiple modelparts created by cloning one original modelpart and hence sharing a common geometry. Also elements occupy a lot of memory.

A rather common need is to be able to share data between elements that share a same geometry (now possible after fix #3187).

The proposal that was vocalized informally is to have the DataValueContainer to be assigned to the Geometry rather than to the element (or condition) as it is done as of now.

Aside for giving the possiblity of sharing data, this also would reduce the memory occupation of elements in the case in which the same geometry is used multiple times.

After thinking about for one week i see the following advantages and disadvantages (list to be updated)

ADVANTAGES
1 - data can be shared naturally within elements which share a geometry
2 - overall memory is saved
3 - this makes more "compatible" elements and conditions
4 - geometry already gives access to nodal database. with this change it would also give access to "element" (bad naming) database
5 - This would resolve some ongoing issue for passing data to ConstitutiveLaw or to the PropertiesAccessor.
6 - MAY simplify in storing BC informations for remeshing.

DISADVANTAGE

• one would have to assign a new geometry to an element in order to be able to save different "elemental" data.
• Geometry object becomes heavier. This also applies for "lightweight" geometries of points (which for example we use as temporary objects in computing shape functions). I don't know what we should do in that case.
• making this change would silently break simulations where two elements with a same geometry share data.

I shall say that my first "gut reaction" to this was very negative. I really did not like mixing the concept of geometry with that of database. However, after one week thinking about this, i reached the conclusion that this is actually consistent with geometry giving access to nodal database, and i put this as an advantage.
I also did not manage to find a good counterexample.

what i am really not clear is what to do with Flags...

on the other hand i am convinced that "Properties" shall be assigned to elements and not to the geometries.

anyhow, what i am putting is simply my personal point of view after one week of thinking about it. I know that @pooyan-dadvand also has a formed opinion about this ... so please correct/amend what i am telling here....and ... anyhow this is a early discussion, so any opinion is very welcome.

[loumalouomega]

Another option is to create two geometries, one geometry.h and the other one geometry_with_data.h. The only difference is that geometry_with_data derived from geometry and holds data. Then you can add to the geometries a new template argument to consider if derives from geometry or geometry_with_data. Then you can make the base class by a function of this, like in here:

https://github.com/KratosMultiphysics/Kratos/blob/8ab2c5bd097d7e4cbb51a8438944a25fed083538/applications/StructuralMechanicsApplication/custom_constitutive/generic_small_strain_isotropic_plasticity.h#L58

~cpp
template
class KRATOS_API(STRUCTURAL_MECHANICS_APPLICATION) GenericSmallStrainIsotropicPlasticity
: public std::conditional ~

The only problem is that this increases the compilation needs, but gives the best of the two options

[jrubiogonzalez]

Thanks @RiccardoRossi for helping us to overcome our shyness :P. You have vocalized perfectly our proposal and our rationale.

1. Being able to share/plot elemental information among different modelparts in a clean way.
2. Reduce the memory footprint (we are trying to go on a diet to reduce our computational needs)

I don't have a strong opinion about where to store the properties, but probably this change will brake far more things.

@loumalouomega I think in this case I prefer having a single geometry, otherways it will add too much complexity.

Thanks,

[philbucher]

Adding another thought:
You could assign the data of one element to the data of another element, thus sharing the same data
I.e. elem1.Data() = elem2.Data()
This would work with the current setup

Regarding having the GeometricalObject owning the Data I dont have a stong opinion, but it has to be carefully evaluated since it can silently break stuff!

Plus afterwards it wont be possible any more that two elems share the same geometry but not the Data (unless I manually construct a new geometry)

To me it seems like both have advs and disadvs, not sure if this justifies changing the current behavior

[RiccardoRossi]

@philbucher unfortunately you cannot do

     elem2.Data() = elem1.Data()

since Data is not a pointer but a class variable

[philbucher]

Ah sure
Wouldn’t making it a pointer (same as Geometry and Properties) be the less intrusive and more flexible change?

[RiccardoRossi]

Of course we considered it. The disadvantage is to increase once again the memory occupation (approx 2 more doubles per element) while it would be good to put Kratos on diet...

[philbucher]

Ok I see, thx for replying
No free lunch ...

[pooyan-dadvand]

Just to add:

• It is also a useful feature for working with geometries (i.e. for remeshing) without having to construct a MeshElement over it all the time.
• This would be also a useful feature for eventually decoupling the input data from the formulation by getting only geometries and their data and apply the Properties and Element by the solver to ModelParts.
• I also agree that Properties should not be added to geometry

[pooyan-dadvand]

Forwarding to @KratosMultiphysics/design-committee

[msandre]

I would be in favor :+1:

[philbucher]

we discussed this in @KratosMultiphysics/design-committee and we agree with this change :+1:

[pooyan-dadvand]

@KratosMultiphysics/technical-committee needs a benchmark to check if it affect the performance for embedded problems.

[RiccardoRossi]

just to explain: the concern is that creation of geoemetrors becomes more expensive

[rubenzorrilla]

@KratosMultiphysics/technical-committee needs a benchmark to check if it affect the performance for embedded problems.

And more than embedded, to any level-set based formulation that creates and destroy geometries on the fly.

[loumalouomega]

@KratosMultiphysics/technical-committee needs a benchmark to check if it affect the performance for embedded problems.

And more than embedded, to any level-set based formulation that creates and destroy geometries on the fly.

Indeed, in the mortar segmentation triangles are created and destroyed on the fly all the time

[loumalouomega]

I have been thinking on this. Maybe instead of adding the data-holder to the geometry, it could be moved to the GeometricalObject, base class of the Element and Condition. Then we can add a constructor on the Element and Condition using an existing GeometricalObject.

The only problem is that in order to this work the dataholder should be a pointer to a dataholder (in the same way we have a pointer to the geometry).

The only way to avoid additional pointers would be to have only one pointer to the GeometricalObject, but then derivate from it would make no sense. Additionally with this the Flags would be also shared.

I don't know, sincerely we should think more about this, I don't like the idea to have a heavy geometry.

Another idea is to create an intermediate GeometryWithData class, which allows any Geometry as template argument and has a dataholder as member variable. Something like:

~~~cpp
template
GeometryWithData : public Geometry> // As it will be used on Conditions/Elements we can assume it will be a Node<3>
{
public:
...
// Methods for data access
...

private:
DataValueContainer mData;
}
~~~

Then specialize for each geometry of interest: FE GeometryWithData<Line2D2N<Node<3>>>

[RiccardoRossi]

new question, related to the CAD integration:

should they have Flags?

[jcotela]

@RiccardoRossi if an Element is set to NOT_ACTIVE, do we want to disable all elements using that connectivity?

[RiccardoRossi]

@jcotela I am not sure of the answer to your question, so .. it is a good one!

[philbucher]

hm I would say no, i.e. if I disable one element I do not want to disable the other element

[rubenzorrilla]

hm I would say no, i.e. if I disable one element I do not want to disable the other element

Agree. This would imply that the flags should remain in the element. Am I wrong?

[RiccardoRossi]

the question is related to the "geometry container".

for elements and conditions we flag the ones we want removed. How would we do the same for geometries if we cannot flag them?

having said this i see the merit in keeping the flags in elements

[loumalouomega]

Please @RiccardoRossi do not move flags, I create many conditions,
independent of the mother condition, and I shall remove only the ones that
require it, not all of them.

El lun., 30 sept. 2019 17:50, Riccardo Rossi [e-mail]
escribió:

the question is related to the "geometry container".

for elements and conditions we flag the ones we want removed. How would we
do the same for geometries if we cannot flag them?

having said this i see the merit in keeping the flags in elements

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/3244?email_source=notifications&email_token=AEYQZABE576DJEG5KCB7FBLQMIN47A5CNFSM4GBC66F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD76EFNI#issuecomment-536625845,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEYQZADKZTICKAA7YQ7MHGLQMIN47ANCNFSM4GBC66FQ
.

[RiccardoRossi]

okok,

my question was answered!!

Riccardo

On Mon, Sep 30, 2019, 6:09 PM Vicente Mataix Ferrándiz <
[email protected]> wrote:

Please @RiccardoRossi do not move flags, I create many conditions,
independent of the mother condition, and I shall remove only the ones that
require it, not all of them.

El lun., 30 sept. 2019 17:50, Riccardo Rossi [e-mail]
escribió:

the question is related to the "geometry container".

for elements and conditions we flag the ones we want removed. How would
we
do the same for geometries if we cannot flag them?

having said this i see the merit in keeping the flags in elements

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/KratosMultiphysics/Kratos/issues/3244?email_source=notifications&email_token=AEYQZABE576DJEG5KCB7FBLQMIN47A5CNFSM4GBC66F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD76EFNI#issuecomment-536625845
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AEYQZADKZTICKAA7YQ7MHGLQMIN47ANCNFSM4GBC66FQ

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/3244?email_source=notifications&email_token=AB5PWEN42WQDOFQ4U5HJCQ3QMIQE7A5CNFSM4GBC66F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD76GGAA#issuecomment-536634112,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB5PWEL3VY42C5JIISLZVJ3QMIQE7ANCNFSM4GBC66FQ
.

[pooyan-dadvand]

But having flags in Geometry would be also useful. So maybe we should have it in both places? Using the elemental/conditional ones as they are used now. And the one of the geometry for geometrical information. Meanwhile, I agree that we need to keep the flag in elements and conditions.

[pooyan-dadvand]

@KratosMultiphysics/technical-committee we agreed that having two different flags one in Element/Condition and another one in Geometry would be the best option.

[loumalouomega]

Why?, which is the objective of having flags in entities and geometries at the same time?

[pooyan-dadvand]

Using the entities flags like we do now for marking one of the ones sharing the same geometry and using the flag of geometry for geometrical process when we don't want to store a flag in the geometry (like to_remove, selected, boundary, etc) in the process.

[loumalouomega]

OK

[philbucher]

closed by #5624