Mimi Framework

Handling of component-specific simulation names changed?

I use references, so most of my parameters are given component-specific names, following:

set_param!(model, :Component, :parameter, :Component_parameter, value)

At some point in the last few months, a change in Mimi has broken my Monte Carlo setup. I currently have lines in there of the form:

parameter[region1] = TriangularDist(...)
parameter[region2] = TriangularDist(...)

and now I have had to change the lines to:

Component_parameter[region1] = TriangularDist(...)
Component_parameter[region2] = TriangularDist(...)

I can see the advantage of this, but I don’t know how it happened or if it was intentional. The general philosophical question is, when you set of a connection to a unique external parameter name, are you just providing a way to set its value, in which case the simulation “setting of its value” should be an independent operation, or are you constructing aspects of the model itself?

Hi @jrising, in this case where you are explicitly setting a component-specific name like :Component_parameter then yes this is the expected behavior in Mimi v1.0.0. This changed when we updated the signature of set_param! to allow for various desired functionalities.

Per your more general question I’m not sure I quite understand, but would be happy to discuss if you could rephrase? We want to use the model-specific parameter name for a defsim that will be run on a model m so that it can correctly access that parameter :Component_parameter.

Okay. As I said, I see the benefits. I was just surprised when the errors appeared.

On my general point, I think I won’t be the only one who needs to adjust their thinking a little to understand why the Simulations use external parameter names. Here’s how I was previously thinking about it.

When you’re making a model, there’s first a design phase, where you set up all the equations, and then there’s a calibration phase, where you plug in values. For me, set_param! was very much a “calibration phase” operation, while “connect_param!” is in the design phase. Because of this, I’ll always do all of my connect_param!'s first, and typically split them out in a separate function. Then, each Monte Carlo simulation is just redoing the calibration phase with different values.

When I’m setting values, I might find that I need to construct a unique external parameter name, but I treat this as a technicality. All I’m really trying to do is set a particular parameter in the model.

But now, I think I should redesign my code to be conceptually consistent with the design of Mimi. When designing my model, I should construct all of the external parameter names that I will want to use. Then, during calibration, I should use set_external_param! and never use set_param!, because set_param! breaks an abstraction barrier. If I let people ever use set_param!, then if I give my model object to some other piece of code, I could find that I can no longer run my Monte Carlo code on it.

An alternative solution, which would be more in-line with the existence of the set_param! function, is to say that the construction of external parameters is entirely a “calibration” operation, and therefore Monte Carlo simulations should construct their own external parameters if they want to use them. In essence, the lines in the @defsim should be in the business of calling set_param! rather than calling set_external_param!.

Ah ok I see what you mean now, thank you for clarifying! Yes I didn’t foresee that error either, it seems this side-effect of our changes isn’t explicitly in our testing suite so we weren’t alerted to it and thus didn’t include it in the how-to guide for bringing models onto v1.0.0. I like your description of calibration and design phases, I’ll mull that over and bring it up with the team at our next meeting so we can make sure we’re on the same page with how we think about the process … always evolving! Thanks again for taking the time to explain and help with this process.

Okay, glad it was helpful! Let me know what comes out of the discussion.