You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering if the field [input_files] under [climo] does anything in general. It obviously works for the examples listed, but it doesn't seem to actually work for a generic use case.
Additionally, I think it would be great to allow flexibility in terms of naming the subfolders. This line unnecessarily hardcodes stuff:
The use case that brought me to this goes like this: I wanted to use zppy to produce climatologies but with native grid (leaving the map option empty) and I wanted to double check how (dis)similar climatologies will be if they were calculated from different tapes with different outputting frequencies. Thus a config like below ends up producing the same thing (i.e., overwriting itself) under a subfolder inferred from the map filename (i.e., 180x360_aave):
while a more desirable outcome would be to ncclimo the different tapes and store them under different (custom-named) directories.
The bigger advantage of this is that it will allow people to calculate specific climatologies with zppy (say some random vars) to be used later.
Again, this is at-most a nice-to-have type of suggestion with no urgency whatsoever. However, I thought I would write it up here in case I am misunderstanding something or if there is some established workflow I am not aware of :)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I was wondering if the field
[input_files]
under[climo]
does anything in general. It obviously works for the examples listed, but it doesn't seem to actually work for a generic use case.Additionally, I think it would be great to allow flexibility in terms of naming the subfolders. This line unnecessarily hardcodes stuff:
zppy/zppy/climo.py
Lines 50 to 51 in c3f70dc
The use case that brought me to this goes like this: I wanted to use zppy to produce climatologies but with native grid (leaving the map option empty) and I wanted to double check how (dis)similar climatologies will be if they were calculated from different tapes with different outputting frequencies. Thus a config like below ends up producing the same thing (i.e., overwriting itself) under a subfolder inferred from the map filename (i.e.,
180x360_aave
):while a more desirable outcome would be to
ncclimo
the different tapes and store them under different (custom-named) directories.The bigger advantage of this is that it will allow people to calculate specific climatologies with zppy (say some random
vars
) to be used later.Again, this is at-most a nice-to-have type of suggestion with no urgency whatsoever. However, I thought I would write it up here in case I am misunderstanding something or if there is some established workflow I am not aware of :)
Beta Was this translation helpful? Give feedback.
All reactions