-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic implementation of a multicomponent Datatype class #399
Comments
To summarise the state of the development branch: We have an implementation that derives from
The implementation is a bit hacky and there are a few minor pitfalls. But with a bit of documentation, I believe it works well enough. In particular, with the above So we satisfy most of the requirements already. The main question is how far this should go. So, to conclude: Should we merge the current state now so that @lisawim can use it for the DAE stuff and worry about how we can streamline some other stuff with this later? Or does anybody want this to be more thorough now? |
Can you also replace the Not sure you need to include the |
I would like to have a look at it during the week-end, especially since I'm not sure we still need to overload the So you can merge it already if @lisawim wants to work with those classes for the DAE sweeper (could also allow to see other non anticipated pitfalls), and just let this issue open so we can continue exploring. Well defining a generic multi-component dataclass could allow to have generic implementation of the End goal, this would greatly ease the usage and development of pySDC for additional problems (in particular for benchmarks ...) |
That's already done on the development branch. |
In any case, if we do this and if this actually replaces the IMEX mesh, we'd probably need more documentation to the new classes. |
Does someone say "documentation"? At this moment I'd be fine with merging the |
I am wondering where we should stop using this. So far, I was only thinking about integration-specific labels for the components, but why stop there? With this it is very easy to put tailored meshes in problems. For instance, in van der Pol, we have variables
I don't really care for doing this now. But I think we should consider this when adding problems in the future. However, when having multiple implementations regarding integration, this is dangerous. I am not sure if we can "stack" the current |
I like that! Yet another dirty code where I did not find a better way to handle this. This would be great to have! |
Such stacking of components could be very interesting for different cases, I like the idea! For DAEs, it would also be interesting to stack the different components. Thinking of SDC for semi-explicit DAEs, the right-hand side can also be separated into implicit and explicit parts, therefore we would get something like
that requires stacking of |
To follow up on the discussion started in 04fdedc#r138624434, @brownbaerchen @lisawim (and also centralize all that have been done on this topic, don't hesitate to complement the description ...)
Workspace dev branch : https://github.com/brownbaerchen/pySDC/tree/multicompmeshv3
Current testing : https://github.com/brownbaerchen/pySDC/blob/multicompmeshv3/pySDC/tests/test_datatypes/test_multicomponent_mesh.py
Requirements :
Some preliminary works (some time ago ...) :
The text was updated successfully, but these errors were encountered: