Era5-Downloader#2
Conversation
| import numpy as np | ||
| from pathlib import Path | ||
|
|
||
| import matplotlib.animation as animation |
There was a problem hiding this comment.
ich habe eine Plot-Klasse erstellt, mit dem Gedanken dort alle plotterei abzulegen
xarray ermöglicht es auch direkt das array zu potten
So Sachen wie das colorschema, Skalen, Formattierungen usw kann man als Klassenattribute dann für alle Plots homogenisieren
There was a problem hiding this comment.
Grundsätzlich mag ich die Idee, allerdings sollten wir diese Arten eher anders initialisieren. Derzeit führt das zu eienm riesigen Block von Initialisierung, die wir nicht brauchen.
Persönlich habe ich die Erfahrung gemacht, dass ich DataClasses nie brauche oder benutze, gerade wenn man XR ohnehin in Benutzung hat. Idealer wäre meiner Meinung nach für das nächste Mal die Initialisierung in dem Plotting-Modul selbst zu machen, das heißt ohne Klasseninstanzierung, dafür als Init-Methode mit entsprechenden Variablen.
| "dimensions_only_in_ds2": d_only2, | ||
| } | ||
|
|
||
| def main(): |
There was a problem hiding this comment.
der ganze Teil sollte eigtl in main.py abgehandelt werden, auch so, dass man die default werte aus der config überschreiben kann
There was a problem hiding this comment.
Ja, allerdings ist der Workflow derzeit ja disconnected, wenn man bedenkt, dass die Daten aus der Vergangenheit vergleicht werden müssen.
Wenn man den normalen Workflow durchführt, kann man das ja selten vergleichen.
Meine Idee wäre einen zweiten Workflow zu bauen, der direkt dafür da ist, um die beiden Daten miteinander zu vergleichen, anstelle das monolithisch in diesem riesigen Ding zu verbasteln, obwohl es nicht zusammengehört.
| @@ -12,9 +12,9 @@ data: | |||
| # Unit of precipitation values in the input file. Examples: 'm', 'm/s', 'm/hr', 'mm/hr' | |||
| precip_unit: 'm' | |||
|
|
|||
There was a problem hiding this comment.
hier brauch es eigtl noch n switch mode :
- forecast
- historic
- analysis (der beide vergleicht)
und da er5 von cds mit 5 Tagen Verzögerung kommt muss für diese Tage dann über den ecmwf client aber von azure als source (statt ecmwf)
d.h. hier würde es Sinn machen im download.py eine Downloadfunktion die beides runterlädt zu haben und dann unterschiedliche prepares
There was a problem hiding this comment.
Kann man allerdings eigentlich getrennt behandeln, wie hier grob beschrieben. Ich würde eher getrennte Workflows sehen.
There was a problem hiding this comment.
default:
- 72h leadtime
- forecast von heute
- validation false
cli params:
- date
- checkt ob histoic oder forecast
- validation
There was a problem hiding this comment.
Added mode.type (validation or downscaling)
2 participants
No description provided.