Giters

NVIDIA / earth2mip

Earth-2 Model Intercomparison Project (MIP) is a python framework that enables climate researchers and scientists to inter-compare AI models for weather and climate.

Home Page:https://nvidia.github.io/earth2mip/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

🐛[BUG]: Inconsistency in Model Inferences with Modified Initial Conditions and Execution Date in 04_diagnostic_models Example

albetancurqu42 opened this issue · comments

commented

Version

main

On which installation method(s) does this occur?

Source

Describe the issue

Hello,

I'm currently working with the example script 04_diagnostic_models.py and I've encountered an issue when making two specific modifications. The first change I made was using gfs instead of cds as the initial condition. The second change involved setting the execution date to 2024-01-10 00:00:00. Apart from these modifications, the code remains identical to the original example provided in your documentation.

The problem arises with the consistency of inferences obtained in both the original variables of the fcn model and the precipitation computed with afno. The results for all forecast horizons across all variables exhibit the following pattern:

Forecast results for the u10m variable across all forecast times and initial conditions:
image
image

Forecast results for the tp variable across all forecast times and first forecast instance
image
image

The reason for raising this issue is that variables not related to the afno model are also being affected. Interestingly, when I run the same example under the initial conditions, I can reproduce the results shown in the example from the documentation. Similarly, executing it with cds but for the date 2024-01-10 00:00:00, I obtained consistent results.

Could you please provide some insight into why these discrepancies are occurring and any potential solutions?

Thank you for your assistance.

Environment details

+ Environment location: ec2 AWS, miniconda, Tesla T4
commented

Thanks for opening the issue @albetancurqu42. Could you share the complete example script you are trying to run?

Could be an issue with the GFS DataSource, this hasn't been used as much.

commented

Resolved the issue when using GFS by addressing the multiplication of geopotential height with gravity to obtain geopotential. The root cause was an incorrect if statement failing to check when the variable is "Z", preventing proper processing.

Additionally, identified an error in the GFS beta function, specifically in beta.lexicon.gfs.py, related to a typographical error in the naming of the u100m variable in the original data source labels.