Open miguelmaso opened 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 .
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.
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 addedWhat 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).
and
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
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...
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?
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:
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.
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)
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).
we are using this in the StructMechApp for all the elements
like that: ?
yes, I was thinking in something like that
Perhaps the people from hte @KratosMultiphysics/dem are interested in these ideas as well. Remember that there everything has always been explicit.
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.
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
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:
For consistency, another method with
MatrixType
could be addedWhat do you think @RiccardoRossi @rubenzorrilla ?