Kratos
Kratos copied to clipboard
KratosMultiphysics
[StructuralMechanicsApplication] Fix Lumped factors in Massmatrix for solids
Description Fix #8457. Computes just once the lumping factors. NOTE: I think that this could be an issue with imposed displacement, in any case the lumping factors can still be computed in an external process
Changelog
- Added variable LUMPING_FACTORS
- Compute factors just once
IMO the element should be in charge of this
If you see my first commits, I tried to be computed by the element all the time, but the method is const, so I cannot do a SetValue without doing an evil const_cast
Then, do you allow me to const_cast?
El vie., 12 mar. 2021 13:48, Philipp Bucher @.***> escribió:
@.**** commented on this pull request.
In applications/StructuralMechanicsApplication/custom_elements/base_solid_element.cpp https://github.com/KratosMultiphysics/Kratos/pull/8462#discussion_r593147729 :
@@ -1696,8 +1696,13 @@ void BaseSolidElement::CalculateLumpedMassVector( // LUMPED MASS MATRIX const double total_mass = GetGeometry().DomainSize() * density * thickness;
- Vector lumping_factors;
- lumping_factors = GetGeometry().LumpingFactors( lumping_factors );
- Vector lumping_factors(number_of_nodes);
- if (this->Has(LUMPING_FACTORS)) {
lumping_factors = this->GetValue(LUMPING_FACTORS);- } else {
lumping_factors = GetGeometry().LumpingFactors( lumping_factors );this->SetValue(LUMPING_FACTORS, lumping_factors);well the element shouldnt set it if it would set it here the first time it is called it wouldn't work in restarts
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/pull/8462#discussion_r593147729, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYQZAGTKROSYQ3XJACZGZLTDIESLANCNFSM4Y6SA2ZA .
Then, do you allow me to const_cast?
No, I mean it would anyway not work, as in restart the configuration in the first timestep is anyway no longer the reference config
Then, do you allow me to const_cast?
No, I mean it would anyway not work, as in restart the configuration in the first timestep is anyway no longer the reference config
The restart saves the values of the DataValueContainer?, because if it is saved, it will be saved together with the rest of values
Then, do you allow me to const_cast?
No, I mean it would anyway not work, as in restart the configuration in the first timestep is anyway no longer the reference config
The restart saves the values of the DataValueContainer?, because if it is saved, it will be saved together with the rest of values
Yes but then we could directly store them as members without the overhear of the DVC
which is not what we want, but for now I don't know a better solution hence I wanted to discuss it in the KTC first before making a decision here
which is not what we want, but for now I don't know a better solution hence I wanted to discuss it in the KTC first before making a decision here
well, but not all the problems require the lumped factors. We can use a pointer which requires an additional double of storage by default
which is not what we want, but for now I don't know a better solution hence I wanted to discuss it in the KTC first before making a decision here
Any news?
which is not what we want, but for now I don't know a better solution hence I wanted to discuss it in the KTC first before making a decision here
Any news?
Ping
still the original issue is not solved that we need a way to compute things on the initial configurations
ping @KratosMultiphysics/technical-committee
still the original issue is not solved that we need a way to compute things on the initial configurations
Okay, can be solved, but this problem existed before this PR already
we cannot accept this change as it would imply storing on every element the lumping fasctors, which would imply storing a vector on every element.
the geometry has a function lumping factors that can be called. For low order elements (triangles or tets) it is cheap...not so for other kind of elements, still i think it is better to recompute than to store it
I think, the important question is @KlausBSautter (this fixes #8457) if this is for explicit simulation, because in that case we have the tradeoff between computing each time (expensive in explicit) or storing more memory. Depending on that, we will need to discuss
we cannot accept this change as it would imply storing on every element the lumping fasctors, which would imply storing a vector on every element. the geometry has a function lumping factors that can be called. For low order elements (triangles or tets) it is cheap...not so for other kind of elements, still i think it is better to recompute than to store it
I think, the important question is @KlausBSautter (this fixes #8457) if this is for explicit simulation, because in that case we have the tradeoff between computing each time (expensive in explicit) or storing more memory. Depending on that, we will need to discuss
Ping @KlausBSautter
It is basically for both implicit and explicit, it does not matter. In the mebrane_element.cpp file for quads I calculate det(J) everytime based on the reference coordinates X0. So I implicitly went for the more expensive choice of recalculating the lumping factors. I dont think this will cause an overhead, will it? Maybe for very large models
It is basically for both implicit and explicit, it does not matter. In the mebrane_element.cpp file for quads I calculate det(J) everytime based on the reference coordinates X0. So I implicitly went for the more expensive choice of recalculating the lumping factors. I dont think this will cause an overhead, will it? Maybe for very large models
The calculation for implicit simulation will be an overhead, but is preferable to memory consumption. But for explicit I think this is a no-go, it will make simulation incredibly expensive. Ping @RiccardoRossi
Do I understand correctly, that we prefer an incorrect implementation because of performance for explicit simulation in the expense of a correct implementation?
