Extending solvers

[thvoigtmann]

Suppose we want to implement a new type of equation that can be solved with the TimeDoublingSolver, but requires us to solve a different implicit equation at each time step. (The anharmonic model from the examples, or the beta-scaling equation would be examples for that.)

We'd want to reuse most of the code of the TimeDoublingSolver, but we will need to change:

• initialize_F_temp! (for short-time expansion of the function)
• initialize_integrals! (for short-time expansion of the integrals, optionally, since for example for the beta-scaling equation this is better done analytically)
• update_Fuchs_parameters! (for setup the new C1,C2,C3 for the implicit equation, or in fact whatever parameters we might need there)

and crucially

• update_F!

All of these except update_F! dispatch on equation::MemoryEquation, which is good, because we can extend for a new equation type.

Now, update_F! has signature (::TimeDoublingSolver, ::FuchsTempStruct, ::Int), and none of these types we'd like to change for a new equation type. (I ended up introducing a subtype of FuchsTempStruct for the beta-scaling equation, but that's another discussion point.) So semantically, this seems odd to me: what happens inside update_F! is tied to the equation that we solve, but the method's signature doesn't even encode it...

I would thus extend the signature of update_F! with ::MemoryEquation in the original code, which allows extending update_F! easily for the user. It would mean to also extend the signature of update_K_and_F! which calls update_F!

The update_K_and_F! has a ::MemoryKernel in its signature, but I think that is not the right way to distinguish: i could imagine wanting to re-use an existing memory kernel with a new type of equation.

[thvoigtmann]

(All this in the hope of couse that the compiler will optimize away unused variables in function calls...)

[IlianPihlajamaa]

Now, update_F! has signature (::TimeDoublingSolver, ::FuchsTempStruct, ::Int), and none of these types we'd like to change for a new equation type. (I ended up introducing a subtype of FuchsTempStruct for the beta-scaling equation, but that's another discussion point.) So semantically, this seems odd to me: what happens inside update_F! is tied to the equation that we solve, but the method's signature doesn't even encode it...

Very good catch, thank you! I will make the functions you mention dispatch on MemoryEquation instead.

The update_K_and_F! has a ::MemoryKernel in its signature, but I think that is not the right way to distinguish: i could imagine wanting to re-use an existing memory kernel with a new type of equation.

MemoryKernel is already an abstract type, so I think that does what you want? Or am I misunderstanding you

[thvoigtmann]

No, you're right with the MemoryKernel. I just wanted to point out that a new equation to be solved cannot be distinguished by it having a different MemoryKernel subtype. But it will have a different MemoryEquation.

[IlianPihlajamaa]

Ahh yes, indeed!

[IlianPihlajamaa]

I just changed it.

I think the original motivation for not dispatching update_F on the type of equation was that I thought any equation would be solved by the C1*F = -K[F]*C2 + C3 system, so that only the update_Fuchs_parameters! function had to be overloaded.