I see that the definition of the variable_dimensions function has changed. My code was using variable_dimensions(::Model, ::Symbol, ::Symbol) (and this is still what is documented), but the Mimi code now defines it as variable_dimensions(::Model, Mimi.ComponentPath, ::Symbol).
What is this ComponentPath thing? I don’t see it in the documentation. Why did the function change?
Thanks.
James, sorry about the documentation glitch. With the introduction of composite components, the approach we used with “flat” (single level) models is no longer adequate for identifying a component. The component path is a tuple of symbols describing the relative (to a composite) or absolute (relative to ModelDef) path through composite nodes to specific composite or leaf node.
The transition to composite components required a substantial rewrite of much of the core code, but we tried hard to maintain compatibility with flat models.
@jrising in this vein, the current master branch is somewhat in flux as we continue to prepare for v1.0.0, which per versioning rules will be breaking (but as little as possible!). We will do our best to add deprecation warnings and docs to make the transition smooth but it may be a bit frustrating to work from master right now! Please do keep asking questions though and we will help you out. @plevin this might have been my fault, the docstring was not clear because I didn’t understand the needed syntax for the path, perhaps we should add a small PR to fix that?
Hi @jrising I’ve been looking Into this a bit so I can give you better instructions on your syntax. For now you will need to use a Mimi.ComponentPath so if you previously did something like:
variable_dimensions(m, :gross_economy, :YGROSS)
now do
comp_path = Mimi.ComponentPath((:gross_economy,))
variable_dimensions(m, comp_path, :YGROSS)
This is a bit strange for now, because if we are exporting variable_dimensions then we should be exporting Mimi.ComponentPath if we require that to be used. I’ll see now if I can add API methods:
variable_dimensions(obj::AbstractCompositeComponentDef, comp_name::Symbol, var_name::Symbol)
and
variable_dimensions(obj::AbstractCompositeComponentDef, comp_path::Tuple{N, Symbol}, var_name::Symbol) where N
so that your old code will work, as would code that just used a tuple of symbols … I’ll update here if I get that working!
@jrising https://github.com/mimiframework/Mimi.jl/pull/589 this would make your code work just fine!
Thank you for adding this! I think it will be a lot cleaner to have these methods.
But it also sounds like it would be prudent for me to move back off of the master branch for the time being. (I moved on to it to get fixes earlier, but I think they’re all now in the most recent release.) To your knowledge, are there any bugs on 0.9.4?
I don’t think there are any big ones to my knowledge, we’re mostly adding features and this doing a little bit of deprecation and breaking for 1.0 but will make sure we make that easy as possible. No big bugs come to mind but if you want to look any issue (closed or open) with the v1.0.0 milestone should tell you what we plan to between 0.9.4 and the next release.
Up to you if you want to stay on master, we don’t encourage most users to do so but you’re experienced and might want to keep updated and make fixes ahead of time. We’ll monitor closely to help you out either way.
There’s a case for set_param! that we’re going to fix … where as of now if several components use the same external parameter and you call update_param! … it will update all the components … which we are going to make a an error unless you flag that you know you are updating all of them so that we don’t end up with unexpected behavior.
I think the update_param! fix is quite good. I know I encouraged DA to change that behavior years ago. It might still break things, but it’s worth it.
Thanks!
Agreed @jrising! We are finally going to implement the proper set_param! and update_param! functionality in 1.0, which will be breaking. The desired functionality that we will be implementing is outlined here: https://github.com/mimiframework/Mimi.jl/issues/524
I’m pretty sure it is all in line with fixing the problematic functionality that you’ve highlighted in the past (in particular about having different components with same or different values for parameters of the same name), but we’d love to have you make sure these are the right fixes!