KratosMultiphysics / Kratos

Kratos Multiphysics (A.K.A Kratos) is a framework for building parallel multi-disciplinary simulation software. Modularity, extensibility and HPC are the main objectives. Kratos has BSD license and is written in C++ with extensive Python interface.
https://kratosmultiphysics.github.io/Kratos/
Other
991 stars 244 forks source link

[Core] [Element] LumpedMassMatrix #6414

Open miguelmaso opened 4 years ago

miguelmaso commented 4 years ago

Recently we have been talking about possibles implementations of explicit time integration. Depending on the implementation of the strategy, it could be interesting to define a new method in the element base class to compute the lumped mass matrix:

virtual void LumpedMassMatrix(VectorType& rMassMatrix, const ProcessInfo& rCurrentProcessInfo)

For consistency, another method with MatrixType could be added

What do you think @RiccardoRossi @rubenzorrilla ?

loumalouomega commented 4 years ago

See the implementations in the StructuralMechanics, there are already several utilities for the explicit simulations.

El jue., 13 feb. 2020 18:07, miguelmaso notifications@github.com escribió:

Recently we have been talking about possibles implementations of explicit time integration. Depending on the implementation of the strategy, it could be interesting to define a new method in the element base class to compute the lumped mass matrix:

virtual void LumpedMassMatrix(VectorType& rMassMatrix, const ProcessInfo& rCurrentProcessInfo)

For consistency, another method with MatrixType could be added

What do you think @RiccardoRossi https://github.com/RiccardoRossi @rubenzorrilla https://github.com/rubenzorrilla ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/6414?email_source=notifications&email_token=AEYQZAFYBVNEOUCWV3CY4E3RCV46FA5CNFSM4KUW7LY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INKSZUA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYQZACVYPURP26NVAGSE5TRCV46FANCNFSM4KUW7LYQ .

rubenzorrilla commented 4 years ago

See the implementations in the StructuralMechanics, there are already several utilities for the explicit simulations. El jue., 13 feb. 2020 18:07, miguelmaso notifications@github.com escribió: Recently we have been talking about possibles implementations of explicit time integration. Depending on the implementation of the strategy, it could be interesting to define a new method in the element base class to compute the lumped mass matrix: virtual void LumpedMassMatrix(VectorType& rMassMatrix, const ProcessInfo& rCurrentProcessInfo) For consistency, another method with MatrixType could be added What do you think @RiccardoRossi https://github.com/RiccardoRossi @rubenzorrilla https://github.com/rubenzorrilla ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6414?email_source=notifications&email_token=AEYQZAFYBVNEOUCWV3CY4E3RCV46FA5CNFSM4KUW7LY2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INKSZUA>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYQZACVYPURP26NVAGSE5TRCV46FANCNFSM4KUW7LYQ .

This would imply to move these utilities to the core.

rubenzorrilla commented 4 years ago

Recently we have been talking about possibles implementations of explicit time integration. Depending on the implementation of the strategy, it could be interesting to define a new method in the element base class to compute the lumped mass matrix:

virtual void LumpedMassMatrix(VectorType& rMassMatrix, const ProcessInfo& rCurrentProcessInfo)

For consistency, another method with MatrixType could be added

What do you think @RiccardoRossi @rubenzorrilla ?

As we've discussed in person. I like the idea and it would fit into the new general explicit strategy we are working on. The nice thing is that this would make possible to work with the mass multiplied by the density (as I don't have expertise I don't know if this is the common case).

However, this would require to do the explicit "solve" by looping the elements, introducing thus some parallelism overhead (I did not realise about this when we discussed in person). Doing the "solve" by looping the elements and using the nodal mass is equivalent and of course more efficient (please correct me if I'm wrong).

In any case, the addition of this method to the base class doesn't hurt anyone so I'd be in favour (despite we finally do not use it for the explicit stuff).

loumalouomega commented 4 years ago

https://github.com/KratosMultiphysics/Kratos/blob/master/applications/StructuralMechanicsApplication/custom_utilities/explicit_integration_utilities.cpp

and

https://github.com/KratosMultiphysics/Kratos/blob/master/applications/StructuralMechanicsApplication/custom_utilities/structural_mechanics_element_utilities.cpp

miguelmaso commented 4 years ago

https://github.com/KratosMultiphysics/Kratos/blob/51bd6c170a20b779c4453d8b456267bf3a242b27/applications/StructuralMechanicsApplication/custom_utilities/structural_mechanics_element_utilities.cpp#L121

then, we could use this variable in the ProcessInfo to define the behavior of the MassMatrix method.

but... one method has two behaviors and the right behavior is defined across a variable which isn't explicit in the arguments

RiccardoRossi commented 4 years ago

I would prefer to keep the use of the MassMatrix function, since having two would imply changing all the schemes, elements etc.

controlling by a value passed in the rCurrentProcessInfo doesn't look terrible to me...

philbucher commented 4 years ago

FYI @KlausBSautter maybe he has an opinion here too

I don't have a strong opinion on whether the computation of the Lumped MM should be a separate fct or controlled by a var in the ProcessInfo pro:

We should also take care that in case we change it the user can still select the usage of the Lumped MM for certain elements: https://github.com/KratosMultiphysics/Kratos/blob/8733de63c355abfe685aa70dd160a9217f321b82/applications/StructuralMechanicsApplication/custom_utilities/structural_mechanics_element_utilities.cpp#L112-L129

Maybe a solution would be to first implement the new strategy and then we will know how much sense it makes to have it a separate function

I like the idea and it would fit into the new general explicit strategy we are working on

@rubenzorrilla what are you working on exactly?

rubenzorrilla commented 4 years ago

FYI @KlausBSautter maybe he has an opinion here too

I don't have a strong opinion on whether the computation of the Lumped MM should be a separate fct or controlled by a var in the ProcessInfo pro:

  • makes more clear what is happening con:
  • changing it to a separate fct will require a lot of refactoring

We should also take care that in case we change it the user can still select the usage of the Lumped MM for certain elements:

https://github.com/KratosMultiphysics/Kratos/blob/8733de63c355abfe685aa70dd160a9217f321b82/applications/StructuralMechanicsApplication/custom_utilities/structural_mechanics_element_utilities.cpp#L112-L129

Maybe a solution would be to first implement the new strategy and then we will know how much sense it makes to have it a separate function

I like the idea and it would fit into the new general explicit strategy we are working on

@rubenzorrilla what are you working on exactly?

We are developing a new DOF-based explicit strategy. The idea is that this can work with any element in Kratos.

loumalouomega commented 4 years ago

We are developing a new DOF-based explicit strategy. The idea is that this can work with any element in Kratos.

How are you planning to do?, I proposed some time ago to define some way to retrieve the corresponding derivatives of the variables so it can be done automatically (and not manually as it is in the custom bdf)

rubenzorrilla commented 4 years ago

I would prefer to keep the use of the MassMatrix function, since having two would imply changing all the schemes, elements etc.

controlling by a value passed in the rCurrentProcessInfo doesn't look terrible to me...

The point is that the MassMatrix method returns a MatrixType. I found that having a mass matrix (whatever is the name) method that returns a VectorType would be nice for the sake of performance (I think that this is why @miguelmaso is proposing this new method).

KlausBSautter commented 4 years ago

like that: ? https://github.com/KratosMultiphysics/Kratos/blob/387cbfe7916a548e717abae9d294631e7072d824/applications/StructuralMechanicsApplication/custom_elements/truss_element_3D2N.cpp#L1046-L1070

KlausBSautter commented 4 years ago

we are using this in the StructMechApp for all the elements

miguelmaso commented 4 years ago

like that: ?

https://github.com/KratosMultiphysics/Kratos/blob/387cbfe7916a548e717abae9d294631e7072d824/applications/StructuralMechanicsApplication/custom_elements/truss_element_3D2N.cpp#L1046-L1070

yes, I was thinking in something like that

GuillermoCasas commented 4 years ago

Perhaps the people from hte @KratosMultiphysics/dem are interested in these ideas as well. Remember that there everything has always been explicit.

veiguf commented 2 years ago

The lumped mass matrix works e.g. with the StructuralMechanicsApplication but I see that for beam and shell elements the terms related to the rotational degrees of freedom are zero. Is there a way to activate these terms or should we implement that.

loumalouomega commented 2 years ago

The lumped mass matrix works e.g. with the StructuralMechanicsApplication but I see that for beam and shell elements the terms related to the rotational degrees of freedom are zero. Is there a way to activate these terms or should we implement that.

We should implement it

KlausBSautter commented 2 years ago

It is implemented for the beam https://github.com/KratosMultiphysics/Kratos/blob/4c8a07592cf4056557be0e5dff1c19839a5e3b98/applications/StructuralMechanicsApplication/custom_elements/cr_beam_element_3D2N.cpp#L1513-L1514