Pecan: met2model.ED2 saute les années bissextiles

Créé le 24 juil. 2017  ·  9Commentaires  ·  Source: PecanProject/pecan

Seulement confirmé cette erreur pour GFDL, mais pourrait arriver pour d'autres. met2model.ED2 signale toutes les années bissextiles comme incomplètes et avertit " ____ is not a complete year and will not be included " et les saute. Cela fait échouer ED2 pour les exécutions qui s'étendent sur des années bissextiles.

Exemple d'erreur exécuté ici.

Bug 03 - High Stale

Commentaire le plus utile

De nombreux produits météo modélisés (et même certains obs) sautent des années bissextiles, certains modèles climatiques plus anciens utilisaient même une année de 360 ​​jours. Nous devons donc soit décider que tous les produits rencontrés doivent combler les lacunes (par exemple, en répliquant deux fois le 28 février) s'ils ne sont pas fournis, ou tous les met2model doivent effectuer cette étape si le modèle l'exige. Étant donné que cela semble spécifique au modèle (certains modèles s'en moquent), cela ressemble à met2model.

Tous les 9 commentaires

solution de contournement
GFDL n'a pas d'années bissextiles intégrées. Ma solution de contournement personnelle consiste à vérifier si le met est GFDL et, si c'est le cas, à traiter toutes les années bissextiles comme des années non bissextiles. Cela pourrait utiliser une vérification plus générale pour les produits rencontrés qui n'ont pas d'années bissextiles.

@mccabe , cette

Je suis d'accord. Ma solution est complètement bidon, et j'ai l'intention de la séquestrer dans une branche personnelle pour le moment. ED semble bien avec ça pour l'instant, donc je pense que je vais revenir sur ce problème après l'ESA et mettre en œuvre une vraie solution.

Je pense que ce n'est pas un bug de met2model.ED2, mais c'est dû au fait que le GFDL n'est pas traité correctement (en supposant que GFDL _a_ des années bissextiles), il n'y a pas de vérification des années bissextiles dans le code download.GFDL , c'est toujours 2920 valeurs par an

Met2model.ED traite également les années bissextiles pour AmerifluxLBL

Je pense que nous avons convenu précédemment que le problème était avec le GFDL rencontré, la question est de savoir si la solution devrait venir dans le téléchargement GFDL, dans met2model, ou être quelque chose de générique entre les deux. Dans tous les cas, ce jour intercalaire supplémentaire doit être ajouté pour les modèles qui en ont besoin.

compris, je ne savais pas si GFDL avait des années bissextiles ou non (j'aurais dû lire le fil plus attentivement, pas seulement le titre :))

De nombreux produits météo modélisés (et même certains obs) sautent des années bissextiles, certains modèles climatiques plus anciens utilisaient même une année de 360 ​​jours. Nous devons donc soit décider que tous les produits rencontrés doivent combler les lacunes (par exemple, en répliquant deux fois le 28 février) s'ils ne sont pas fournis, ou tous les met2model doivent effectuer cette étape si le modèle l'exige. Étant donné que cela semble spécifique au modèle (certains modèles s'en moquent), cela ressemble à met2model.

Ce numéro est périmé car il a été ouvert 365 jours sans activité.

Je pense que cela a été réglé. Cette fonction prend un argument leap_year qui contrôle ce comportement. Je ne sais pas comment cela joue avec GFDL rencontré, cependant.

https://github.com/PecanProject/pecan/blob/9ed21c954f64d24055d91cd8682cb7b2ddf97863/models/ed/R/met2model.ED2.R#L26 -L28

Cette page vous a été utile?
0 / 5 - 0 notes