Improve parameter handling with and without generation

[al-rigazzi]

This PR enhances the current way parameters and models are generated in two ways:

• add the possibility of specifying arg_params in Ensembles: arg_params are treated like params but set as exe_args in the created Models -- thus they are set even without the generation step.
• allow multiple tagged parameters on same line

This PR resolves #16 #40

[Spartee]

A few questions about this implementation

1. Should params and arg_params be separate? Why?
2. If they should be separate, shouldn't Model also have arg_params?
3. What happens if a conflicting argument is placed in both arg_params and in params?

My main concern is that this isn't entirely straightforward given the naming convention.

Alternative approaches to consider:

• a flag, params_as_args that specifies if the params argument should be used as command line args
• a method, Ensemble.params_to_args() that calls Model.params_to_args on each model in the ensemble.

thoughts on those?

Either way I think Models should have this too.

[al-rigazzi]

Thanks for the review, @Spartee!

I agree, naming is confusing. I think it is fine to just call all of them params, and then have a method that uses info given in params_as_args to generate the corresponding command line arguments.

I'll adapt the code in the following way:

• all parameters are specified as params
• a list params_as_args has to be passed to specify whether a param has to be turned into an argument, this is then also set in all Models in the Ensemble
• in Ensemble._initialize_entitities(), the function params_to_args() is called, and this is called on each Model in the Ensemble.

The only minor drawback is that params_as_args in Model, is not particularly useful when not running within an ensemble (it somehow just duplicates what can be done with exe_args, since a single model is not parameterized).

[Spartee]

one comment but otherwise LGTM

[Spartee]

will this case ever happen?

[al-rigazzi]

@Spartee it seems like we don't check whether run_settings is None, thus a very bad user might initialize a Model with run_settings=None. I don't know if there is any reason why we are allowing this, otherwise we might want to guard against it in another part of the code?

[Spartee]

yea I think step creation would just fail, but when we go to the server arch I think thisll be more important.