Better handling of only flag

[lewisjared]

MAGICC7 has a mechanism to specify a list of variables to write to file with the out_dynamic_vars parameter allowing for very fast runs if only a few variables are required.

Currently the only parameter in the call to run limits the files which are read from disk. For MAGICC7, this functionality can be extended to automatically write the out_dynamic_vars parameter, minimising the number of output files written.

Subannual files shouldn't be returned when using run. Instead users can read these files manually from the output dir if these files are needed.

[znicholls]

@lewisjared are you happy with these steps and what are your thoughts on subannual reading options?

1. refactor MAGICC6 and MAGICCBase to make room for this change
2. make MAGICCBase handling of only compatible with out_dynamic_vars and ignore all SUBANNUAL files when returning timeseries from run
3. add convenience method to read subannual output (see question below)
4. add example of this functionality to the MAGICC7 notebook

I think there's a couple of ways to do the subannual reading:

1. add convenience method, read_output_file(self, filename) which takes a filename and reads it out of self.out_dir, raising an error if it can't find it
2. add convenience method, read_subannual_output_files which reads any subannual files in self.out_dir
3. add a read_subannual_output flag to the run method, if it's True, read subannual files preferentially

I'd go for read_subannual_output_files as read_output_file means you have to remember all the filenames (which is annoying) while read_subannual_output flag means you need to keep track of whether you're overwriting annual data or not (which is also annoying and is most likely a user choice anyway)

[lewisjared]

The problem is that these subannual files are so rarely used that if you need them you know what you need. A more generic method would be preferable as it provides convenience for much more use cases

[znicholls]

A more generic method would be preferable as it provides convenience for much more use cases

I'll take that to mean option 2