-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
Summary of breakages when updating problems with conservation laws #952
Comments
|
There is no way we can auto-determine the value of the new parameter associated with a conservation law without having initial values for all pre-elimination species. |
If |
But in our case |
|
But doesn't that mean users will have to be told that if they use Catalyst they have to explicitly specify parameters to represent all initial conditions? We have no way of knowing a priori which unknowns will appear in conservation laws, and we wouldn't want a situation where we sometimes inject new parameters in the background and then expect users to know about them and switch to setting initial conditions using them... |
I might be misunderstanding, but weren't dependent parameters which were just expressions of other parameters? I.e. basically a way to write a commonly occurring parameter expression in a shorter form as a single symbol? I think this case is something else, i.e. a parameter which value is being initiated according to some other values. The funny thing is that everything works fine, it is just the case when the problem is updated that there is a problem, but the initial creation is all good. |
@TorkelE what Chris was suggesting is we need to make the initial conditions parameters too for each species appearing within a conservation law, and have users update those parameters to change initial conditions. |
i.e. @parameters A0
@species A(t)=A0 and then users update |
No user's don't need to do that, Catalyst would need to. Or @AayushSabharwal do we support initial values in dependent parameters? |
Yeah we do. @variables x(t)
@parameters p = x will initialize The reverse works as well. |
But wouldn't Catalyst adding parameters to represent initial conditions mean that any user using downstream functionality (like Doesn't it also mean that there are possibly large numbers of extra parameters hanging around for users working on higher level analyses (sensitivity analysis, etc)? This seems undesirable. |
Since using initial conditions as parameters like Aayush shows works, making a dependent parameter |
My understanding from @TorkelE is that when subsequently remaking a problem it won’t be correctly recalculated as described above. |
Okay so remake isn't tying into the initialization system properly. The docs for what should be happening is: https://docs.sciml.ai/ModelingToolkit/stable/tutorials/initialization/ Let's assume we have an ODE with states However, when you have a DAE you need to ensure consistent initialization, and so there's a nonlinear system that is built for that initialization. If you say x - 2 ~ 0
x + y - gamma ~ 0 that is then ran to give the initial conditions for If you say y - 2 ~ 0
x + y - gamma ~ 0 I.e. the user can specify the initial condition for When you then add x - 2 ~ 0
y - 2 ~ 0
x + y - gamma ~ 0 which is then a NonlinearLeastSquaresProblem that is solved before the DAE integration starts, the residual is checked to make sure the initialization is consistent. If So there's two things going on here. For one, What should then happen is that if Likewise though, I don't expect Likewise All of the same logic of course applies to the integrator type itself. Note that after callbacks, the DAE initialization has to be re-ran to check that there's always consistency at each step or error since having a non-consistent state is not recoverable by the solver. This is one of the reasons why MTK is going the route of more symbolic callbacks too, since then it can generate custom initializers for specific callbacks given the known equation changes. This then ends up being a really deep topic... which I think Catalyst can mostly avoid given the constrained use of DAEs it tends to have. In theory, all of Catalyst DAEs are linear constraints and so tearing always analytically solves them and so the deeper DAE stuff doesn't apply. Hopefully that's a better explanation of all of the behaviors there, and points to one missing feature in remake. |
Thanks, that is very helpful and would be a perfect solution for us. I’m fine with just telling users to use remake and not pushing the convenience direct updating anyways. Making the constraint equation that defines the conservation constant a dependent parameter sounds good — we plan to add dependent parameter support after we get V14 out and settled. |
Dependent parameters can only depend on other parameters. What semantics would
I'll try and come up with an API for that. It's really easy to get an implicit circular dependency with this stuff.
It's not exactly identical, since
I'll try and come up with a way to do this without turning it into a circular dependency. |
Bump, any updates on supporting parameters defined via initial conditions getting updated correctly? Could this be simplified by introducing a special notation to indicate the parameter is defined via an initial condition and not via a general value for a variable? i.e. |
SciML/ModelingToolkit.jl#2928 will enable solving for parameters during initialization |
Awesome, thanks! Is this for ODEs only or will it ultimately work with other system types too? |
Right now we only solve the initialization for ODEs. I'm not sure if there are additional concerns required when solving it for other systems. @ChrisRackauckas? |
We definitely need it for NonlinearProblems and SteadyStateProblems as they are both places conservation laws get used, and it would be nice for SDEs too (though not really high priority I'd say). I can't see a need for it with regards to jump problems right now since we don't support conservation law elimination there (and probably won't anytime soon as they aren't expected to generally offer performance benefits). |
SteadyStateProblems would use it because those use the ODEProblem. If they end up as a NonlinearProblem though it would be ignored since it should be inconsequential to the solution? For SDEs, there's a bit more to work out anyways. SDAEs are still a research topic with very little actually written about them. |
In our case, going through SDAEs shouldn't be a problem though, since Catalyst deals with conservation laws without going through the generation of algebraic equations. |
There are no DAEs here since the point is that a user supplies initial values for all species, including eliminated species that were moved to observables, and that is used to determine a parameter's value before any solve is being called (irregardless of equation type). The value of the parameter is then known and available for use in equations passed to the associated solver. For NonlinearProblems one can specify an initial guess via value mappings of unknowns right? That would be the place it would be nice to have the parameter calculated from that mapping (i.e. if users specify a mapping with all unknowns, even those that have been moved to be observables, it is used to generate the parameter value -- similar to how the value is generated from initial value mappings for ODEs). |
Yes, and that could be useful since starting with the conservation supported should keep it supported through the stepping. |
Exactly, hence why we'd like that use-case supported. |
So at this stage I am starting to be uncertain exactly what is intended to work and what is not intended to work. At least here is a summary of the tests I have broken, and which works and which do not work. There are definitely some oddities going on here.
I also have some general MTK tests, where
remake
actually works now (except that I thought that it wasn't meant to any longer).The text was updated successfully, but these errors were encountered: