Skip to content
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

Add CoupledSDEs system struct #202

Closed
reykboerner opened this issue Mar 13, 2024 · 6 comments · Fixed by #212
Closed

Add CoupledSDEs system struct #202

reykboerner opened this issue Mar 13, 2024 · 6 comments · Fixed by #212

Comments

@reykboerner
Copy link
Contributor

As discussed with @Datseris, we could add the possibility of defining an SDE system as a type of DynamicalSystem. This type would allow to add stochastic dynamics, and it would limit to CoupledODEs for vanishing noise.

Such a type already exists in CriticalTransitions.jl, where it is called StochSystem. We could migrate it here. It is motivated by the way one would commonly write down a fairly general SDE:

image

The struct is currently written as follows:

struct StochSystem
    f::Function
    pf::Parameters
    u::State
    σ::Float64
    g::Function
    pg::Parameters
    Σ::CovMatrix
    process::Any
end;

Things to discuss:

  • Should there be a field to specify the Jacobian (of the deterministic drift)?
  • Should DiffEq kwargs and solver options be specified as part of the system definition, like in CoupledODEs?
  • What should the SDE type be called? StochSystem, CoupledSDEs, ...?
@Datseris
Copy link
Member

i will review soon i will promise i m just a bit busy!!!

@Datseris
Copy link
Member

It should be called CoupledSDEs. Your outline is fine, but the structure needs more things.

First, we need to consider the symbolic aspect. This type should integrate with Modeling toolkit.jl. why do we need two separated parameter containers? Is it because we have a dedicated function for the noise term?

I am confused. Why do you need both σ and Pg?

Also, why do you need both a covariance matrix and a g function ? Doesn't the vector function g already contain all info including cross coupling...?

We could also allow the noise to be a vector of noises, one for each stare.

In general if we can simplify so that there aren't so many inputs that would be great. You can always add convenience constructors later if you want to place signa at a special place.

Lastly the type must satisfy the dynamical system API.have a look at the source code of CoupledODEs. It should show you everything you need I will help in the pr.

@oameye
Copy link
Member

oameye commented Apr 22, 2024

I started something in this direction in this PR. After, I finished the transition for CriticalTransitions.jl, the type CoupledSDEs can be moved to DynamicalSystemsBase.

@Datseris
Copy link
Member

I'd suggest to open the PR here directly. The PR you cited has 28 files changed, I won't be able to review that. Better to start something very focused here and simply parallel the CoupledODEs file.

@oameye
Copy link
Member

oameye commented Apr 25, 2024

I see your viewpoint. But I think for us it is better to work on a branch in Criticaltransitions.jl so that we can slowly understand what we need and first internally make some decisions. After this, we will open a PR where we introduce the code related to CoupledSDEs.

@oameye oameye mentioned this issue Jul 24, 2024
5 tasks
@oameye
Copy link
Member

oameye commented Jul 25, 2024

Hey @Datseris. I made a PR where we propose a structure. It addresses most of your questions/issues you raised. However, there is still ambiguity in the construction. I explain more at the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants