Documentation page on how to access model properties

[TorkelE]

Not actually sure what to call this one, but this is the tutorial that goes through how to access stuff within a ReactionSystem.

• For a starter, it goes through basic stuff like species(rs).
• For now, I also put our main section on how accessing symbolic variables via the model (e.g. rs.X) works.
• There is also a bit on hierarchical models, i.e. the difference between get_species and species, and rs.submodelname.X.

[isaacsas]

Happy for you to merge after you've addressed my comments.

[isaacsas]

Suggested change

Previously we have described how the parameters and species (and [variables](@ref constraint_equations_coupling_constraints)) that Catalyst models contain are represented using so-called [*symbolic variables*](@ref introduction_to_catalyst) (and how these enable the forming of [*symbolic expressions*](@ref introduction_to_catalyst)). We have described how, during [programmatic modelling](@ref programmatic_CRN_construction), the user has [direct access to these](@ref programmatic_CRN_construction) and how this can be [taken advantage of](@ref programmatic_CRN_construction). We have also described how, during [DSL-based modelling](@ref dsl_description), the need for symbolic representation can be circumvented by [using `@unpack`](@ref dsl_advanced_options_symbolics_and_DSL_unpack) or by [creating an observable](@ref dsl_advanced_options_observables). However, sometimes, it is easier to *directly access a symbolic variable through the model itself*.

... the need for symbolic representation can be circumvented by [using `@unpack`](@ref dsl_advanced_options_symbolics_and_DSL_unpack) or by [creating an observable](@ref dsl_advanced_options_observables)...*.

I found this part of the paragraph confusing. Maybe separately just recall the ways to access a symbolic variable/parameter that have already been shown? (I'd leave out the observable stuff as I think it will just confuse the discussion.)

[TorkelE]

This was kind of written in the mind that we had a dedicated section on symbolic variables, but I agree that it might be a bit confusing now. I will try to reword/improve.

Ideally I'd still have a link to the observables (although maybe rather and example where it is used). For DSL-based models, in most cases, I think this is probably the best way to do it (i.e. if there is a specific quantity like this you are using, it probably should be an observable, in other situations @unpack might be better)

[TorkelE]

New section

[Direct accessing of symbolic model parameter and species](@id model_accessing_symbolic_variables)

Previously we have described how the parameters and species that Catalyst models contain are represented using so-called [symbolic variables](@ref introduction_to_catalyst) (and how these enable the forming of [symbolic expressions](@ref introduction_to_catalyst)). We have described how, during [programmatic modelling](@ref programmatic_CRN_construction), the user has [direct access to these](@ref programmatic_CRN_construction) and how this can be [taken advantage of](@ref programmatic_CRN_construction). I.e. here we declare the symbolic variables associated with a two-state model, and also creates the model programmatically.

using Catalyst
t = default_t()
@parameters k1 k2
@species X1(t) X2(t)

rxs = [
    Reaction(k1, [X1], [X2]),
    Reaction(k2, [X2], [X1])
]
@named rs = ReactionSystem(rxs, t)
nothing # hide

We have also described how, during [DSL-based modelling](@ref dsl_description), the need for symbolic representation can be circumvented by [using @unpack](@ref dsl_advanced_options_symbolics_and_DSL_unpack) or by [creating an observable](@ref dsl_advanced_options_observables). However, sometimes, it is easier to directly access a symbolic variable through the model itself.

[TorkelE]

Actually, didn't like how this turned out, especially since the same model is declare later. Now I use

Previously we have described how the parameters and species that Catalyst models contain are represented using so-called [*symbolic variables*](@ref introduction_to_catalyst) (and how these enable the forming of [*symbolic expressions*](@ref introduction_to_catalyst)). We have described how, during [programmatic modelling](@ref programmatic_CRN_construction), the user has [direct access to these](@ref programmatic_CRN_construction) and how this can be [taken advantage of](@ref programmatic_CRN_construction). We have also described how, during [DSL-based modelling](@ref dsl_description), the need for symbolic representation can be circumvented by [using `@unpack`](@ref dsl_advanced_options_symbolics_and_DSL_unpack) or by [creating an observable](@ref dsl_advanced_options_observables). However, sometimes, it is easier to *directly access a symbolic variable through the model itself*, something which we will describe here.

which is not that different from what we had originally. I think the best solution is to create a model creation example which illustrates this, and then simply link to that.