Do we now plan to make substeps default to true or false with v3.0?

This is probably similar to what we are currently discussing in #1690. IIRC the current default is true. But this would - in many cases - directly trigger an error message in the current state.

Going for some kind of auto option is probably complicated, because determining whether we should use substeps="true" or substeps="false" based on the acceleration scheme is tricky on the technical level. Therefore, I would vote for substeps="true", because we want to prioritize waveform iterations with exchange of substeps. This will require some UX compromises and manual labor until quasi Newton is 100% working, but I think this is ok.

Another idea, not sure if it is a good one: we could also add an additional check and only trigger the error above, if we detect that the user actually performed substeps. I guess this would bypass the error for most users, but it also makes the implementation more complicated, harder to test and the behavior does not solely depend on the configuration, but also on the runtime.

Another idea, not sure if it is a good one: we could also add an additional check and only trigger the error above, if we detect that the user actually performed substeps. I guess this would bypass the error for most users, but it also makes the implementation more complicated, harder to test and the behavior does not solely depend on the configuration, but also on the runtime.

I agree and share the concerns. In general, sounds too complicated to me.

Going for some kind of auto option is probably complicated

Agree, let's not do this here.

I see the situation as follows:

• With v3.0, some waveform iteration will be functional and we will have many important building blocks in the backend ready. But some important features will not yet be supported, such that true as default would lead to many errors and slowly all users will add substeps="false" to their configuration without even thinking about it. So false as default might be better.
• Eventually in some v3.x waveform iteration will be functional including all features. Then, defaulting to true would be better.
• Can / should we change the default behavior in a minor release? I think we did similar things in the past already. We also improve features in minor releases. I think it is not uncommon to do that.

So, I would vote for false now and true eventually.

To the extent I understand the situation:

• Currently, typical FSI scenarios use subcycling and IQN. This still remains supported with the current (v2) limitations (effectively no time interpolation applied).
• The term "subcycling" is already used to describe something different, so we should definitely change it in the error messages. I got a mini heart attack from thinking that at least half of our users will be affected by disabling subcycling.
• We are adding time interpolation, but it will not be as good as it could be till later in the v3.x release cycle. But we still need to explicitly disable half-baked issues, which then makes sense to disable by default.

• Can / should we change the default behavior in a minor release? I think we did similar things in the past already. We also improve features in minor releases. I think it is not uncommon to do that.

As far as I see it, we should document the option already with its limitations and plans, and later advertise the "now time interpolation supports X, set Y to use it" and use it in the tutorials. It will be a new feature.

I would vote to stick to the policy of not changing the default in a minor release. We can guide users to explicitly switch something on with different ways (documentation, tutorials, warnings).

Let's set the option to false and keep it like that.

What would be the downside of asking the user to explicitly use the new features when available?

@MakisH mostly agree with the following two comments:

• Currently, typical FSI scenarios use subcycling and IQN. This still remains supported with the current (v2) limitations (effectively no time interpolation applied).

I would say a typical FSI scenario uses no subcycling (see our tutorials). Generally subcycling may lead to numerical problems, if you don't do it right. I you know about users that (consciously) use subcycling, please let me know, because these might be great application cases for my thesis 😏

I would vote to stick to the policy of not changing the default in a minor release. We can guide users to explicitly switch something on with different ways (documentation, tutorials, warnings).

Let's set the option to false and keep it like that.

What would be the downside of asking the user to explicitly use the new features when available?

Ideally we would like to exchange substeps as the default option as soon as everything is working, because it would finally result in the behavior of subcycling that a user would also expect: I perform substeps and the data also arrives on the other side. Until then (half-baked situation) defaulting to false makes a lot of sense, but when everything is ready I think defaulting to true would cause the least pain for users. This would also help us that the feature is actually regularly used and tested (not like other features that are rarely used and where we lack experience and test coverage).

I'm not sure how far we are stretching the basic principles of semantic versioning, but if possible, I would also like to relax a bit and go change the default from false to true in some 3.x release as proposed by @uekerman.

@MakisH mostly agree with the following two comments:

• Currently, typical FSI scenarios use subcycling and IQN. This still remains supported with the current (v2) limitations (effectively no time interpolation applied).

I would say a typical FSI scenario uses no subcycling (see our tutorials).

hmm... true. None of our tutorials (OpenFOAM cases) currently uses subcycling. We do need a tutorial/test case for it!

Depending on the order of merging: If we merge #1732 first, I can also reduce the diff of this PR here quite a bit and remove substep="false" at several places.

@uekerman can you take a look again? Changes are trivial. I think it generally makes sense introducing this error message. It does not matter what the default value of substeps is as both options are generally allowed and only some configurations are valid. We should merge now, because what's merged is merged and every open PR is a possible integration problem in the future ;)

#1732 is related to this one, but still has some minor problems and needs more time.

The error message makes sense to me (user perspective), thanks!

Let's keep the substeps="false" in most tests despite being the default. Doesn't hurt and make things explicit

Well, the nice thing about using the default in the config is that it will also automatically change, if we change the default. This also makes sure that the tests are aligned what most of our users are likely to do. We can remove the substeps="false" or keep it as it is. In the end it's not worth the discussion in my opinion.