[flotus1]

New software new problems

Problem description:
The whole scope of the simulation involves more aspects, but for the sake of simplicity I broke it down to this.
Imagine I want to simulate filling a container with only one opening. At this opening, the pressure is prescribed and varies over time, e.g. rising from absolute 0.5bar to 2.5bar over a period of ~1s. The fluid is air which is initially at rest with an absolute pressure of 0.5bar. The simulation is transient.
During the filling process, the velocity values are rather low in the order of 5m/s but the pressure level changes substantially due to the boundary condition.

Issue:
Problem is: the simulation takes quite a lot of inner iterations per time step (segregated solver) to converge. I played around with URFs ad various solver settings, tried the coupled solver, but to no avail. I need to simulate a lot of these cycles and using 50-200 iterations per time step or very small time step sizes is not feasible.

I broke down the convergence problem to this:
After convergence during the last time step, the new pressure value at the boundary condition is applied for the first iteration of the next time step. Thus causing a high velocity near the boundary. This sets off the lengthy period of the solver trying to find a converged solution for pressure and velocity.
After the time step is converged, the velocity field differs only slightly from the converged solution of the previous time step. The pressure field is also almost identical, just with an offset due to the new boundary value.

My idea:
Knowing that the pressure and velocity fields qualitatively do not differ a lot between 2 time steps -apart from the offset prescribed by the pressure boundary condition- my idea was to apply this offset for the pressure field already for the first iteration of a new time step. I know beforehand what this offset will be based on the changing pressure boundary.

How to do this?
M idea was to use user coding for this. But I did not find how to manipulate pressure values directly in user code. And if I did, there would still be the issue of running the user code once for every first iteration of a new time step. It is straightforward to attach user code to a simulation e.g. as a source term because the UI allows it. But simply executing user code that changes variables in the background...haven't found that feature yet.
Any thoughts on this are welcome. Also other ideas how to change pressure values without user coding.

[bluebase]

Hi Alex,


do you model air as compressible in this simulation?


As workaround to your question:

Did you try to reduce the under-relaxation factors of velocity and pressure?
In the seggregated solver options, you can find "Velocity Corrections: Acceptable Velocity Increase Rate". maybe reduce this rate too, in order to avoid large velocity magnitude jumps.




I don't recall a method to interact with the pressure field directly.



It might be possible to exploit the porous media solver, to increase the pressure via porous inertial resistance. However, i haven't tested whether the solver stays stable for such an inversed expected behavior.


this inertial resistance is calculated approximately like:
deltaP = - density * lossFactor * velocityMagnitude


you could try to create a fieldfunction which computes:
pressureIncrement /(density * velocityMag)


This would negate variable components and leave deltaP with the wanted pressure increment.


The pressure increment could be the difference between local pressure and inletpressure. somewhat unphysical...

Again.... i think it's likely that the solver becomes unstable for a negative loss factor.





Best regards,
Sebastian

[flotus1]

Thanks for the quick reply.

do you model air as compressible in this simulation?

Yes, using the ideal gas model. Assuming an incompressible fluid would fail to capture the filling process.

Did you try to reduce the under-relaxation factors of velocity and pressure?

I tried both decreasing and increasing them. Lower URF for the velocity leads to even slower convergence. Presumably because the initial shock from the changing pressure boundary condition takes longer to vanish.
Currently using 0.8 for velocity and 0.4 for pressure, which is about as good as it gets for my simplified test case.

In the seggregated solver options, you can find "Velocity Corrections: Acceptable Velocity Increase Rate". maybe reduce this rate too, in order to avoid large velocity magnitude jumps.

Sounds like a good idea. I tried changing these values even with extreme settings like these:
Velocity Corrections: Maximum Unlimited Velocity : 0.0 m/s
Velocity Corrections: Acceptable Velocity Increase Rate [<1] 0.01
But it does not seem to have any effect whatsoever
Any idea what I missed here?

I'll have to think about your suggestion concerning porous resistance. I would still be left with the problem of applying this correction only once before the first iteration of each time step. Guess that could be solved with a macro...

Edit: reconstruction gradients...
Setting them to zero slightly improved convergence behaviour. However if I understand the manual correctly this reduces the simulation to first order accuracy in space.

With reconstruction gradients
residuals_reconstruction_nonzeroed.png

reconstruction gradients zeroed
residuals_reconstruction_zeroed.png

[me3840]

From your residual plots it looks like you can drop the number of inner iterations considerably, are you monitoring another quantity that makes you think the timesteps take that long to converge?

Are you ramping the pressure through a field function?

If the solution overshoots that much it suggests your timestep is just too big.

You could also try using a stagnation inlet condition, that way instead of interpreting the velocity by the gradient the velocity can be derived, but I've never used it as the sole condition before.

[flotus1]

Sure, the number of inner iterations was deliberately set to a high value so I always get full convergence. The scope of this preliminary analysis is the slope of the residuals initially, i.e. the number of iterations until convergence is achieved / the residuals dropped enough.

Yes, I currently use a field function to supply the pressure value at the boundaries.

Reducing the time step size does not help. I could use a few less iterations, but overall the computational cost does not drop.

I tried all boundary conditions that let me adjust a pressure value. To no avail.

[me3840]

If you really want that level of convergence I would swap for the coupled solver then, it should need fewer of them.

STAR's coupled solver is fairly challenging to tune, but it has a lot of options in it. What settings did you try?

Make sure your mesh quality is superb, though it probably is if you're getting those low residual levels.

Do those extra 3-4 orders of magnitude you have there really make any difference in the engineering metrics?

[flotus1]

Again, this is an extremely simplified test case I am running here. Mesh quality will inevitably be worse with the actual geometry. That's why I am trying everything I can to improve convergence behavior.
I am not interested in getting the residuals to level out at round-off error levels. I just need to avoid 50+ inner iterations on the actual simulation. Hence my quest to improve convergence in a simplified test case that only has the transient pressure boundary condition as a challenging element, while everything else is a best-case scenario.

[me3840]

Okay, but you said you tried the coupled solver and it didn't work, what settings did you use? I would have expected it to do better tuned well.