回避策
GFDLにはうるう年が組み込まれていません。 私の個人的な回避策は、会ったのがGFDLであるかどうかを確認し、そうである場合は、すべてのうるう年を非うるう年のように扱うことです。 これは、うるう年のない適合製品のより一般的なチェックを使用できます。
@mccabe 、その
同意します。 私の解決策は完全にハッキーであり、当面は個人のブランチに隔離するつもりです。 今のところEDは問題ないようですので、ESAの後でこの問題に戻り、実際のソリューションを実装すると思います。
これはmet2model.ED2のバグではないと思いますが、GFDLが適切に処理されていないことが原因です(GFDLがうるう年を持っていると仮定)。ダウンロードでうるう年のチェックはありません。GFDL
また、met2model.EDは、AmerifluxLBLのうるう年を処理します
問題はGFDLが満たされていることであることに以前同意したと思います。問題は、解決策がGFDLダウンロード内にあるのか、met2model内にあるのか、それともその間の一般的なものであるのかということです。 いずれにせよ、それを必要とするモデルには、その余分な飛躍日を追加する必要があります。
わかりました。GFDLにうるう年があるかどうかはわかりませんでした(タイトルだけでなく、スレッドをもっと注意深く読む必要があります:))
多くのモデル化されたmet製品(および一部のobs)はうるう年をスキップし、一部の古い気候モデルは360日年を使用していました。 したがって、提供されていない場合は、すべてのmet製品が飛躍日を埋める必要がある(たとえば、2月28日を2回複製する)か、モデルで必要な場合はすべてのmet2modelがそのステップを実行する必要があるかを決定する必要があります。 これはモデル固有のように見えるので(一部のモデルは気にしない)、met2modelのように見えます。
この問題は365日間開いており、アクティビティがないため、古くなっています。
これは解決されたと思います。 この関数は、この動作を制御するleap_year
引数を取ります。 しかし、それがGFDLでどのように機能するかはわかりません。
最も参考になるコメント
多くのモデル化されたmet製品(および一部のobs)はうるう年をスキップし、一部の古い気候モデルは360日年を使用していました。 したがって、提供されていない場合は、すべてのmet製品が飛躍日を埋める必要がある(たとえば、2月28日を2回複製する)か、モデルで必要な場合はすべてのmet2modelがそのステップを実行する必要があるかを決定する必要があります。 これはモデル固有のように見えるので(一部のモデルは気にしない)、met2modelのように見えます。