Missbehaviour regarding "interval" with loads in StructuralMechanicsApplication

[AlejandroCornejo]

Dear all,

@Rbravo555 is trying to reproduce a simple case (cantilever with a pressure load applied durint a certain time period [0, 3] s) and we have noticed that after the 3.0 s the load remains applied:

We have tried to solve this by:

1. Adding Damping -> Not working

2. Non-linear simulation -> Not working

3. decrease the dt -> Not working

4. using static simulation -> Not working

5. using a Total Lagrangian element -> Not working

So my impression is that the assign_vector_by_direction_to_condition_process is not working properly... Anyone knows why?

@Rbravo555 will upload the cases to test.

[philbucher]

I am pretty sure that you have to manually set the load to 0 again The load is set to a value in the interval, but not resetted You can print the value of the load to check

[AlejandroCornejo]

I am pretty sure that you have to manually set the load to 0 again The load is set to a value in the interval, but not resetted You can print the value of the load to check

mmm this is what we were thinking, that the condition maintain its previous value. Isn't it more logical to set it as 0 if its beyond the interval? :)

[Rbravo555]

Once the pressure is manually set to zero, the behavior is as expected.

The model is here in any case:

PreviousExample.gid.zip

[loumalouomega]

Huuuum, probably an error from my side (I think I did this). The solution is easy but I cannot reach my computer until Sunday night (and fix this from the phone is not trivial)

El vie., 24 ene. 2020 16:59, Alejandro Cornejo Velázquez < notifications@github.com> escribió:

Dear all,

@Rbravo555 https://github.com/Rbravo555 is trying to reproduce a simple case (cantilever with a pressure load applied durint a certain time period [0, 3] s) and we have noticed that after the 3.0 s the load remains applied:

[image: imagen] https://user-images.githubusercontent.com/26402605/73082875-868e2580-3eca-11ea-99f1-c083ad01737a.png

We have tried to solve this by:

1.

Adding Damping -> Not working 2.

Non-linear simulation -> Not working 3.

decrease the dt -> Not working 4.

using static simulation -> Not working 5.

using a Total Lagrangian element -> Not working

So my impression is that the assign_vector_by_direction_to_condition_process is not working properly... Anyone knows why?

@Rbravo555 https://github.com/Rbravo555 will upload the cases to test.

— 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/6291?email_source=notifications&email_token=AEYQZABFMSC47Y4UZPJUIP3Q7MF5RA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IIR3CDA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYQZAFA7BLWXAE43BBDHKTQ7MF5RANCNFSM4KLIJUSA .

[loumalouomega]

This would affect other types of function loads BTW.

El vie., 24 ene. 2020 21:19, Vicente Mataix Ferrándiz < vicente.mataix@polytechnique.edu> escribió:

Huuuum, probably an error from my side (I think I did this). The solution is easy but I cannot reach my computer until Sunday night (and fix this from the phone is not trivial)

El vie., 24 ene. 2020 16:59, Alejandro Cornejo Velázquez < notifications@github.com> escribió:

Dear all,

@Rbravo555 https://github.com/Rbravo555 is trying to reproduce a simple case (cantilever with a pressure load applied durint a certain time period [0, 3] s) and we have noticed that after the 3.0 s the load remains applied:

[image: imagen] https://user-images.githubusercontent.com/26402605/73082875-868e2580-3eca-11ea-99f1-c083ad01737a.png

We have tried to solve this by:

1.

Adding Damping -> Not working 2.

Non-linear simulation -> Not working 3.

decrease the dt -> Not working 4.

using static simulation -> Not working 5.

using a Total Lagrangian element -> Not working

So my impression is that the assign_vector_by_direction_to_condition_process is not working properly... Anyone knows why?

@Rbravo555 https://github.com/Rbravo555 will upload the cases to test.

— 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/6291?email_source=notifications&email_token=AEYQZABFMSC47Y4UZPJUIP3Q7MF5RA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IIR3CDA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYQZAFA7BLWXAE43BBDHKTQ7MF5RANCNFSM4KLIJUSA .

[philbucher]

how would you fix this @loumalouomega ?

[loumalouomega]

Creating a clear function and calling it when outside of the time interval (basically that)

[philbucher]

that makes sense to me, but what does "Clear" do in this case? This is not clear (:laughing:) to me reset to a value? But what value?

[loumalouomega]

Don't worry about that, it is easy to fix

El sáb., 25 ene. 2020 14:35, Philipp Bucher notifications@github.com escribió:

that makes sense to me, but what does "Clear" do in this case? This is not clear (😆) to me reset to a value? But what value?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/6291?email_source=notifications&email_token=AEYQZABSBIAE4R5VBWDTLNLQ7Q53TA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ44UCQ#issuecomment-578406922, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYQZAFYT57ZMICCNWP3ZB3Q7Q53TANCNFSM4KLIJUSA .

[RiccardoRossi]

guys, i think that mantaining the load is the expected behaviour and not a bug...so please do not change this lighthearted...

if we want to change this we xan, but it needs to be disccussed,communicated, etc

On Sat, Jan 25, 2020, 3:14 PM Vicente Mataix Ferrándiz < notifications@github.com> wrote:

Don't worry about that, it is easy to fix

El sáb., 25 ene. 2020 14:35, Philipp Bucher notifications@github.com escribió:

that makes sense to me, but what does "Clear" do in this case? This is not clear (😆) to me reset to a value? But what value?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/KratosMultiphysics/Kratos/issues/6291?email_source=notifications&email_token=AEYQZABSBIAE4R5VBWDTLNLQ7Q53TA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ44UCQ#issuecomment-578406922 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AEYQZAFYT57ZMICCNWP3ZB3Q7Q53TANCNFSM4KLIJUSA

.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/6291?email_source=notifications&email_token=AB5PWENRWVKPYUA2J56JMQDQ7RCNTA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ45JNI#issuecomment-578409653, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5PWELTKNVFAUCQLFBCP2TQ7RCNTANCNFSM4KLIJUSA .

[RiccardoRossi]

the point is that this same fu ction is also used for prescribing inlet. in that case you would expect to remove the fixity, but to leave the value as "initial" for the folowing steps

On Sat, Jan 25, 2020, 5:22 PM Riccardo Rossi rrossi@cimne.upc.edu wrote:

guys, i think that mantaining the load is the expected behaviour and not a bug...so please do not change this lighthearted...

if we want to change this we xan, but it needs to be disccussed,communicated, etc

On Sat, Jan 25, 2020, 3:14 PM Vicente Mataix Ferrándiz < notifications@github.com> wrote:

Don't worry about that, it is easy to fix

El sáb., 25 ene. 2020 14:35, Philipp Bucher notifications@github.com escribió:

that makes sense to me, but what does "Clear" do in this case? This is not clear (😆) to me reset to a value? But what value?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/KratosMultiphysics/Kratos/issues/6291?email_source=notifications&email_token=AEYQZABSBIAE4R5VBWDTLNLQ7Q53TA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ44UCQ#issuecomment-578406922 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AEYQZAFYT57ZMICCNWP3ZB3Q7Q53TANCNFSM4KLIJUSA

.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/6291?email_source=notifications&email_token=AB5PWENRWVKPYUA2J56JMQDQ7RCNTA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ45JNI#issuecomment-578409653, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5PWELTKNVFAUCQLFBCP2TQ7RCNTANCNFSM4KLIJUSA .

[loumalouomega]

Yes, I was thinking about that. That can be solved with flags or auxiliar variables

El sáb., 25 ene. 2020 18:58, Riccardo Rossi notifications@github.com escribió:

the point is that this same fu ction is also used for prescribing inlet. in that case you would expect to remove the fixity, but to leave the value as "initial" for the folowing steps

On Sat, Jan 25, 2020, 5:22 PM Riccardo Rossi rrossi@cimne.upc.edu wrote:

guys, i think that mantaining the load is the expected behaviour and not a bug...so please do not change this lighthearted...

if we want to change this we xan, but it needs to be disccussed,communicated, etc

On Sat, Jan 25, 2020, 3:14 PM Vicente Mataix Ferrándiz < notifications@github.com> wrote:

Don't worry about that, it is easy to fix

El sáb., 25 ene. 2020 14:35, Philipp Bucher notifications@github.com escribió:

that makes sense to me, but what does "Clear" do in this case? This is not clear (😆) to me reset to a value? But what value?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <

https://github.com/KratosMultiphysics/Kratos/issues/6291?email_source=notifications&email_token=AEYQZABSBIAE4R5VBWDTLNLQ7Q53TA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ44UCQ#issuecomment-578406922

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AEYQZAFYT57ZMICCNWP3ZB3Q7Q53TANCNFSM4KLIJUSA

.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub < https://github.com/KratosMultiphysics/Kratos/issues/6291?email_source=notifications&email_token=AB5PWENRWVKPYUA2J56JMQDQ7RCNTA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ45JNI#issuecomment-578409653 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB5PWELTKNVFAUCQLFBCP2TQ7RCNTANCNFSM4KLIJUSA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/6291?email_source=notifications&email_token=AEYQZAH37QCGSB4MWXWO5DTQ7R4SVA5CNFSM4KLIJUSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ5BW3A#issuecomment-578427756, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYQZAA5Z5HXO3PDVFSJPWLQ7R4SVANCNFSM4KLIJUSA .

[loumalouomega]

the point is that this same fu ction is also used for prescribing inlet. in that case you would expect to remove the fixity, but to leave the value as "initial" for the folowing steps …

@RiccardoRossi the process that sets the inlet and the one which sets the loads is different. One is assign_scalar_variable_process and the other one is assign_scalar_variable _to_entitities_process. The first one set on the historical variables and the second one in teh non-historicals. Th process to be modified is the second one

[philbucher]

But then the behavior is inconsistent between the two processes

[loumalouomega]

But then the behavior is inconsistent between the two processes

And the nature of the two processes it is too. The historical values are expected to be the result of the problem, therefore the information feedback comes from the resolution of the problem not from an imposed value

[RiccardoRossi]

the point is that outside of the interval you simply do not touch any longer the value, so to me it makes sense that it remains to the value you set before and you evolve from there.

if you want to set a new value, for example 0, no problem, but then you need to tell what is the next value

[loumalouomega]

the point is that outside of the interval you simply do not touch any longer the value, so to me it makes sense that it remains to the value you set before and you evolve from there.

if you want to set a new value, for example 0, no problem, but then you need to tell what is the next value

Therefore current implementation is right, in any case I would add an option to automatically clear after the interval is finished. Otherwise behaviours like this one may occur

[philbucher]

Well adding the option not only changes the behavior in sensitive parts of the code but is also redundant and inconsistent As Riccardo says, the desired behavior can be achieved already

[loumalouomega]

Well adding the option not only changes the behavior in sensitive parts of the code but is also redundant and inconsistent As Riccardo says, the desired behavior can be achieved already

¯_(ツ)_/¯

[RiccardoRossi]

An alternative solution would be to apply the load by table or by a function of time defined with an if

[loumalouomega]

An alternative solution would be to apply the load by table or by a function of time defined with an if

Well, in #6296 there is a correction assuming that the load must be applied only in the interval. I think the modification makes sense, as is not the same an initial condition than a load. Think first about the expected behavior, but if the load is not cleared, which is the purpose of the interval in a load?

[rubenzorrilla]

After going through the discussion, I think that @loumalouomega is pointed in the right direction when asking "which is the purpose of the interval in a load?". Unfortunately I think that the answer is completely problem dependent.

For instance, what a would expect in a common mechanical problem is that the load is null outside of the interval. However, this is not the case when solving a geomechanics problem as I would expect the preload to remain if it is not otherwise stated.

Having said this, I'd try to keep the same behaviour in all the processes as @philbucher suggests. Note that the distinction between the historical and non-historical data is rather easy for more or less advanced developers, but this might not the case for a newbie or for someone that is using Kratos directly from the GUI.

[loumalouomega]

After going through the discussion, I think that @loumalouomega is pointed in the right direction when asking "which is the purpose of the interval in a load?". Unfortunately I think that the answer is completely problem dependent.

For instance, what a would expect in a common mechanical problem is that the load is null outside of the interval. However, this is not the case when solving a geomechanics problem as I would expect the preload to remain if it is not otherwise stated.

Having said this, I'd try to keep the same behaviour in all the processes as @philbucher suggests. Note that the distinction between the historical and non-historical data is rather easy for more or less advanced developers, but this might not the case for a newbie or for someone that is using Kratos directly from the GUI.

Thanks @rubenzorrilla

[RiccardoRossi]

Imagine that you want to have a load that is first growing and then released.

you make two processes, one that grows within and is considered within the same interval, and one that sets the load to zero and is applied in the second interval

[philbucher]

closing this as the current behavior is the expected one and the @KratosMultiphysics/technical-committee disagrees changing this as it would no longer be generic (e.g. for fluid would break things)

see also here

the correct solution is to specify two process for each interval (the second one is used to set the loads back to zero)