diff --git a/docs/src/getting-started.md b/docs/src/getting-started.md index 6cda02c4..14be978b 100644 --- a/docs/src/getting-started.md +++ b/docs/src/getting-started.md @@ -29,14 +29,14 @@ It provides: Two things to keep in mind: -1. **No top-level exports.** `using CTModels` loads the package but brings no symbols +- **No top-level exports.** `using CTModels` loads the package but brings no symbols into scope. Every symbol is accessed via its qualified path: ```julia CTModels.Building.state! # ✓ always works CTModels.Solutions.build_solution CTModels.Init.build_initial_guess ``` -2. **`PreModel → build → Model` pipeline.** An OCP is assembled incrementally on a mutable +- **`PreModel → build → Model` pipeline.** An OCP is assembled incrementally on a mutable `PreModel`, then frozen into an immutable `Model` by `build`. The `Model` is the object every downstream package (solver, initial-guess builder, serializer) consumes. diff --git a/docs/src/index.md b/docs/src/index.md index 4d72b47b..c5a58942 100644 --- a/docs/src/index.md +++ b/docs/src/index.md @@ -81,10 +81,10 @@ The core **optimal control model** is expressed via: In practice you typically: -1. Specify **time dependence** and **time models** (fixed or free final time, etc.). -2. Describe **state, control, and variable spaces**. -3. Provide **dynamics** and **objective** functions. -4. Add **constraints**, either programmatically or via a `ConstraintsDictType` dictionary. +- Specify **time dependence** and **time models** (fixed or free final time, etc.). +- Describe **state, control, and variable spaces**. +- Provide **dynamics** and **objective** functions. +- Add **constraints**, either programmatically or via a `ConstraintsDictType` dictionary. The numerical **solution** of an OCP is represented by: diff --git a/src/Building/name_validation.jl b/src/Building/name_validation.jl index 0a69da74..18eb2ca5 100644 --- a/src/Building/name_validation.jl +++ b/src/Building/name_validation.jl @@ -124,11 +124,11 @@ $(TYPEDSIGNATURES) Validate that a name and its components don't conflict with existing names. Performs comprehensive validation: -1. Name is not empty -2. Components are not empty -3. Name not in components (internal conflict) -4. No duplicates in components -5. No conflicts with existing names in other components (global uniqueness) +- Name is not empty +- Components are not empty +- Name not in components (internal conflict) +- No duplicates in components +- No conflicts with existing names in other components (global uniqueness) # Arguments diff --git a/src/Solutions/build_solution.jl b/src/Solutions/build_solution.jl index c2cc7ebe..218e367e 100644 --- a/src/Solutions/build_solution.jl +++ b/src/Solutions/build_solution.jl @@ -38,15 +38,15 @@ for memory efficiency. Otherwise, it uses `MultipleTimeGridModel` to store each Trajectory data (`X`, `U`, `P`, `path_constraints_dual`) can be provided in two formats: -1. **Matrix format**: `Matrix{Float64}` with dimensions `(n_points, n_dim)` - - Each row corresponds to a time point in the associated grid - - Each column corresponds to a component dimension - - Example: `X` is `(length(T_state), state_dimension(ocp))` - -2. **Function format**: `Function` that takes time `t::Float64` and returns a vector - - Allows analytical or pre-interpolated trajectories - - Function signature: `t -> Vector{Float64}` of appropriate dimension - - Useful for exact solutions or when data is already interpolated +- **Matrix format**: `Matrix{Float64}` with dimensions `(n_points, n_dim)` + - Each row corresponds to a time point in the associated grid + - Each column corresponds to a component dimension + - Example: `X` is `(length(T_state), state_dimension(ocp))` + +- **Function format**: `Function` that takes time `t::Float64` and returns a vector + - Allows analytical or pre-interpolated trajectories + - Function signature: `t -> Vector{Float64}` of appropriate dimension + - Useful for exact solutions or when data is already interpolated # Arguments