Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use linearly increasing ramp as inflow BC #620

Draft
wants to merge 2 commits into
base: develop
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 7 additions & 3 deletions perpendicular-flap/fluid-openfoam/0/U
Original file line number Diff line number Diff line change
Expand Up @@ -8,14 +8,18 @@ FoamFile

dimensions [0 1 -1 0 0 0 0];

internalField uniform (10 0 0);
internalField uniform (0 0 0);

boundaryField
{
inlet
{
type fixedValue;
value $internalField;
type uniformFixedValue;
uniformValue table
(
(0 (0 0 0))
(1 (10 0 0))
);
}
outlet
{
Expand Down
2 changes: 1 addition & 1 deletion perpendicular-flap/fluid-openfoam/system/controlDict
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ stopAt endTime;

endTime 5;

deltaT 0.01;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using a ramp also allows us to use a larger time step size in OpenFOAM. I did not change the overall time window size in the precice-config.xml since I am not sure if we will see the same effect in nutils. And I'm also not sure if there is any potential for increasing the time step size in SU2.

Would be helpful and a useful step in the scope of this PR if anybody wants to evaluate this but also not necessary, since preCICE generally supports using a smaller time step size in the config than in the solver (if everything is implemented correctly in the adapters).

Copy link

@bevanwsjones bevanwsjones Feb 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Benjamin, sorry this was on my feed and I just thought I would put a quick comment. Hope you well otherwise :).

I have also encountered issues with inflow conditions (back when I was still building CFD codes). Esp, for incompressible solvers and large velocities (its basically water hammer). What I found, which worked really well, was to use a sigmoid function as the ramp, as the gradients are nicer. You have 'no' discontinuity at the start or end, so the 'size/magnitude' of the final velocity does not affect the size of the jump over the starting discontinuity (time step dependent though) and it 'gives' the flow some time to react locally. When I talk of discontinuity here its a C1 discontinuity.

Anyways just my 2 cents comment.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @bevanwsjones, thank you for the comment and the hint with the sigmoid function! That's very helpful. If we are already touching the case it would be nice to directly use a solution that works well (even for higher-order).

I also had some trouble with C1 discontinuous inflow velocities when I tried to reach 2nd order in time for the results presented here. The fix I found was using a -cos(t)+1 instead of a sin(t) as inflow condition for the elastic-tube-1d example. I assume this is a similar case and time-stepping order should also profit from higher-order continuity here.

deltaT 0.025;

writeControl adjustableRunTime;

Expand Down