What behavior do we want when updating model time dimension?

[rjplevin]

In the test file test_dimensions.jl, we set the first/last period of a component to 2005 and 2105. We then call set_dimension!(m, :time, 2010:2050) and test that the component's first/last have been updated.

This strikes me as incorrect behavior. If the component can run outside the range the model is being run for, I don't think we should change the component, though this raises questions about component initialization if it's started after it's indicated first period.

Bottom line is that I'm not sure what the correct behavior here should be. Both updating it and not updating it can result in confusion and violation of the principle of least astonishment.

Seeking feedback...

[corakingdon]

I think I currently rely on this updating of time periods in components. I think this makes sense for now because a component can't run longer than the model (so if you're shrinking the time span of the model, then the component has to run on that too). I realize this is not a strong argument, but would vote for keeping this functionality as is.

[rjplevin]

Consider first that we have potentially 3 actors in the mix:

• A composite component developer
• A model (or composite component) developer using others' composite components
• An end user using the above

We need a way to communicate assumptions among these parties about how to use the components "correctly" with respect to time. A user should be able to run a component in an "off label" mode, but they should know they're doing so.

There are two main cases:

1. A model or composite component contains a leaf component with a later start or earlier end than the current model timespan, i.e., the component timespan is binding.

   The component won't run until the model reaches the component's first period, which seems ok. Do we run the components' init function when the model starts or just before the component starts?

   The component will stop running before the model does, which may result in missing values. I can imagine cases where stopping the component early is fine, and cases in which it breaks the model. We don't want this to appear to be a random outcome from the user perspective.

2. A composite component contains a leaf component with a earlier start or later end than the model timespan, i.e., the model timespan is binding. I think this is the use case @ckingdon95 described.

   A potential problem with starting the model later than the component was designed for is that "first period" initialization steps might be skipped.

   • Do we need a way to indicate that a component is not valid unless it starts at a certain timestep?
   • Do we need guidelines for component design and use of the init function to create "time-flexible" components? Maybe this is just a matter of documentation.

   A component with a last period beyond the model isn't a problem; it just won't be run as far as it is designed to.

Having never built a real Mimi model, I don't have the best feel for the model development process and why/when one would be altering time horizons.

[corakingdon]

Okay just a clarification that I didn't realize at first: the issue at hand really only applies to components whose first/last values were explicitly set during add_comp! (because if they weren't explicitly set, then it makes sense for them to transition to the model's new time index which happens during build).

Once I realized that, I agree that the current functionality seems problematic, especially because of the init function.

I think the solution is, though, that you cannot have a component whose time index is longer than the model (or a leaf component that is longer than its parent component). So if you shrink the model's time span too narrow, you should get an error (rather than the current updating behavior). In order to run such a model, the user needs to set the model's time index to reflect the length of the longest component, and all other comps need to be explicitly set shorter during add_comp!. Just to be clear, I think this applies not only to the first value but also the last value. I understand that having a last value that is later than the model causes less of a problem, in the sense that it just won't run past that point and doesn't have the problems associated with the init function, but I think it still contradicts the user's intention of setting the last value.

Regarding your two cases:

1. I think the init function should be run before the model starts. Regarding missing values, I think it's on the user to manage this, since it's only an issue if they are explicitly making a component shorter when add_comp! is called, so they need to be responsible for managing their connections.
2. as I stated above, I don't think we should allow this. The first/last values are not inherent to the component definition created during @defcomp, so it's not the case that a certain defined component has to start at a certain time; they only appear in the comp_def that gets added during add_comp! if the user explicitly sets them.

[rjplevin]

@cora, thanks for the clear analysis. I agree with all of it, with one caveat.

If someone develops a composite component, they may have reason to have a leaf component start later, or end earlier, than the overall component. Given that the global model time isn't known at this stage makes it hard to deal with this when writing the composite.

I wonder if we need to introduce a relative time concept, e.g., to indicate that a leaf component stops N timesteps prior to the end (or after the start) of the composite?

[davidanthoff]

Should we put this on the agenda for Fri? My head is spinning just reading this... I think I also agree with @ckingdon95's points above, but the composite case does make it quite a bit more complicated...

[corakingdon]

Yes I think we need to talk through this further in the case of composite components, as I'm not familiar with what the syntax is yet in terms of setting a first/last values for a leaf.

[rjplevin]

I've implemented what we discussed with time bounds on components, but I'm facing more conceptual issues. This is from one of the test files:

m = Model()
set_dimension!(m, :time, [2000, 2005, 2020])
add_comp!(m, MyComp2; first=2000, last=2020)
set_param!(m, :MyComp2, :x, [1, 2, 3])

set_dimension!(m, :time, [2005, 2020, 2050])

In my current version, this raises the following error:
Attempted to set last period of ComponentId(Mimi.##ModelDef#380) to a later period (2050) than component indicates (2020)

It's still unclear to me what the relationship should be between first and last when set in add_comp! to a (non-ModeDef) composite component, and the setting of the model's time. Here's what's (somewhat) clear to me and what is not:

• Setting the model's first to later than any component's first should be disallowed, since this might break the component.
• Setting the model's last to earlier than some component's last shouldn't be a problem.
• Setting the model's last to earlier than any component's first might be disallowed, since it will never run, or we could just emit a warning.
• I wonder if we should support first and last only for ModelDefs and leaf components (defined as an attribute of the component, not of the composite it is add_comp!d to as currently implemented).

I think a source of confusion is the conflation of (i) first and last periods for components, (ii) the global time dimension (at least for now, it's still global to a model), which figures in storage allocation, and (iii) the period the user wants to run the model for. Item (i) is mainly a performance optimization; components could instead be programmed to do nothing outside their bounds.

It's unclear to me how much the first and last feature is used for components. When would a (reusable) composite need to set these?

We might be less dogmatic and allow the user to run over whatever time horizon they want, provided it's within the current time dimension, with a warning if we detect any questionable time relationships. But if they attempt to set the time dimension to something that truncates a component's expected run horizon, we throw an error.

The default run horizon would be the full time dimension, but the user can override this in Mimi.run.

We might be less dogmatic and allow the user to run over whatever time horizon they want, provided it's within the current time dimension, with a warning if we detect any questionable time relationships. But if they attempt to set the time dimension to something that truncates a component's expected run horizon, we throw an error.

The default run horizon would be the full time dimension, but the user can override this in Mimi.run.

Setting a run horizon would not change the time dimension (which in turn determines storage allocation, and some components may "require" longer arrays to load their data values.
So if you want to run for a shorter period and have smaller array allocations, you would have to set the time dimension first, and address any conflicts with components' run horizons.

Cora [8:31 AM]

"I wonder if we should support first and last only for ModelDefs and leaf components (defined as an attribute of the component, not of the composite it is add_comp!d to as currently implemented)"
This doesn't make sense to me, because the first and last are only attributes of the component with respect to the model it is being added to, not within the component definition itself. or are you saying we should add new fields to @defcomp where the user sets them if needed?

rich [8:40 AM]

the first and last are only attributes of the component with respect to the model it is being added to, not within the component definition itself.
Are you saying "as currently implemented" or conceptually?

Cora [8:41 AM]
as currently implemented

rich [8:41 AM]
I'm suggesting changing that.

Cora [8:42 AM]
changing it to have it be part of @decomp?

rich [8:42 AM]
Yes, that's what I meant. But this raises another point of confusion. The run horizon for a component could be an attribute of the component or something set by the composite it is added to. I suppose both are possibly useful. They were really the same thing for flat models. But now there's a distinction.

Cora [8:45 AM]
Hmm I think that would make sense for this mess of what they mean and how they get carried through composite components, but I also think the general idea of Mimi is that the components (as defined in @Defcomp) are a more general template and that specific things about them should be set and changed when building the model
but also keeping in mind that this is rarely used, and maybe it would only be used for a specific component that needs to be run a certain way and then I could see it making sense for it to be set in @Defcomp

rich [8:46 AM]
Yes, I see that. But I can also imagine setting the run period as part of the definition of a component, e.g., if it has a long "spin-up" period based on historical data.

Cora [8:46 AM]
right
but maybe we could also support a function that allows the user to change this when adding it to a model? but that it would change it in the copy of the component definition that gets added to the model?
I think this conversation is also related to parameter data loading, in that we want these components to be a general template, but often they have very specific historic data that they need to be run on
and should we somehow be formalizing the relatioship between component definitions and the data they need

rich [8:51 AM]
Agreed about the data. Should there then be a distinction between "hard" constraints on a component's run horizon (e.g., data-related) versus "advisory" constraints on a run horizon that can safely be overridden when the component is added to a model?

The point I keep returning to is that we still don't have a clear semantics of what first and last mean, which makes it difficult to implement!

Cora [8:51 AM]
yes agreed!
I think though that they are more about data constraints, and not about optimization considerations (like I don't think we should worry about allocating arrays that are longer than they need to be etc)

rich [8:57 AM]
I think we should discuss this when David is available. I'd like to go back to first principles about:
• what we want to support in terms of composites as consumer-modifiable "templates" (exactly what can / cannot be modified safely?)
• clarifying the distinctions between model run horizon, component run horizon, model time dimension(s)
• whether first and last (run horizon) for components are attributes of the component or of the composite they belong to (or both?)