|
1 | 1 | # How-to Guide 1: Construct and Run a Model
|
2 | 2 |
|
3 |
| -This how-to guide pairs nicely with Tutorial 4: Create a Model and Tutorial 6: Create a Model with Composite Components, and serves as a higher-level version and refresher for those with some experience with Mimi. If this is your first time constructing and running a Mimi model, we recommend you start with Tutorial 4 (and Tutorial 6 if you are interested in composite components), which will give you more detailed step-by step instructions. |
| 3 | +This how-to guide pairs nicely with [Tutorial 4: Create a Model](@ref) and [Tutorial 6: Create a Model Including Composite Components](@ref), and serves as a higher-level version and refresher for those with some experience with Mimi. If this is your first time constructing and running a Mimi model, we recommend you start with Tutorial 4 (and Tutorial 6 if you are interested in composite components), which will give you more detailed step-by step instructions. |
4 | 4 |
|
5 | 5 | ## Defining Components
|
6 | 6 |
|
@@ -48,13 +48,13 @@ The API for using the fourth argument, represented as `t` in this explanation, i
|
48 | 48 |
|
49 | 49 | To access the data in a parameter or to assign a value to a variable, you must use the appropriate index or indices (in this example, either the Timestep or region or both).
|
50 | 50 |
|
51 |
| -By default, all parameters and variables defined in the `@defcomp` will be allocated storage as scalars or Arrays of type `Float64.` For a description of other data type options, see How-to Guide 4: Work with Timesteps, Parameters, and Variables |
| 51 | +By default, all parameters and variables defined in the [`@defcomp`](@ref) will be allocated storage as scalars or Arrays of type `Float64.` For a description of other data type options, see How-to Guide 5: Work with Parameters and Variables |
52 | 52 |
|
53 | 53 | ### Composite Components
|
54 | 54 |
|
55 | 55 | Composite components can contain any number of subcomponents, **which can be either leaf components or more composite components**. To the degree possible, composite components are designed to operate in the same way as leaf components, although there are a few necessary differences:
|
56 | 56 |
|
57 |
| -- Leaf components are defined using the macro `@defcomp`, while Composite components are defined using `@defcomposite`. Each macro supports syntax and semantics specific to the type of component. |
| 57 | +- Leaf components are defined using the macro [`@defcomp`](@ref), while Composite components are defined using [`@defcomposite`](@ref). Each macro supports syntax and semantics specific to the type of component. |
58 | 58 |
|
59 | 59 | - Leaf components support user-defined `run_timestep()` functions, whereas composites have a built-in `run_timestep()` function that iterates over its subcomponents and calls their `run_timestep()` function.
|
60 | 60 |
|
@@ -103,9 +103,9 @@ Now we construct a composite component `MyCompositeComponent` which holds the tw
|
103 | 103 | end
|
104 | 104 | ```
|
105 | 105 |
|
106 |
| -The `connect` calls are responsible for making internal connections between any two components held by a composite component, similar to `connect_param!` described in the Model section below. |
| 106 | +The `connect` calls are responsible for making internal connections between any two components held by a composite component, similar to [`connect_param!`](@ref) described in the Model section below. |
107 | 107 |
|
108 |
| -As mentioned above, conflict resolution refers to cases where two subcomponents have identically named parameters, and thus the user needs to explicitly demonstrate that they are aware of this and create a new external parameter that will point to all subcomponent parameters with that name. For example, given leaf components `A` and `B`: |
| 108 | +As mentioned above, conflict resolution refers to cases where two subcomponents have identically named parameters, and thus the user needs to explicitly demonstrate that they are aware of this and create a new shared model parameter that will point to all subcomponent parameters with that name. For example, given leaf components `A` and `B`: |
109 | 109 |
|
110 | 110 | ```julia
|
111 | 111 | @defcomp Leaf1 begin
|
@@ -161,21 +161,29 @@ add_comp!(m, ComponentA)
|
161 | 161 | add_comp!(m, ComponentA, :GDP)
|
162 | 162 | ```
|
163 | 163 |
|
164 |
| -The first argument to `add_comp!` is the model, the second is the name of the ComponentId defined by `@defcomp`. If an optional third symbol is provided (as in the second line above), this will be used as the name of the component in this model. This allows you to add multiple versions of the same component to a model, with different names. |
| 164 | +The first argument to [`add_comp!`](@ref) is the model, the second is the name of the ComponentId defined by [`@defcomp`](@ref). If an optional third symbol is provided (as in the second line above), this will be used as the name of the component in this model. This allows you to add multiple versions of the same component to a model, with different names. |
165 | 165 |
|
166 |
| -The `add_comp` function has two more optional keyword arguments, `first` and `last`, which can be used to indicate a fixed start and/or end time (year in this case) that the compnonent should run for (within the bounds of the model's time dimension). For example, the following indicates that `ComponentA` should only run from 1900 to 2000. |
| 166 | +The [`add_comp!`](@ref) function has two more optional keyword arguments, `first` and `last`, which can be used to indicate a fixed start and/or end time (year in this case) that the compnonent should run for (within the bounds of the model's time dimension). For example, the following indicates that `ComponentA` should only run from 1900 to 2000. |
167 | 167 |
|
168 | 168 | ```julia
|
169 | 169 | add_comp!(m, ComponentA; first = 1900, last = 2000)
|
170 | 170 | ```
|
171 | 171 |
|
172 |
| -The next step is to set the values for all the parameters in the components. Parameters can either have their values assigned from external data, or they can internally connect to the values from variables in other components of the model. |
| 172 | +The next step is to set the values for all the parameters in the components. Parameters can either have their values assigned from external data, or they can internally connect to the values from variables in other components of the model. When assigned from external data, parameters are externally connected to a model parameter, which can be a shared model parameter with its own name and connected to more than one component-parameter pair, or an unshared model paarameter accessible only through the component-parameter pair names and connected solely to that parameter. |
173 | 173 |
|
174 |
| -To make an external connection, the syntax is as follows: |
| 174 | +To make an external connection to an unshared model parameter, the syntax is as follows: |
175 | 175 |
|
176 | 176 | ```julia
|
177 |
| -set_param!(m, :ComponentName, :ParameterName, 0.8) # a scalar parameter |
178 |
| -set_param!(m, :ComponentName, :ParameterName2, rand(351, 3)) # a two-dimensional parameter |
| 177 | +update_param!(m, :ComponentName, :ParameterName1, 0.8) # a scalar parameter |
| 178 | +update_param!(m, :ComponentName, :ParameterName2, rand(351, 3)) # a two-dimensional parameter |
| 179 | +``` |
| 180 | + |
| 181 | +To make an external connection to a shared model parameter, the syntax is as follows: |
| 182 | + |
| 183 | +```julia |
| 184 | +add_shared_param!(m, :ModelParameterName, 1.0) # add a shared model parameter to the model |
| 185 | +connect_param!(m, :ComponentName, :ParameterName3, :ModelParameterName) # connect component parameter |
| 186 | +connect_param!(m, :ComponentName, :ParameterName4, :ModelParameterName) |
179 | 187 | ```
|
180 | 188 |
|
181 | 189 | To make an internal connection, the syntax is as follows.
|
@@ -301,11 +309,11 @@ end
|
301 | 309 | m = Model()
|
302 | 310 | set_dimension!(m, :time, 2005:2020)
|
303 | 311 | add_comp!(m, top, nameof(top))
|
304 |
| -set_param!(m, :fooA1, 1) |
305 |
| -set_param!(m, :fooA2, 2) |
306 |
| -set_param!(m, :foo3, 10) |
307 |
| -set_param!(m, :foo4, 20) |
308 |
| -set_param!(m, :par_1_1, collect(1:length(2005:2020))) |
| 312 | +update_param!(m, :top, :fooA1, 1) |
| 313 | +update_param!(m, :top, :fooA2, 2) |
| 314 | +update_param!(m, :top, :foo3, 10) |
| 315 | +update_param!(m, :top, :foo4, 20) |
| 316 | +update_param!(m, :top, :par_1_1, collect(1:length(2005:2020))) |
309 | 317 | run(m)
|
310 | 318 | ```
|
311 | 319 | Take a look at what you've created now using `explore(m)`, a peek into what you can learn in How To Guide 2!
|
0 commit comments