Replies: 8 comments 46 replies
-
When we first added FEniCS we needed to rewrite the sweeper and transfer classes, because now we had a mass matrix. If you don't have a mass matrix, those classes are easier to read and digest (and much closer to the literature). This is why we decided against a default |
Beta Was this translation helpful? Give feedback.
-
After thinking about it on a (long ...) train travel, here are some propositions. Mass-matrixAdd it by default to define the problem and define a base method IMEXDon't split since some application may consider applying implicit sweep to a non-linear term, or a time-dependent Additionally, the IMEX sweep could be added to the core modules, close to the base sweeper class that would contains both explicit and implicit implementations (and just testing the QDelta matrix to choose which one to use). That way, for one given application, only datatype and problem classes implementation is required, and the rest is only the correct choice of core classes and parameters already provided by pySDC core. Generic solver for implicit sweepAdd a generic with Generic ODE solver for
|
Beta Was this translation helpful? Give feedback.
-
Thanks a lot @tlunet! Let me try to comment one by one:
|
Beta Was this translation helpful? Give feedback.
-
I have no idea about mass matrices, so I can't give any comments on that. I do however like the idea of implementing IMEX on a more basic level. In particular, I would like to have a function like
which would in the case of IMEX return the sum of the two rhs evaluations and in the implicit sweeper just the implicit part and so on. This would allow to have a bit more abstraction in the sweeper classes. For instance, you wouldn't need to overload the The other place where this is useful is the scipy stuff. There you need to supply something that evaluates the full rhs. Ofc naming it "fully_implicit" may not make sense, since in this case "fully_explicit" is probably closer to the truth, but whatever. We can also just implement a function like this for the scipy reference solution stuff, if @pancetta wants to keep the non-imex sweepers a bit more simple, though. |
Beta Was this translation helpful? Give feedback.
-
So ... it appears that implementing those generic methods for problem classes need also a rework of the datatype classes, with the introduction of a base interface for Here is a first draft that tries to solve those issues : https://github.com/Parallel-in-Time/pySDC/blob/847e8ca1491df1076aff9c61768245ff940101a9/pySDC/playgrounds/datatypes/draft.py. I'm slowly checking how the current class could be translated and used into this new structure. Let me know if you see any issue and supplementary test I could try. @pancetta : for some reason I don't understand yet, it seems that we don't need the complicated approach to subclass |
Beta Was this translation helpful? Give feedback.
-
Can you please test parallel code, too? E.g. distributed arrays with a communicator, computing a norm or so. |
Beta Was this translation helpful? Give feedback.
-
So, we need different communicators for different instances of data. One |
Beta Was this translation helpful? Give feedback.
-
Bottom line: I don't see the benefit of rewriting the data types yet again. If the way you propose it faster, I'm on board. If not, I'd rather leave it like that, because we have so many open issues, even without touching the data types. |
Beta Was this translation helpful? Give feedback.
-
Following a post by @brownbaerchen in #244 (comment) , the current interface for
Problem
class in pySDC is as follow :Looking at different current problem implementations, here are some ideas
apply_mass_matrix(self, u)
as an identity operator onu
(since most problem don't have a mass matrix) and suggest to redefine it in a children class using, for instance, FEM.u_exact(self, t, u_init=None, t_init=None)
as a standard method using the scipy reference solution for IVP, and allow it to be redefined for problem that have a simpler exact solutionsolve_system(self, rhs, factor, u0, t)
as a base method to the problem class, with a generic implementation of a solution of the (non)-linear systemu-factor*f(u,t) = rhs
using the (very generic) Newton-Krylov solver of scipy, allow it to be redefined for problems that have a simpler way to solve this (e.g for linear problems) or even for problem that don't allow any implicit solve (and use a custom ImplicitNotAllowedError).📜 The change on
apply_mass_matrix
andsolve_system
would facilitate the binding with dedalus V3, as those are two main components required by dedalus time-integrators ...Any comment/suggestion on that @pancetta @brownbaerchen ?
Beta Was this translation helpful? Give feedback.
All reactions