Open ranocha opened 1 month ago
I'd suppose that at such an early stage of this package, we don't need to care too much about backward compatibility. And users of the old version can adapt their code to the new version with little effort.
Well, the other argument in favor of the wrapping could be that is may look more clear for simple ODE problems. And if we make breaking changes, we can indicate it in the version number and we're fine.
Okay, let's try wrapping.
This is not as straightforward as hoped: We get problems with constructors like
PDSProblem(P, D, u0, tspan, p = NullParameters())
PDSProblem(prod_dest, u0, tspan, p = NullParameters())
since it is not clear how to differentiate the first form with the default argument for p
and the second form with the given p
- both have the same number of arguments and I don't see any obvious type restrictions we could use for dispatch (since we want to keep everything quite generic). We could consider imposing P::Function, D::Function
, but that makes it impossible to use custom callable structs that are no Function
s.
Thus, it looks like this has to be a breaking change. I see the following options:
Function
sWhich version do you prefer?
I'd opt for the first case: single function in all cases.
Right now, all algorithms compute first the production terms in one function call and the destruction terms (given the same states) in another function call directly afterward. However, it would be more efficient for some problems to have an API where the production and destruction terms are computed in a single function call.
For backward compatibility, we could wrap the two functions in one struct and call them one after the other. However, that would mean that we have to touch the out-of-place version a bit more (since we use some
if
statements in them). The in-place versions are fine since conservative and non-conservative systems are already separated.What do you think about this, @SKopecz?