Configurable showcases#144
Conversation
Co-authored-by: Francesco Zanetta <62377868+frazane@users.noreply.github.com> Co-authored-by: Michele Cattaneo <44707621+MicheleCattaneo@users.noreply.github.com> Co-authored-by: Hugues de Laroussilhe <hugues.delaroussilhe@meteoswiss.ch>
…d (as in baseline)
Co-authored-by: Daniele Nerini <daniele.nerini@meteoswiss.ch>
Co-authored-by: Daniele Nerini <daniele.nerini@meteoswiss.ch>
|
@jonasbhend did you have the chance to look at it? |
jonasbhend
left a comment
There was a problem hiding this comment.
Thanks @cosunae, really nice. I have a minor discussion point (not sure whether we want to do this at all) and there seems to be something wrong with the precipitation scaling in the example config (run as is for meteograms only):
| showcase: | ||
| params: | ||
| - T_2M | ||
| - SP_10M | ||
| - TOT_PREC | ||
| meteograms: false | ||
| animations: true | ||
| domains: | ||
| - europe | ||
| - switzerland | ||
| - name: alpine_arc | ||
| extent: [3.0, 17.0, 43.5, 48.5] | ||
| projection: orthographic | ||
|
|
||
| stations: [JUN] #, COV, GOR, WFJ, SAE, SAM, DAV, ZER, ANT, VSBAS, BRT, LTB, GOS, CEV, BIA] |
There was a problem hiding this comment.
I really like the idea of a showcase section in the config (and as @dnerini pointed out, we should probably do that for experiments too). What I am not sure is if a more hierarchical approach would be more user-friendly, e.g.:
showcase:
meteograms:
plot: true
stations: [JUN, BAS, BER]
animations:
plot: true
domains: ...
Then the question is, if you want params as top level (under showcase) or params per meteogram and animations separately. Easy enough to produce one after the other, so probably no need to replicate params in both.
fyi: @frazane
There was a problem hiding this comment.
yes, that makes lot of sense. let me refactor the config alone the lines. Concerning the question, yes, do not have much opinion, probably more in favor of as you said not duplicate too much in order to not clutter much the config with replicated params
| python {input.script} \ | ||
| --input {params.grib_out_dir} --date {wildcards.init_time} --outfn {output[0]} \ | ||
| --param {wildcards.param} --leadtime {wildcards.leadtime} --region {wildcards.region} \ | ||
| {params.region_extra} \ |
There was a problem hiding this comment.
AFAIK we are running a separate job for each region in the config. As showcases are already quite slow (due to the large volume of plots being generated), wouldn't it be more efficient to plot all the regions in one call, such that we have to load the data only once?
There was a problem hiding this comment.
Never mind, this is probably too hard due to the multiple outputs issue.
There was a problem hiding this comment.
I think this makes lot of sense. I was already thinking alone those lines, for meteograms.
Currently with snakemake we are generating rules per params x stations x runs. Each launch an individual script and re-loads the data.
Similar to your comment, I think we could re-structure the granularity, and have python scripts that handle multiple regions, or multiple locations. And perhaps params.
But yes, I think that will be a considerable refactoring. I can take a look at after this PR?
thanks @jonasbhend , not sure I understood what would you do here? |
The idea is to make the generation of showcases configurable.
In the config we can now specify:
An example