-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adding return_parameters
option to Engine
#62
base: master
Are you sure you want to change the base?
Conversation
Adding optional parameter `return_parameters` which returns each the parameters used in each run within the experiment results output. Defaults to False. This feature saves time, reduces complexity, and avoids the risk of error when requiring users to manually construct a map of which parameters correspond to each run after the fact.
@@ -164,6 +167,8 @@ def _single_run_wrapper(args): | |||
if raise_exceptions and exception: | |||
raise exception | |||
else: | |||
if run_args.return_parameters: | |||
[substep.update(run_args.parameters) for timestep in results for substep in timestep] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One issue we might face including all parameters in the simulation results is that typically not all parameters are basic Python types, serialisable, or able to be stored in Pandas DataFrames efficiently.
As an alternative we do currently have access to each subset's parameters in the before_subset()
and after_subset()
hooks, should a user want to get access to these before or after a specific set of parameters is used in a simulation.
I understand the use case of storing parameters in the simulation results and having them end up in a DataFrame though - I have done this in the past for a subset of the parameters that are useful to have in post-processing and maybe additionally are basic Python types.
Let me sleep on this and see if there are other ways of implementing, open to ideas too :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I 100% agree with the benefits of such a feature:
This feature saves time, reduces complexity, and avoids the risk of error when requiring users to manually construct a map of which parameters correspond to each run after the fact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point about complex data types for params. Given all params are specified as values in a dict though, I believe it should cover every case to output a dict with keys corresponding to run # and subset # and a value of a dict of params:
{ run_i: {subset_j: {param_x: value_x }, subset_j+1: {param_x: value_x }} }
This approach would need to make experiment.run()
return both the run results and the params dict at well. ie:
results, params = experiment.run()
Adding optional parameter
return_parameters
which returns the parameters used in each run within the experiment results output.Defaults to False.
This feature saves time, reduces complexity, and avoids the risk of error when requiring users to manually construct a map of which parameters correspond to each run after the fact.