ODE and Discrete Function Types

struct ODEFunction{iip, specialize, F, TMM, Ta, Tt, TJ, JVP, VJP, JP, SP, TW, TWt, WP, TPJ, VJP_P, O, TCV, SYS, ID<:Union{Nothing, SciMLBase.OverrideInitData}, NLP<:Union{Nothing, SciMLBase.ODENLStepData}} <: SciMLBase.AbstractODEFunction{iip}

A representation of an ODE function f, defined by:

\[M \frac{du}{dt} = f(u,p,t)\]

and all of its related functions, such as the Jacobian of f, its gradient with respect to time, and more. For all cases, u0 is the initial condition, p are the parameters, and t is the independent variable.

Constructor

ODEFunction{iip, specialize}(
    f;
    mass_matrix = __has_mass_matrix(f) ? f.mass_matrix : I,
    analytic = __has_analytic(f) ? f.analytic : nothing,
    tgrad= __has_tgrad(f) ? f.tgrad : nothing,
    jac = __has_jac(f) ? f.jac : nothing,
    jvp = __has_jvp(f) ? f.jvp : nothing,
    vjp = __has_vjp(f) ? f.vjp : nothing,
    jac_prototype = __has_jac_prototype(f) ? f.jac_prototype : nothing,
    sparsity = __has_sparsity(f) ? f.sparsity : jac_prototype,
    paramjac = __has_paramjac(f) ? f.paramjac : nothing,
    vjp_p = __has_vjp_p(f) ? f.vjp_p : nothing,
    colorvec = __has_colorvec(f) ? f.colorvec : nothing,
    sys = __has_sys(f) ? f.sys : nothing
)

ODEFunction{iip,specialize}(f::ODEFunction; kwargs...)

Note that only the function f itself is required. This function should be given as f!(du,u,p,t) or du = f(u,p,t). See the section on iip for more details on in-place vs out-of-place handling.

The fully parameterized constructor can also change the specialization of an existing ODEFunction. It preserves the stored callable and fields, with keyword arguments taking priority. Converting to AutoSpecialize, AutoDespecialize, or AutoRespecialize widens the bounded initialization and nonlinear-step metadata types so model-specific metadata does not defeat compilation reuse. Construction from a raw callable retains concrete metadata types.

All of the remaining functions are optional for improving or accelerating the usage of f. These include:

• mass_matrix: the mass matrix M represented in the ODE function. Can be used to determine that the equation is actually a differential-algebraic equation (DAE) if M is singular. Note that in this case special solvers are required, see the DAE solver page for more details: https://docs.sciml.ai/DiffEqDocs/stable/solvers/dae_solve/. Must be an AbstractArray or an AbstractSciMLOperator.
• analytic(u0,p,t): used to pass an analytical solution function for the analytical solution of the ODE. Generally only used for testing and development of the solvers.
• tgrad(dT,u,p,t) or dT=tgrad(u,p,t): returns $\frac{∂f(u,p,t)}{∂t}$
• jac(J,u,p,t) or J=jac(u,p,t): returns $\frac{df}{du}$
• jvp(Jv,v,u,p,t) or Jv=jvp(v,u,p,t): returns the directional derivative$\frac{df}{du} v$
• vjp(Jv,v,u,p,t) or Jv=vjp(v,u,p,t): returns the adjoint derivative$\frac{df}{du}^∗ v$
• jac_prototype: a prototype matrix matching the type that matches the Jacobian. For example, if the Jacobian is tridiagonal, then an appropriately sized Tridiagonal matrix can be used as the prototype and integrators will specialize on this structure where possible. Non-structured sparsity patterns should use a SparseMatrixCSC with a correct sparsity pattern for the Jacobian. It must support the operations required by the selected differentiation and linear solver. The default is nothing, which means a dense Jacobian. Solvers may copy, allocate a similar object, or convert the prototype, so callers must not rely on object identity or aliasing.
• paramjac(pJ,u,p,t): returns the parameter Jacobian $\frac{df}{dp}$.
• vjp_p(Jpv,v,u,p,t) or Jpv=vjp_p(v,u,p,t): returns the parameter adjoint derivative $\frac{df}{dp}^∗ v$, i.e. the vector-Jacobian product with respect to parameters. This avoids materializing the full parameter Jacobian when only the VJP is needed (e.g. in adjoint sensitivity analysis). When not provided, falls back to paramjac or AD-based computation.
• colorvec: a column-color vector compatible with the selected sparse differentiation backend and the sparsity pattern of jac_prototype. This can accelerate Jacobian construction with finite differences or automatic differentiation. Defaults to nothing, which lets the selected backend compute coloring when required.

iip: In-Place vs Out-Of-Place

iip is the optional boolean for determining whether a given function is written to be used in-place or out-of-place. In-place functions are f!(du,u,p,t) where the return is ignored, and the result is expected to be mutated into the value of du. Out-of-place functions are du=f(u,p,t).

Normally, this is determined automatically by looking at the method table for f and seeing the maximum number of arguments in available dispatches. For this reason, the constructor ODEFunction(f) generally works (but is type-unstable). However, for type-stability or to enforce correctness, this option is passed via ODEFunction{true}(f).

specialize: Controlling Compilation and Specialization

The specialize parameter controls the specialization level of the ODEFunction on the function f. This allows for a trade-off between compile and run time performance. The available specialization levels are:

• SciMLBase.AutoSpecialize: this form performs a lazy function wrapping on the functions of the ODE in order to stop recompilation of the ODE solver, but allow for the prob.f to stay unwrapped for normal usage. This is the default specialization level and strikes a balance in compile time vs runtime performance.
• SciMLBase.FullSpecialize: this form fully specializes the ODEFunction on the constituent functions that make its fields. As such, each ODEFunction in this form is uniquely typed, requiring re-specialization and compilation for each new ODE definition. This form has the highest compile-time at the cost of being the most optimal in runtime. This form should be preferred for long-running calculations (such as within optimization loops) and for benchmarking.
• SciMLBase.NoSpecialize: this form fully unspecializes the function types in the ODEFunction definition by using an Any type declaration. As a result, it can result in reduced runtime performance, but is the form that induces the least compile-time.
• SciMLBase.FunctionWrapperSpecialize: this is an eager function wrapping form. It is unsafe with many solvers, and thus is mostly used for development testing.

For more details, see Specialization Levels.

Fields

The fields of the ODEFunction type directly match the names of the inputs.

More Details on Jacobians

The following example creates an inplace ODEFunction whose Jacobian is a Diagonal:

using LinearAlgebra
f = (du, u, p, t) -> du .= t .* u
jac = (J, u, p, t) -> (J[1, 1] = t; J[2, 2] = t; J)
jp = Diagonal(zeros(2))
fun = ODEFunction(f; jac, jac_prototype = jp)

The prototype declares Jacobian shape, element type, and structure. It must support the operations required by the selected differentiation and linear solver, including writes for an in-place jac and any multiplication, diagonal-shift, or factorization operations that solver performs. Solvers may copy, allocate with similar, or convert the prototype, so code must not rely on its object identity or aliasing behavior.

When jac_prototype is an AbstractSciMLOperator and jac is omitted, the constructor creates a Jacobian update using update_coefficients! for the in-place form and update_coefficients for the out-of-place form. Refer to the AbstractSciMLOperators documentation for more information on setting up time/parameter dependent operators.

Examples

Declaring Explicit Jacobians for ODEs

The most standard case, declaring a function for a Jacobian is done by overloading the function f(du,u,p,t) with an in-place updating function for the Jacobian: f_jac(J,u,p,t) where the value type is used for dispatch. For example, take the Lotka-Volterra model:

function f(du, u, p, t)
    du[1] = 2.0 * u[1] - 1.2 * u[1] * u[2]
    du[2] = -3 * u[2] + u[1] * u[2]
    return
end

To declare the Jacobian, we simply add the dispatch:

function f_jac(J,u,p,t)
    J[1,1] = 2.0 - 1.2 * u[2]
    J[1,2] = -1.2 * u[1]
    J[2,1] = 1 * u[2]
    J[2,2] = -3 + u[1]
    return
end

Then we can supply the Jacobian with our ODE as:

ff = ODEFunction(f; jac = f_jac)

and use this in an ODEProblem:

prob = ODEProblem(ff, ones(2), (0.0, 10.0))

Symbolically Generating the Functions

See the modelingtoolkitize function from ModelingToolkit.jl for automatically symbolically generating the Jacobian and more from the numerically-defined functions.

struct DynamicalODEFunction{iip, specialize, F1, F2, TMM, Ta, Tt, TJ, JVP, VJP, JP, SP, TW, TWt, TPJ, O, TCV, SYS, ID} <: SciMLBase.AbstractODEFunction{iip}

A representation of an ODE function f, defined by:

\[M \frac{du}{dt} = f(u,p,t)\]

as a partitioned ODE:

\[\begin{align*} M_1 \frac{du}{dt} = f_1(u,p,t) \\ M_2 \frac{du}{dt} = f_2(u,p,t) \end{align*}\]

and all of its related functions, such as the Jacobian of f, its gradient with respect to time, and more. For all cases, u0 is the initial condition, p are the parameters, and t is the independent variable.

Constructor

DynamicalODEFunction{iip, specialize}(
    f1, f2;
    mass_matrix = __has_mass_matrix(f) ? f.mass_matrix : I,
    analytic = __has_analytic(f) ? f.analytic : nothing,
    tgrad= __has_tgrad(f) ? f.tgrad : nothing,
    jac = __has_jac(f) ? f.jac : nothing,
    jvp = __has_jvp(f) ? f.jvp : nothing,
    vjp = __has_vjp(f) ? f.vjp : nothing,
    jac_prototype = __has_jac_prototype(f) ? f.jac_prototype : nothing,
    sparsity = __has_sparsity(f) ? f.sparsity : jac_prototype,
    paramjac = __has_paramjac(f) ? f.paramjac : nothing,
    colorvec = __has_colorvec(f) ? f.colorvec : nothing,
    sys = __has_sys(f) ? f.sys : nothing
)

Note that only the functions f_i themselves are required. These functions should be given as f_i!(du,u,p,t) or du = f_i(u,p,t). See the section on iip for more details on in-place vs out-of-place handling.

All of the remaining functions are optional for improving or accelerating the usage of f. These include:

• mass_matrix: the mass matrix M_i represented in the ODE function. Can be used to determine that the equation is actually a differential-algebraic equation (DAE) if M is singular. Note that in this case special solvers are required, see the DAE solver page for more details: https://docs.sciml.ai/DiffEqDocs/stable/solvers/dae_solve/. Must be an AbstractArray or an AbstractSciMLOperator. Should be given as a tuple of mass matrices, i.e. (M_1, M_2) for the mass matrices of equations 1 and 2 respectively.
• analytic(u0,p,t): used to pass an analytical solution function for the analytical solution of the ODE. Generally only used for testing and development of the solvers.
• tgrad(dT,u,p,t) or dT=tgrad(u,p,t): returns $\frac{∂f(u,p,t)}{∂t}$
• jac(J,u,p,t) or J=jac(u,p,t): returns $\frac{df}{du}$
• jvp(Jv,v,u,p,t) or Jv=jvp(v,u,p,t): returns the directional derivative $\frac{df}{du} v$
• vjp(Jv,v,u,p,t) or Jv=vjp(v,u,p,t): returns the adjoint derivative $\frac{df}{du}^∗ v$
• jac_prototype: a prototype matrix matching the type that matches the Jacobian. For example, if the Jacobian is tridiagonal, then an appropriately sized Tridiagonal matrix can be used as the prototype and integrators will specialize on this structure where possible. Non-structured sparsity patterns should use a SparseMatrixCSC with a correct sparsity pattern for the Jacobian. The default is nothing, which means a dense Jacobian.
• paramjac(pJ,u,p,t): returns the parameter Jacobian $\frac{df}{dp}$.
• colorvec: a color vector according to the SparseDiffTools.jl definition for the sparsity pattern of the jac_prototype. This specializes the Jacobian construction when using finite differences and automatic differentiation to be computed in an accelerated manner based on the sparsity pattern. Defaults to nothing, which means a color vector will be internally computed on demand when required. The cost of this operation is highly dependent on the sparsity pattern.

iip: In-Place vs Out-Of-Place

For more details on this argument, see the ODEFunction documentation.

specialize: Controlling Compilation and Specialization

For more details on this argument, see the ODEFunction documentation.

Fields

The fields of the DynamicalODEFunction type directly match the names of the inputs.

struct SplitFunction{iip, specialize, F1, F2, TMM, C, Ta, Tt, TJ, JVP, VJP, JP, WP, SP, TW, TWt, TPJ, O, TCV, SYS, ID<:Union{Nothing, SciMLBase.OverrideInitData}, NLP<:Union{Nothing, SciMLBase.ODENLStepData}} <: SciMLBase.AbstractODEFunction{iip}

A representation of a split ODE function f, defined by:

\[M \frac{du}{dt} = f_1(u,p,t) + f_2(u,p,t)\]

and all of its related functions, such as the Jacobian of f, its gradient with respect to time, and more. For all cases, u0 is the initial condition, p are the parameters, and t is the independent variable.

Generally, for ODE integrators the f_1 portion should be considered the "stiff portion of the model" with larger timescale separation, while the f_2 portion should be considered the "non-stiff portion". This interpretation is directly used in integrators like IMEX (implicit-explicit integrators) and exponential integrators.

Constructor

SplitFunction{iip, specialize}(
    f1, f2;
    mass_matrix = __has_mass_matrix(f1) ? f1.mass_matrix : I,
    analytic = __has_analytic(f1) ? f1.analytic : nothing,
    tgrad= __has_tgrad(f1) ? f1.tgrad : nothing,
    jac = __has_jac(f1) ? f1.jac : nothing,
    jvp = __has_jvp(f1) ? f1.jvp : nothing,
    vjp = __has_vjp(f1) ? f1.vjp : nothing,
    jac_prototype = __has_jac_prototype(f1) ? f1.jac_prototype : nothing,
    W_prototype = __has_W_prototype(f1) ? f1.W_prototype : nothing,
    sparsity = __has_sparsity(f1) ? f1.sparsity : jac_prototype,
    paramjac = __has_paramjac(f1) ? f1.paramjac : nothing,
    colorvec = __has_colorvec(f1) ? f1.colorvec : nothing,
    sys = __has_sys(f1) ? f1.sys : nothing
)

Note that only the functions f_i themselves are required. These functions should be given as f_i!(du,u,p,t) or du = f_i(u,p,t). See the section on iip for more details on in-place vs out-of-place handling.

All of the remaining functions are optional for improving or accelerating the usage of the SplitFunction. These include:

• mass_matrix: the mass matrix M represented in the ODE function. Can be used to determine that the equation is actually a differential-algebraic equation (DAE) if M is singular. Note that in this case special solvers are required, see the DAE solver page for more details: https://docs.sciml.ai/DiffEqDocs/stable/solvers/dae_solve/. Must be an AbstractArray or an AbstractSciMLOperator.
• analytic(u0,p,t): used to pass an analytical solution function for the analytical solution of the ODE. Generally only used for testing and development of the solvers.
• tgrad(dT,u,p,t) or dT=tgrad(u,p,t): returns $\frac{∂f_1(u,p,t)}{∂t}$
• jac(J,u,p,t) or J=jac(u,p,t): returns $\frac{df_1}{du}$
• jvp(Jv,v,u,p,t) or Jv=jvp(v,u,p,t): returns the directional derivative $\frac{df_1}{du} v$
• vjp(Jv,v,u,p,t) or Jv=vjp(v,u,p,t): returns the adjoint derivative $\frac{df_1}{du}^∗ v$
• jac_prototype: a prototype matrix matching the type that matches the Jacobian. For example, if the Jacobian is tridiagonal, then an appropriately sized Tridiagonal matrix can be used as the prototype and integrators will specialize on this structure where possible. Non-structured sparsity patterns should use a SparseMatrixCSC with a correct sparsity pattern for the Jacobian. The default is nothing, which means a dense Jacobian.
• W_prototype: a prototype matrix matching the type that matches the W matrix. For example, if the Jacobian is tridiagonal, and the mass_matrix is diagonal, then an appropriately sized Tridiagonal matrix can be used as the prototype and integrators will specialize on this structure where possible. Non-structured sparsity patterns should use a SparseMatrixCSC with a correct sparsity pattern for the W matrix. The default is nothing, which means a W of appropriate type for the jacobian and linear solver
• paramjac(pJ,u,p,t): returns the parameter Jacobian $\frac{df_1}{dp}$.
• colorvec: a color vector according to the SparseDiffTools.jl definition for the sparsity pattern of the jac_prototype. This specializes the Jacobian construction when using finite differences and automatic differentiation to be computed in an accelerated manner based on the sparsity pattern. Defaults to nothing, which means a color vector will be internally computed on demand when required. The cost of this operation is highly dependent on the sparsity pattern.

Note on the Derivative Definition

The derivatives, such as the Jacobian, are only defined on the f1 portion of the split ODE. This is used to treat the f1 implicit while keeping the f2 portion explicit.

iip: In-Place vs Out-Of-Place

For more details on this argument, see the ODEFunction documentation.

specialize: Controlling Compilation and Specialization

For more details on this argument, see the ODEFunction documentation.

Fields

The fields of the SplitFunction type directly match the names of the inputs.

Symbolically Generating the Functions

See the modelingtoolkitize function from ModelingToolkit.jl for automatically symbolically generating the Jacobian and more from the numerically-defined functions. See ModelingToolkit.SplitODEProblem for information on generating the SplitFunction from this symbolic engine.

IncrementingODEFunction{iip, specialize}(f)
IncrementingODEFunction{iip}(f)
IncrementingODEFunction(f)

Wrap an ODE model that supports solver-specific incrementing evaluations.

This is a thin AbstractODEFunction wrapper: calls and keyword arguments are forwarded directly to f, while iip records the mutation convention and specialize follows the SciML function specialization interface. It does not add derivative metadata or transform an ordinary ODE right-hand side into an incrementing one.

Low-storage Runge-Kutta solvers commonly call an in-place wrapped function as f(du, u, p, t, alpha, beta) and require it to compute du = alpha * F(u, p, t) + beta * du. The selected solver owns the exact extra call forms and semantics, so the model must implement every form that solver uses. Use IncrementingODEFunction{true}(f) or IncrementingODEFunction{false}(f) when optional arguments or multiple methods make arity-based in-place inference ambiguous.

See IncrementingODEProblem for the constructor that records the matching problem tag.

struct ODEInputFunction{iip, specialize, F, TMM, Ta, Tt, TJ, CTJ, JVP, VJP, JP, CJP, SP, TW, TWt, WP, TPJ, O, TCV, SYS, ID} <: SciMLBase.AbstractODEInputFunction{iip}

A representation of a ODE function f with inputs, defined by:

\[\frac{dx}{dt} = f(x, u, p, t)\]

where x are the states of the system and u are the inputs (which may represent different things in different contexts, such as control variables in optimal control).

Includes all of its related functions, such as the Jacobian of f, its gradient with respect to time, and more. For all cases, u0 is the initial condition, p are the parameters, and t is the independent variable.

ODEInputFunction{iip, specialize}(
    f;
    mass_matrix = __has_mass_matrix(f) ? f.mass_matrix : I,
    analytic = __has_analytic(f) ? f.analytic : nothing,
    tgrad= __has_tgrad(f) ? f.tgrad : nothing,
    jac = __has_jac(f) ? f.jac : nothing,
    control_jac = __has_controljac(f) ? f.controljac : nothing,
    jvp = __has_jvp(f) ? f.jvp : nothing,
    vjp = __has_vjp(f) ? f.vjp : nothing,
    jac_prototype = __has_jac_prototype(f) ? f.jac_prototype : nothing,
    controljac_prototype = __has_controljac_prototype(f) ? f.controljac_prototype : nothing,
    sparsity = __has_sparsity(f) ? f.sparsity : jac_prototype,
    paramjac = __has_paramjac(f) ? f.paramjac : nothing,
    colorvec = __has_colorvec(f) ? f.colorvec : nothing,
    sys = __has_sys(f) ? f.sys : nothing
)

f should be given as f(x_out,x,u,p,t) or out = f(x,u,p,t). See the section on iip for more details on in-place vs out-of-place handling.

• mass_matrix: the mass matrix M represented in the BVP function. Can be used to determine that the equation is actually a BVP for differential algebraic equation (DAE) if M is singular.
• jac(J,dx,x,u,p,gamma,t) or J=jac(dx,x,u,p,gamma,t): returns $\frac{df}{dx}$
• control_jac(J,du,x,u,p,gamma,t) or J=control_jac(du,x,u,p,gamma,t): returns $\frac{df}{du}$
• jvp(Jv,v,du,x,u,p,gamma,t) or Jv=jvp(v,du,x,u,p,gamma,t): returns the directional derivative $\frac{df}{du} v$
• vjp(Jv,v,du,x,u,p,gamma,t) or Jv=vjp(v,du,x,u,p,gamma,t): returns the adjoint derivative $\frac{df}{du}^∗ v$
• jac_prototype: a prototype matrix matching the type that matches the Jacobian. For example, if the Jacobian is tridiagonal, then an appropriately sized Tridiagonal matrix can be used as the prototype and integrators will specialize on this structure where possible. Non-structured sparsity patterns should use a SparseMatrixCSC with a correct sparsity pattern for the Jacobian. The default is nothing, which means a dense Jacobian.
• controljac_prototype: a prototype matrix matching the type that matches the Jacobian. For example, if the Jacobian is tridiagonal, then an appropriately sized Tridiagonal matrix can be used as the prototype and integrators will specialize on this structure where possible. Non-structured sparsity patterns should use a SparseMatrixCSC with a correct sparsity pattern for the Jacobian. The default is nothing, which means a dense Jacobian.
• paramjac(pJ,x,u,p,t): returns the parameter Jacobian $\frac{df}{dp}$.
• colorvec: a color vector according to the SparseDiffTools.jl definition for the sparsity pattern of the jac_prototype. This specializes the Jacobian construction when using finite differences and automatic differentiation to be computed in an accelerated manner based on the sparsity pattern. Defaults to nothing, which means a color vector will be internally computed on demand when required. The cost of this operation is highly dependent on the sparsity pattern.

iip: In-Place vs Out-Of-Place

For more details on this argument, see the ODEFunction documentation.

specialize: Controlling Compilation and Specialization

For more details on this argument, see the ODEFunction documentation.

Fields

The fields of the ODEInputFunction type directly match the names of the inputs.

struct DiscreteFunction{iip, specialize, F, Ta, O, SYS, ID} <: SciMLBase.AbstractDiscreteFunction{iip}

A representation of a discrete dynamical system f, defined by:

\[u_{n+1} = f(u,p,t_{n+1})\]

and all of its related functions, such as the Jacobian of f, its gradient with respect to time, and more. For all cases, u0 is the initial condition, p are the parameters, and t is the independent variable.

Constructor

DiscreteFunction{iip, specialize}(
    f;
    analytic = __has_analytic(f) ? f.analytic : nothing
)

Note that only the function f itself is required. This function should be given as f!(du,u,p,t) or du = f(u,p,t). See the section on iip for more details on in-place vs out-of-place handling.

All of the remaining functions are optional for improving or accelerating the usage of f. These include:

• analytic(u0,p,t): used to pass an analytical solution function for the analytical solution of the ODE. Generally only used for testing and development of the solvers.

iip: In-Place vs Out-Of-Place

For more details on this argument, see the ODEFunction documentation.

specialize: Controlling Compilation and Specialization

For more details on this argument, see the ODEFunction documentation.

Fields

The fields of the DiscreteFunction type directly match the names of the inputs.

struct ImplicitDiscreteFunction{iip, specialize, F, Ta, O, SYS, RP, ID} <: SciMLBase.AbstractDiscreteFunction{iip}

A representation of an discrete dynamical system f, defined by:

\[0 = f(u_{n+1}, u_n, p, t_{n+1}, \text{integ})\]

and all of its related functions, such as the Jacobian of f, its gradient with respect to time, and more. For all cases, u0 is the initial condition, p are the parameters, and t is the independent variable. integ contains the fields:

dt: the time step

Constructor

ImplicitDiscreteFunction{iip, specialize}(
    f;
    analytic = __has_analytic(f) ? f.analytic : nothing,
    resid_prototype = __has_resid_prototype(f) ? f.resid_prototype : nothing
)

Note that only the function f itself is required. This function should be given as f!(residual, u_next, u, p, t) or residual = f(u_next, u, p, t). See the section on iip for more details on in-place vs out-of-place handling.

All of the remaining functions are optional for improving or accelerating the usage of f. These include:

• analytic(u0,p,t): used to pass an analytical solution function for the analytical solution of the ODE. Generally only used for testing and development of the solvers.

iip: In-Place vs Out-Of-Place

For more details on this argument, see the ODEFunction documentation.

specialize: Controlling Compilation and Specialization

For more details on this argument, see the ODEFunction documentation.

Fields

The fields of the ImplicitDiscreteFunction type directly match the names of the inputs.