You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the main structure of CriticalTransitions.jl is the StochSystem, and the typical syntax for methods is function(sys::StochSystem, args; kwargs...).
A typical workflow for numerically studying critical transitions could look like this:
Investigate system properties (fixed points, stability, basins of attraction, flow field, quasipotential, instanton, ...)
Analyze the statistical properties of samples (mean transition path, residence time distribution/scaling, invariant measure, ...)
Relate these sample properties to the dynamical system properties (boundary crossing point, transition indicators, quasipotential height differences, ...)
(what else would be of interest?)
The StochSystem structure is convenient for points 1 and 2 of this workflow. To deal with sampling data in a unified and practical way, it could be useful to define new structures:
Trajectory and TrajectoryEnsemble
Transition and TransitionEnsemble (subtypes of Trajectory and TrajectoryEnsemble, respectively)
These structures could be abstract types with fields. For example, Transition.path could output the path as a matrix of size (D x N), where D is the system dimension and N the number of path points.
Functions for analyzing transition samples could then follow the general syntax function(tr::TransitionEnsemble, args; kwargs...) or function(sys::StochSystem, tr::TransitionEnsemble, args; kwargs...).
Would this be a good way to structure the functionality?
The text was updated successfully, but these errors were encountered:
Currently the main structure of CriticalTransitions.jl is the
StochSystem
, and the typical syntax for methods isfunction(sys::StochSystem, args; kwargs...)
.A typical workflow for numerically studying critical transitions could look like this:
The
StochSystem
structure is convenient for points 1 and 2 of this workflow. To deal with sampling data in a unified and practical way, it could be useful to define new structures:Trajectory
andTrajectoryEnsemble
Transition
andTransitionEnsemble
(subtypes ofTrajectory
andTrajectoryEnsemble
, respectively)These structures could be abstract types with fields. For example,
Transition.path
could output the path as a matrix of size(D x N)
, whereD
is the system dimension andN
the number of path points.Functions for analyzing transition samples could then follow the general syntax
function(tr::TransitionEnsemble, args; kwargs...)
orfunction(sys::StochSystem, tr::TransitionEnsemble, args; kwargs...)
.Would this be a good way to structure the functionality?
The text was updated successfully, but these errors were encountered: