@jrising @ckingdon95 @hbenveniste you three are our current MCS functionality users so I wanted to quickly flag something for you. We are quickly moving towards getting stability in function names etc. for this, but since it’s a new and evolving functionality there are bound to be a few little changes going forward. The most recent, which is reflected in the docs, is that you now must use set_models!(mcs, model), and run_mcs no longer can add models to the mcs run within its signature. This was for clarity and simplicity. Hence, you will do the following if m is your Model and mcs is your MCS instance.
# Set the model
set_models!(mcs, m)
# Run trials 1:4, and save results to the indicated directory, one CSV file per RV
run_mcs(mcs,1:4, output_dir=output_dir)
The next release will also feature the new @defsim macro, which generalizes @defmcs to include other methods, first of which is Sobol Analysis. We will plan to maintain the backwards compatibility of @defmcs for now though.
1 Like
Thanks for the heads-up. This seems fine.
@ckingdon95 @hbenveniste @jrising Hi all, apologies for the continuous updates on this, we are moving towards stability! We are adding to the mcs functionality, and generalizing it to sensitivity analysis (sa) functionality, encompassing Monte Carlo and others. The goal is to make the package even more useful for you!
BUT the next Mimi release will break your mcs code a bit. All documentation will be updated too, but your changes should be minimal:
-
@defmcs to @defsim
-
@run_mcs to @run_sim
These are simple, since we consider random sampling with mcs to be our default. See the docs and examples and don’t hesitate to ask if you have any questions at all!
I noticed that in MimiPAGE2009, you wrapped all the @defsim code in a function. What’s the purpose of that? It seems like this would allow us to create the MC structure multiple times, but since it’s all descriptive, why would we want to do that?
Thanks.
Hi James. I think this was a design decision by Cora so that she can import and use the function as part of the PAGE2009 API instead of calling include on a file with the def_sim in it, not so that she can create the structure multiple times, is that right @ckingdon95?
I actually don’t use this directly, so this can be changed if desired. But the intention was in line with what Lisa said-- if someone wants to use this, it might be better to be able to call a function that returns a copy of the Simulation object to work with, rather than having there be only one Simulation object defined in the module. This is similar to how we have a getpage() function that returns a new/clean version of the model, rather than only defining one copy of the model.
Maybe another important clarification: the Simulation object isn’t just purely descriptive. When we use the object (by calling set_models! and generate_trials! and run_sim), the object is modified, which is why it might be useful to have the function that returns a new/unused copy of it
That’s a good point, the object does get modified. I am continuing to work on performing sensitivity analysis with the Sobol method, which includes an analyze function and has revealed some pros and cons of our current design … I’ll keep everyone updated but if I make changes will be trying not to break any existing functionality!