Implement Proj/Model/Run/Var selection for a Calc based on tags

[spencerahill]

Run already has a tags attribute, but it isn't used anywhere. This should be added to all of the core aospy objects. And then within Calc (or however the datatypes shake out based on the pending Calc refactor), implement a way to look through all the available Run objects and only include those with the given tag(s). E.g. control tag to signify this is a control simulation.

[spencerahill]

Now that we use actual objects rather than their string names to permute across parameters for calculations, this is even more pertinent. We have started towards implementing this, in that 'default' and 'all' options are categorized as tags, and we deliberately left the door open in that implementation to add additional tags.

But the implementation is also different than what was originally the target of this Issue. Namely, it assumes that the tags correspond to particular attributes, since (using a Model for a concrete example), 'all' corresponds to self.runs and 'default' corresponds to self.default_runs. This doesn't work for tags like 'control'.

It also relies on parent-level attributes, whereas tags like 'control' make more sense to me to be defined at the child level (which matters provided a Run can correspond to multiple Models, c.f. https://github.com/spencerahill/aospy/issues/111#issuecomment-291022962). On the other hand, 'all' obviously has to correspond to the parent, and I think 'default' makes more sense there too (i.e. you wouldn't have a Run be tagged as 'default', because maybe it should be default in some Models but not others. Or not?)

More thinking required on all of this.

[spencerkclark]

Yes, this functionality would be great! Thanks for reminding me about this issue; I currently do what would be enabled by this in a brute-force (outside aospy) kind of way in my object library by storing some groups (which actually needs to be updated in light of #158 to replace the strings with actual objects) of Runs as global variables in a module. It would be really nice to simply use tags in the run constructors themselves.

When I get a chance I will think about this more too; you raise some important concerns.

[spencerahill]

I currently do what would be enabled by this in a brute-force (outside aospy) kind of way in my object library by storing some groups

Ha, I do the same by the even more crude method of having lots of commenting in/out various runs = ... statements in my main script!

This seems central to our whole aim of easy repetition of calculations across simulations. And honestly your "groups" approach in your object library doesn't seem far off (modulo the strings aspect). Essentially we just want a [run for run in calc_suite.runs if tag in run.tags], although the calc_suite.runs is shorthand for more logic.