dummy solver

[joglekara]

Reason a: Adding a dummy solver is useful in cases where time/depth integration is not an explicit/implicit additive time-step such as for exponential integrators. Reason b: This also allows for a custom update (even if explicit etc.) in case the user is not yet ready to merge it in as a true SolverTemplate subclass.

As a use-case, I use it in a couple of projects for both reason (a) and (b)

[Zymrael]

Operatively the method step should be agnostic as to how x_sol is produced: the only thing fixed is the recipe i.e. we use to current state x(t), vector field f, time increment dt and potentially auxiliary inputs such as previous evaluations or states. So this should take care of the additive aspect; we are not locked into any specific way to modify the state.

In terms of explicit/implicit: subclassing Dummy as Euler makes it an explicit method. Is this intended (i.e. are we expecting new WIP solver additions to be mostly explicit? It would seem perhaps more appropriate to have two different "dummy" or subtemplates for base explicit / implicit solvers that method developers can subclass or modify directly to have an easy access point into the torchdyn ecosystem. Thoughts? @massastrello @fedebotu

Also it seems some of the tests are not passing

Unable to find installation candidates for dgl (0.8.0.post1)

it is probably time to update some of those dependencies.

[Zymrael]

@joglekara check if the new templates under solvers.templates are useful for your use case. You should be able to use the new BaseExplicit in the same way you used the proposed Dummy.

[joglekara]

Yeah makes sense to me that this is actually a more general base class.

And yes, this implementation works for me. Thanks!