TwoFluids / AccelerationLimitationUtility

[mrhashemi]

Description This utility obviously creates an error and prevents reaching the expected velocity especially in channel flows (with a small length scale). This line should be removed.

Scope

• Two Fluid NS Solver, BDF scheme

To Reproduce Microchannel with inflow (assigned velocity).

Expected behavior For an incompressible fluid, velocity should propagate.

[rubenzorrilla]

Agree. This proved to be helpful in the past for some applications but IMO it should be at least optional and defaulted to be inactive.

[RiccardoRossi]

ok for making it inactive, however i think that Altair is using it

On Thu, Jul 1, 2021, 8:47 AM Rubén Zorrilla @.***> wrote:

Agree. This proved to be helpful in the past for some applications but IMO it should be at least optional and defaulted to be inactive.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/8929#issuecomment-871972234, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5PWEP4NWIRW2UJDPJG523TVQFOXANCNFSM47TELHUQ .

[mrhashemi]

ok for making it inactive, however i think that Altair is using it … On Thu, Jul 1, 2021, 8:47 AM Rubén Zorrilla @.***> wrote: Agree. This proved to be helpful in the past for some applications but IMO it should be at least optional and defaulted to be inactive. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#8929 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5PWEP4NWIRW2UJDPJG523TVQFOXANCNFSM47TELHUQ .

It artificially limits the acceleration and if the user is unaware of its application, there might be large errors. So, being inactive by default (as @rubenzorrilla suggests) could help. Maybe, including it within "formulation" settings: "formulation": { "dynamic_tau": 1.0, "surface_tension": false, "limiting_acceleration": false, "maximum_acceleration_factor": 3.0 }

[rubenzorrilla]

I'm very hesitant to add it to the formulation settings. Note that formulation setting encapsulates element-related settings, which is the place where the formulation belongs to. Besides this, if we eventually create an auxiliary helper mechanism for the formulation as we did in the rest of the fluid this will be duplicated in all elements.

In my opinion it should be a new field of the solver_settings defaults.

[ddiezrod]

ok for making it inactive, however i think that Altair is using it … On Thu, Jul 1, 2021, 8:47 AM Rubén Zorrilla @.***> wrote: Agree. This proved to be helpful in the past for some applications but IMO it should be at least optional and defaulted to be inactive. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#8929 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5PWEP4NWIRW2UJDPJG523TVQFOXANCNFSM47TELHUQ .

we have our own python fluid solver, so you can proceed as you consider. I agree with @rubenzorrilla , this should be off by default.

[playpaolo]

Is this acceleration limited to a hardcoded value?

[mrhashemi]

Is this acceleration limited to a hardcoded value?

It can be changed through void AccelerationLimitationUtilities::SetLimitAsMultipleOfGravitionalAcceleration( double& newMaxAcc ){ mMaximalAccelaration = newMaxAcc; }

[mrhashemi]

Calling this utility with the condition of (time-step > 3) would resolve this issue.

[rubenzorrilla]

@mrhashemi I think we can close this. Do you agree?