Tight coupling should fail if it does not converge

[drewj-usnctech]

In working on some tight coupling analysis, I keep finding myself unsure if a simulation actually converged or not. If the job does not error nor exit with a non-zero exit code, the implication is that there were no errors and my tight coupled analysis converged. But, instead, I need to search through the log file for lines like

[warn] Tight coupling iterations for c00n00 have not converged! The maximum number of iterations, 10, was reached.

And, since the simulation still goes through it's various EOC / EOL steps, I'm left to assume that the operator would progress forward in time, doing more tight coupling iterations that likely won't succeed. Or, in the worst case, they are based on compositions determined by depleting unconverged fields. Either way, the overall simulation results are wrong. And, especially for tight coupled simulations, this can mean a good amount of engineering and/or computational time has been wasted.

[keckler]

At the very least, this should be an option that one can set.

[jakehader]

I agree with @keckler that we should implement a setting that will fail on non convergence. Would you be able to support a PR @drewj-usnctech?

[albeanth]

Agreed. It's a good option to have.

Related: #1245

[onufer]

i agree it should be the option, perhaps the default option.
would prefer to to retain the old capability to continue. (potentially specifying non-default for the setting) for more loosely coupled systems its usually not that far from converged and torpedoing the whole run is not great.

@drewj-usnctech , have tried making CONF_TIGHT_COUPLING_MAX_ITERS a very large number like 100? internally we have it set to higher than the default of 4. in this case you would know when it was having trouble converging since it would take forever (if you had it be 100 or so)

another option could be to change the default to something very high

[onufer]

i would also add that each output has a
[info] ----- Final Warning Count --------
table and these should be reviewed after the run. anything with runlog of warning or higher will appear, so you dont need to grep the whole output for the warning message, just review the table.

(though perhaps the table should be warning rather than info ; )