[cwl]

Hi everyone!

If one needs to monitor solution convergence during the run and stop it automatically based on asymptotic behavior of some monitor (Pressure Drop for example) for the last T seconds - he surely can use Asymptotic Stopping Criteria or Asymptote Update Event with sample count (which cannot be Parameter or Report or Field Function) set to T/TimeStep.
Which works perfectly. If time step is constant.

But how can that be implemented in case of very variable time step? - The amount of time steps for T seconds can be very different in this case.

[LuckyTran]

It checks for just the sequence and if it is asymptotic in time, which works for 99% of users. You just need to specify a large enough number of steps to check.

Actually even steady calculations (asymptotic vs iteration) has the same issue. Each iteration in each cell doesn't advance the solution by the same Flow Courant number. If you think this approach doesn't make sense for variable time-step sizes, then it wouldn't make sense either vs iteration.

An asymptotic monitor is not a replacement for a temporal derivative and should not be interpreted as such. If you want to monitor temporal derivatives, then make that monitor.

[cwl]

Thank you, but that's not what I meant %)

What I mean is: there is a fixed user-input-dependent (non parametric etc) "Number of Samples" in both Asymptotic Stopping Criteria and Asymptote Update Event.

So let's say I want to consider solution converged if that kind of criteria is satisfied for the last T seconds.

If time step is constant - I just set Number of Samples to manually calculated T/Time Step.

But if time step is very variable (let's say from 1E-6 to 1E-3) - I do not see they way to check convergence for the certain amount of physical time.

[fluid23]

I think what Lucky suggested was to make a report of the time derivative of your parameter (pressure drop) then setup a monitor and stopping criteria based on that, or do I misunderstand the problem?

[cwl]

Might be a good option, but that is not the solution i'm afraid.

Time derivative convergence - again can be monitored (in stopping criteria or update event) only for certain amount of time steps, which in case of variable time step can be an unknown range of time - which is the problem.

Also convergence is not neccerilly about time derivative, the monitored value (like pressure drop) is ok to be oscillating within some small range with any time derivative values (drpending on oscillations frequency and resolved time step).

[LuckyTran]

My remark about temporal derivatives is due to the fact that a well-bounded oscillating function will have an envelope corresponding to the lowest frequency characteristics of the temporal derivative which you can obtain by taking an FFT (in Star). But that would mean you are calculating (or trying to calculate temporal derivatives).

If your time-step size varies from 1e-06 to 1e-03 so wildlly that you have no idea what order of magnitude in physical time is elapsed, then you have bigger problems (honestly shouldn't even be using variable time-steps).

I don't get why you can't just use a check make a plot of the monitor vs time and retrieve the physical time from there. Does it really matter if the corresponding time is 1 second versus 1.0159 seconds for the purpose of checking convergence? I don't understand why anyone would need that level of precision if they're not trying to retrieve the temporal derivatives.

Furthermore, there isn't any deterministic boolean logic you can actually create a criteria from. Your criteria is something is asymptotic for exactly 2 seconds... But what if your simulation results in solutions at a physical time of 1.98764 seconds and 2.01654 seconds? Is your criteria now at least 2 seconds or less than 2 seconds? It doesn't work because as soon as you relax it, any interval that is greater/less-than will either always satisfy it or always violate it you now have a null criteria. And if your simulation returns exactly a time of exactly 2 seconds, well then it is a non-issue because we already know how much time has been simulated.


All of this is to say that: it's not that no one has thought of this case before and hasn't tried it. It just doesn't work the way you are imagining it to work.

[cwl]

If your time-step size varies from 1e-06 to 1e-03 so wildlly that you have no idea what order of magnitude in physical time is elapsed, then you have bigger problems

I know what you mean, but the explanation is quite simple - just a simple static mixer simulation template (including Filters, Dynamic Queues, Tags etc) in which physical time of process as well as time step (ok, not from 1e-6 but from 1e-4 to 1e-2) might depend on some physical dimensions (length, diameter of a mixer) and boundary conditions (vol. flow at inlet).

Such an example already can have varying time step for different inputs.

I don't get why you can't just use a check make a plot of the monitor vs time and retrieve the physical time from there.

Manually? - Nope, the computer should do the job automatically, especially in a batch mode running numerous simulations.

Does it really matter if the corresponding time is 1 second versus 1.0159 seconds for the purpose of checking convergence?

Surely it does not. The aim is to check the convergence for (approximately) last T seconds, not the fixed amount of time steps which depends on average time step.

Your criteria is something is asymptotic for exactly 2 seconds... But what if your simulation results in solutions at a physical time of 1.98764 seconds and 2.01654 seconds? Is your criteria now at least 2 seconds or less than 2 seconds?

The criteria is: monitored value has not been changing for more than X% over the last T seconds.
If T is for example 5 seconds - than physical time would be not less than 5 seconds.

It just doesn't work the way you are imagining it to work.

Checking the convergence automatically for certain amount of time but not time steps?
Me is very confused what's so special about it, it looks like having perfect sense to me