Kratos
Kratos copied to clipboard
KratosMultiphysics
[Structural] Fix explicit central difference scheme
I created this PR so that we can discuss the code. I'll adjust my tests soon.
@loumalouomega thanks for the comments and fixes! Let's see what the tests are doing. You have some tests with the explicit central diff. scheme in contact mech, right?
I think the explicit tests in the contact are validation or nightly because they take too long, let me check
@peterjwilson do the new results make sense?
I am super confused, I cannot get the free_falling_sphere_explicit from @loumalouomega to give proper results. I have to look into this now. But all my simulations work with the new code.
@loumalouomega,@peterjwilson, @philbucher we have the following problem:
The new code calls the CalculateRightHandSide in Initialize. I did this because we need to calculate acc_0. For gravity-driven problems, this results in the problem that the acc_0 is not correctly calculated, it is 0. Because VOLUME_ACCELERATION is 0 on each node in Initialize. It is set in InitializeSolutionStep.
So what do you suggest to solve this? I thought about a flag in the scheme which allows me to do a custom initialization in the InitializeSolutionStep of the 1st time step. So that I can do what I did in Initialize 1 time in InitializeSolutionStep. Basically we need a way to calculate the residual of the element before the first solutionstep. If this includes VOLUME_ACCELERATION we run into this problem.
maybe in the first InitializeSolutionStep of the Scheme you could do the computation of Acc_0
by this time the Processes already have called the first time InitializeSolutionStep so the Volume acc will already be applied
@loumalouomega,@peterjwilson, @philbucher we have the following problem:
The new code calls the
CalculateRightHandSideinInitialize. I did this because we need to calculate acc_0. For gravity-driven problems, this results in the problem that the acc_0 is not correctly calculated, it is 0. BecauseVOLUME_ACCELERATIONis 0 on each node inInitialize. It is set inInitializeSolutionStep.So what do you suggest to solve this? I thought about a flag in the scheme which allows me to do a custom initialization in the
InitializeSolutionStepof the 1st time step. So that I can do what I did inInitialize1 time inInitializeSolutionStep. Basically we need a way to calculate the residual of the element before the first solutionstep. If this includesVOLUME_ACCELERATIONwe run into this problem.
I have two questions about this:
1 - what happens if you call this in a FSI loop? recall that InitializeSolutionStep and FinalizeSolutionStep will be called exactly once, while SolveSolutionStep will be called as many times as needed by the FSI loop --> this tells essentially that you should call this kind of stuff in the SolveSolutionStep 2 - the VOLUME_ACCELERATION is set by the processes, so that you can only use it after they set it. You cannot compute it before as it is a user input
This looks more like a buffer problem, IMO
I couldn't find anything wrong with the buffer, maybe you can
This looks more like a buffer problem, IMO
I couldn't find anything wrong with the buffer, maybe you can
If the problem is that we require to calculate acc_0 may be because maybe we should do like in the fluids, and append some initial steps as buffer (instead of doing this computation in the Initialize)
@KlausBSautter yes my new results make sense.
To all:
The setting of initial acceleration a_0 affects newmark average acceleration as well. Currently I'm working around it on the python level manually setting the nodal accelerations to what I want for the zeroth timestep - but this isn't a proper fix.
IMO it would make sense if a separate 'gravity' process in the core existed - with the understanding that it applies acceleration from negative infinity time to positive inifinity time and somehow applies acceleration before the rest of initializeSolutionStep is called. Setting this functionality up would mean other affected time integrators (I expect DEM has a central explicit too, etc...) would automatically be fixed as well, without having to go in each of their schemes and manually fixing them.
Alright, this sounds good. How do we do that?
What we do in the fluid is to drop n-1 steps (i.e. advancing in time by doing a CloneSolutionStep n-1 times without calling the SolveSolutionStep) if the buffer size is n.
BTW, you should at some point consider deriving all these schemes from the new explicit strategies in the core.
@rubenzorrilla we might actually use this occasion to do that
The point is that this involves slightly changing the elements too (the explicit residual contribution is saved in the residual variable as this is actually minus the residual). So you might want to separate the migration changes from this fix. In any case, let me know if you have any issues :wink:
@rubenzorrilla the definition of residual we always use it
res = fext - fint
we shall be consistent with this through the Kratos, particularly in the elements, so if something is to be changed i would argue that it is the strtegy
On Wed, Feb 3, 2021 at 10:39 AM Rubén Zorrilla [email protected] wrote:
@rubenzorrilla https://github.com/rubenzorrilla we might actually use this occasion to do that
The point is that this involves slightly changing the elements too (the explicit residual contribution is saved in the residual variable as this is actually minus the residual). So you might want to separate the migration changes from this fix. In any case, let me know if you have any issues 😉
— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/pull/8185#issuecomment-772372097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5PWEJHH7K6CE5DIIS53GLS5EKWXANCNFSM4W4YOBEQ .
@rubenzorrilla the definition of residual we always use it res = fext - fint we shall be consistent with this through the Kratos, particularly in the elements, so if something is to be changed i would argue that it is the strtegy … On Wed, Feb 3, 2021 at 10:39 AM Rubén Zorrilla @.***> wrote: @rubenzorrilla https://github.com/rubenzorrilla we might actually use this occasion to do that The point is that this involves slightly changing the elements too (the explicit residual contribution is saved in the residual variable as this is actually minus the residual). So you might want to separate the migration changes from this fix. In any case, let me know if you have any issues wink — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#8185 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5PWEJHH7K6CE5DIIS53GLS5EKWXANCNFSM4W4YOBEQ .
I meant in the REACTION variable (not the residual variable). Sorry for the confusion. Thanks for noticing @RiccardoRossi
I just noticed this is an oportunity to refactor to the new explicit builder and solvers and strategies (maybe for another PR)
Ok, I was having problems with the falling sphere test written by you @loumalouomega. One can actually also see in this test that the current strategy lags 1 time step for velocity and acceleration as the velocity in the 1st time step currently is 0 in this case which is wrong.
There are actually more problems:
- As we first have to update the displacement and middle_vel before calculating the element residuals, we somehow should also call MoveMesh and all the finalize operations within the time step. I think this is not feasible.
- I need to call
ConstraintUtilities::PreComputeExplicitConstraintConstributionin the scheme now right after the element residuals have been updated. Because I cannot splitUpdate.
I'd be happy to skype, also including @philbucher
Ok, I was having problems with the falling sphere test written by you @loumalouomega. One can actually also see in this test that the current strategy lags 1 time step for velocity and acceleration as the velocity in the 1st time step currently is 0 in this case which is wrong.
There are actually more problems:
1. As we first have to update the displacement and middle_vel before calculating the element residuals, we somehow should also call MoveMesh and all the finalize operations within the time step. I think this is not feasible. 2. I need to call `ConstraintUtilities::PreComputeExplicitConstraintConstribution` in the scheme now right after the element residuals have been updated. Because I cannot split `Update`.I'd be happy to skype, also including @philbucher
I remember that I "skipped" one step in order to retrieve the analytic solution. That can be updated to the exact solution without additional issues.
For the other problems:
- It is not necessary to move the mesh...if we update the implementation of the elements...
- I do not know how to solve this issue...
- ok that sounds good
- it's not really an issue, more of a comment :)
Yes I can easily change the check function in the proj.parameters. I have other problems right now with the the residual calculated by the small displacement element. I'll get back to you.