search

SciML / ModelingToolkit.jl

An acausal modeling framework for automatically parallelized scientific machine learning (SciML) in Julia. A computer algebra system for integrated symbolics for physics-informed machine learning and automated transformations of differential equations
https://mtk.sciml.ai/dev/
Other
1.41k stars 204 forks source link

JumpSystem design discussion #307

Closed isaacsas closed 4 years ago

isaacsas commented 4 years ago

So all this seems to work

@parameters t k
@variables A(t) B(t) C(t) 

rate = k*A*B
affects = [A ~ A - 1, B ~ B-1, C ~ C-1]
crj = ConstantRateJump(rate,affects)
vrj = VariableRateJump(rate,affects)
maj = MassActionJump(k[1],[A=>1,B=>1],[A=>-1,B=>-1,C=>1])

Would it make sense to have a JumpSystem just take a list mixing these three types as its eqs? I guess this would rely on being able to generate functions from the rate and the affects specified within each of the *RateJump types, is there is simple way to do this currently?

I imagine later we might want a more mathematical looking way to specify these using Poisson RVs or measures that could be components in ODEs/SDEs, but that could presumably just sit on top of these.

ChrisRackauckas commented 4 years ago

I imagine later we might want a more mathematical looking way to specify these using Poisson RVs or measures that could be components in ODEs/SDEs, but that could presumably just sit on top of these.

Yes, you can see my final goal is to allow for saying that a variable is a Poisson random variable, or a Brownian motion, just write the differential equation, and make it a DESystem. Then DESystem would auto-detect the form and use this to generate JumpSystem, SDESystem, etc. Also make that automatically handle PDEs and allow for auto-discretizations, and then allow for analyzing and transforming these between each other. That's the grand goal of the package. What made things start working today was to not look directly at the goal but instead start building these independent systems, since indeed having these intermediates makes it much easier to reason about the right way to lower it to code.

Would it make sense to have a JumpSystem just take a list mixing these three types as its eqs?

Yes, this looks great.

I guess this would rely on being able to generate functions from the rate and the affects specified within each of the *RateJump types, is there is simple way to do this currently?

Not very well. The rate functions can easily be done with build_function today. The affect functions will need a tie-in so that we can add u = integrator.u preamble before the dereferencing phase. That's not hard to add, and I plan to add it quite soon.

isaacsas commented 4 years ago

Cool, I'll plan to open a PR to start working on this soon then. I'd like to get jumps settled too so we can switch the DEBio backend all at once to MT and then improve/update the API and interface there to allow users to more easily generate ReactionSystems. (My plan there is to create a DEBioV2 branch we can discuss breaking changes on -- the DSL and API functions will hopefully stay the same, modulo switching symbols and expressions to variables and operations, but I think we should abandon the monolithic generation of everything in the default DSL version...)

ChrisRackauckas commented 4 years ago

I agree that's a great direction to go.

isaacsas commented 4 years ago

Closed by https://github.com/SciML/ModelingToolkit.jl/pull/317#pullrequestreview-404672049