# Handling of component-specific simulation names changed? **URL:** \ **Category:** Uncategorized\ **Created:** [November 3, 2020, 1:41pm UTC](https://forum.mimiframework.org/t/handling-of-component-specific-simulation-names-changed/130 "2020-11-03T13:41:28Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![jrising](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.mimiframework.org/jrising/32/7_2.png) [@jrising](https://forum.mimiframework.org/u/jrising)\ **Post date:** [November 3, 2020, 1:41pm UTC](https://forum.mimiframework.org/t/handling-of-component-specific-simulation-names-changed/130/1 "2020-11-03T13:41:28Z")
I use references, so most of my parameters are given component-specific names, following: ```auto 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: ```auto parameter[region1] = TriangularDist(...) parameter[region2] = TriangularDist(...) ``` and now I have had to change the lines to: ```auto 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? ---
**Author:** ![lrennels](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.mimiframework.org/lrennels/32/6_2.png) [@lrennels](https://forum.mimiframework.org/u/lrennels)\ **Post date:** [November 3, 2020, 11:33pm UTC](https://forum.mimiframework.org/t/handling-of-component-specific-simulation-names-changed/130/2 "2020-11-03T23:33:24Z")
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`. ---
**Author:** ![jrising](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.mimiframework.org/jrising/32/7_2.png) [@jrising](https://forum.mimiframework.org/u/jrising)\ **Post date:** [November 4, 2020, 2:59pm UTC](https://forum.mimiframework.org/t/handling-of-component-specific-simulation-names-changed/130/3 "2020-11-04T14:59:50Z")
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!`. ---
**Author:** ![lrennels](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.mimiframework.org/lrennels/32/6_2.png) [@lrennels](https://forum.mimiframework.org/u/lrennels)\ **Post date:** [November 4, 2020, 3:53pm UTC](https://forum.mimiframework.org/t/handling-of-component-specific-simulation-names-changed/130/4 "2020-11-04T15:53:07Z")
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. ---
**Author:** ![jrising](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.mimiframework.org/jrising/32/7_2.png) [@jrising](https://forum.mimiframework.org/u/jrising)\ **Post date:** [November 5, 2020, 12:44pm UTC](https://forum.mimiframework.org/t/handling-of-component-specific-simulation-names-changed/130/5 "2020-11-05T12:44:28Z")
Okay, glad it was helpful! Let me know what comes out of the discussion.