Hi, I have to admit I did not use that feature yet but EXT_ITER does not exist anymore. In steady single zone simulations just use ITER. Steady Multizone OUTER_ITER and INNER_ITER. In unsteady cases just put TIME_ITER up front. Maybe that already helps.

In case you have a minimal example please attach it and the name the code version it works with.

You can use git bisect to pinpoint the commit yourself, that should be the quickest and easiest solution.

best tobi

I think we lost this functionality around version 7 (at the time I did not know we had it) maybe because it was complicated to guarantee the right file outputs when the simulation is stopped this way, especially for discrete adjoint problems.
The poor mans version of this feature is to increase the file output frequency and kill the execution 🤷
Nevertheless, the mechanism to change the number of time iterations at runtime can still be found in CFluidDriver::Monitor, which is currently used by turbomachinery problems.
If someone wants to bring the feature back that would be a good place to start, although I think this type of runtime interaction is a bad investment, it would be better to use the python wrapper.

I haven't looked at the python wrapper in detail, we had previously tracked several properties which are not available in the conventional convergence tracker (such as Cmy) and used the stop file to obtain the data when appropriate.

We have considered increasing the save frequency, but there are several files which are not created at every save point; thereby forcing each "standard" run to become a "run to nearest save" then "resume for 1 time-step to get the actual output data". As the decomposition and some of the file writes take a significant amount of time, it is a non-starter for commercial applications.

We would switch back to v6 (which had the capability) but we need some of the other features in v7.

I'll take a look at the python wrapper. Thank you for your candor.

Can you describe a bit more the stopping strategy you want? The new output structure is much more flexible than before, and you can even use Cauchy criteria based on time averages (of pretty much any coefficient), with different windowing methods and so on.

I know updating versions can be a pain (even for us developers) but it is truly worth it in this case.

Being able to apply Cauchy criteria to any of the named parameters would be wonderful. I see that some of the options are present in the config_template; is there a list of name conversions somewhere? (i.e. "DRAG" -> CD, "Cmy" -> ?, and I assume TAVG_ applies an average over CONV_WINDOW_CAUCHY_ELEMS elements for the requested parameter; I see some at https://su2code.github.io/docs_v7/Custom-Output/, but it is listed as non-exhaustive)

Beyond that, there are some instances we run into where the solution parameter does not converge according to the Cauchy criterion but it is converged for our uses (pitching moment convergence can be a bit different from other forms of convergence; it can sometimes wander within a count). In those instances, we would like to be able to terminate the job without incurring the "wait until save and run it again" penalty.

Can you describe a bit more the stopping strategy you want? The new output structure is much more flexible than before, and you can even use Cauchy criteria based on time averages (of pretty much any coefficient), with different windowing methods and so on.

Does Cauchy criteria based on time averages only work for time-independent flows? Because it seems that WINDOW_START_ITER needs to be set in the section of TIME-DEPENDENT SIMULATION in the input .cfg file. Thank you.