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

Make model interface more well defined #295

Open
matt-graham opened this issue Dec 18, 2024 · 0 comments
Open

Make model interface more well defined #295

matt-graham opened this issue Dec 18, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@matt-graham
Copy link
Member

matt-graham commented Dec 18, 2024

At the moment to use a model with ParticleDA a series of methods must be defined which we document, dispatching on the type of the model object, which we don't require to be subtyped from any top-level abstract type, as well as an init function with a standard interface which returns an instance of the model given a dictionary of parameters (and number of parallel tasks to use run across threads). For models which have extra structure we define extra optional methods that can be implemented - this is used for models with a conditionally Gaussian structure at the moment to support using the locally optimal proposal.

To better signal what the expected interface is for different model types and also allow using packages such as RequiredInterfaces.jl and Interfaces.jl to allow testing an implementation respects the required interface as suggested by @giordano, it would be useful to define an abstract type hierarchy that models need to subtype from, for example something like

abstract type StateSpaceModel end
abstract type ConditionallyGaussianSSM <: StateSpaceModel end

We could also then have specific types for for example spatial models to support methods required for localised filters.

As an alternative as the models have a common substructure of

  1. an initial state distribution (initial state model)
  2. a state transition distribution (state transition model)
  3. a conditional observation distribution given current state (observation model)

we could instead define a type hierarchy for these underlying components and define models as structs which compose together these different components. I think this would allow a more Julia-esque interface with shorter generic method names which are disambiguated by types of arguments rather than the current very verbose but explicit method names, for example something like

abstract type InitialStateModel end
abstract type StateTransitionModel end
abstract type StateModel{I<:InitialStateModel, T<:StateTransitionModel} end
abstract type ObservationModel end
abstract type StateSpaceModel{S<:StateModel, O<:ObservationModel}

# get_state_dimension
dimension(state_model::StateModel)
# get_observation_dimension
dimension(observation_model::ObservationModel)
# get_state_eltype
eltype(state_model::StateModel)
# get_observation_eltype
eltype(observation_model::ObservationModel)
# sample_initial_state!
sample!(state_model::StateModel, rng::AbstractRNG)
# update_state_deterministic! + update_state_stochastic!
sample!(state::AbstractVector, state_model::StateModel, rng::AbstractRNG)
# sample_observation_given_state!
sample!(observation::AbstractVector, state::AbstractVector, observation_model::ObservationModel, rng::AbstractRNG)
# get_log_density_observation_given_state
log_density(observation::AbstractVector, state::AbstractVector, observation_model::ObservationModel)
# write_model_metadata
write(file::HDF5.File, model::StateSpaceModel)

Specific structure in the components could also then be indicated by the type hierarchy for example for models with Gaussian state noise / linear-Gaussian observation models

abstract type GaussianStateTransitionModel <: StateTransitionModel end
abstract type LinearGaussianObservationModel <: ObservationModel end
abstract type ConditionallyGaussianSSM{S<:GaussianStateTransitionModel, O<:LinearGaussianObservationModel} <: StateSpaceModel end
@matt-graham matt-graham added the enhancement New feature or request label Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant