Issue with prediction of t1000 and surface temp

[yashdiggikar]

While analyzing GraphCast outputs, I observed that the near-surface temperature fields (T1000 and T2m) do not exhibit the expected diurnal oscillation seen in ERA5. Both variables remain relatively flat, whereas in ERA5, they show a clear day–night cycle. This seems to indicate that the model may not fully capture surface–atmosphere interactions or the diurnal cycle near the boundary layer.
Could you please clarify whether this is a known limitation of the model, or if there is a specific preprocessing step needed to recover the diurnal variability?

[alvarosg]

Thank you creating the issue.
That is definitely unexpected, for example, in the video from our blogpost from when GraphCast was published, there is a video that shows predictions for 2m temperature and shows diurnal cycle.

Where are you getting the GraphCast outputs from?

We have historical and realtime fees for GraphCast, labelled as WeatherNext Graph, in this site:
https://deepmind.google/science/weathernext/

Could you try to reproduce the issue using that from that site and share the code?

Thanks!

[yashdiggikar]

Hi Alvaro, Thanks for clarifying. I ran the graphcast_demo.ipynb notebook from the official GraphCast repository ( https://github.com/google-deepmind/graphcast/blob/main/graphcast_demo.ipynb), specifically with the GraphCast-small checkpoint (ERA5, 1° resolution, 13 levels, 40 steps). The output NetCDF contained the expected variables (2m_temperature, temperature, etc.), and I plotted the physical outputs. However, both the global means and local point showed a smooth monotonic drift without any sign of the expected diurnal cycle. Since you mentioned the model should show a diurnal cycle, could you please guide on why I might not be seeing it with the demo checkpoint, and what steps could be taken to recover it? Regards Yash

…

On Thu, Sep 18, 2025 at 1:34 PM Alvaro ***@***.***> wrote: *alvarosg* left a comment (google-deepmind/graphcast#183) <#183 (comment)> Thank you creating the issue. That is definitely unexpected, for example, in the video from our blogpost from when GraphCast was published, there is a video <https://youtu.be/Q6fOlW-Y_Ss?si=OX7sNK3Iy3tQAdK7&t=5> that shows predictions for 2m temperature and shows diurnal cycle. Where are you getting the GraphCast outputs from? We have historical and realtime fees for GraphCast, labelled as WeatherNext Graph, in this site: https://deepmind.google/science/weathernext/ Could you try to reproduce the issue using that from that site and share the code? Thanks! — Reply to this email directly, view it on GitHub <#183 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3W5A7A3RNZKPEZK6MWSBAT3TLUKTAVCNFSM6AAAAACG4M64JWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMBYG4ZDMNZUGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[alvarosg]

Could you show the code you are using to produce the plot?

I would expect the global mean to perhaps not have a cycle (since it is always noon somewhere in earth after all), but I would very much expect a local point that is situated over land to have a diurnal cycle.

[alvarosg]

I just run the full colab in Colaboratory using a TPU backend.

with the model (make sure you select this in the drop down, instead of random):

GraphCast_small - ERA5 1979-2015 - resolution 1.0 - pressure levels 13 - mesh 2to5 - precipitation input and output.npz

and the dataset (make sure you select this in the drop down):

source: era5, date: 2022-01-01, res: 1.0, levels: 13, steps: 40

I can see the diurnal cycle in the animation of 2t in the Plot predictions cell

And also on the location I looked at, seems similar to the diurnal cycle that exists in ERA5.

fig, ax = plt.subplots()
location = dict(lat=40, lon=356.)  # Madrid

ax.plot(eval_targets.time.data.astype(np.float64) / 1e9 / 3600 / 24, eval_targets.sel(**location, batch=0)["2m_temperature"].data, label="ERA5 targets")
ax.plot(predictions.time.data.astype(np.float64) / 1e9 / 3600 / 24, predictions.sel(**location)["2m_temperature"].data, label="GraphCast Prediction")
ax.legend()
ax.set_ylabel(f"2m temperature at {location}")
ax.set_xlabel("leadtime [days]")

[yashdiggikar]

I ran this code and still not seeing the diurnal cycle, I have attached the output below. Could you please help? import matplotlib.pyplot as plt fig, ax = plt.subplots() location = dict(lat=40.0, lon=356.0) ax.plot( eval_targets.time.data.astype(np.float64) / 1e9 / 3600 / 24, eval_targets.sel(**location, batch=0)["2m_temperature"].data, label="ERA5 targets" ) ax.plot( predictions.time.data.astype(np.float64) / 1e9 / 3600 / 24, predictions.sel(**location)["2m_temperature"].data, label="GraphCast Prediction" ) ax.legend() ax.set_ylabel(f"2m temperature at {location}") ax.set_xlabel("leadtime [days]") ax.grid(True) out_path = "/xace/d1/yashd1/gc_runs/t2m_madrid.png" plt.savefig(out_path, dpi=150)

…

On Fri, Sep 19, 2025 at 1:20 PM Alvaro ***@***.***> wrote: *alvarosg* left a comment (google-deepmind/graphcast#183) <#183 (comment)> I just run the full colab in Colaboratory using a TPU backend. with the model: GraphCast_small - ERA5 1979-2015 - resolution 1.0 - pressure levels 13 - mesh 2to5 - precipitation input and output.npz and the dataset: source: era5, date: 2022-01-01, res: 1.0, levels: 13, steps: 40 I can see the diurnal cycle in the animation of 2t in the Plot predictions cell And also on the location I looked at, seems similar to the diurnal cycle that exists in ERA5. fig, ax = plt.subplots() location = dict(lat=40, lon=356.) # Madrid ax.plot(eval_targets.time.data.astype(np.float64) / 1e9 / 3600 / 24, eval_targets.sel(**location, batch=0)["2m_temperature"].data, label="ERA5 targets") ax.plot(predictions.time.data.astype(np.float64) / 1e9 / 3600 / 24, predictions.sel(**location)["2m_temperature"].data, label="GraphCast Prediction") ax.legend() ax.set_ylabel(f"2m temperature at {location}") ax.set_xlabel("leadtime [days]") image.png (view on web) <https://github.com/user-attachments/assets/4d0e7215-7a72-408c-acbd-6880e19ac11f> — Reply to this email directly, view it on GitHub <#183 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3W5A7F35TWDMB4FZBVIDSL3TQ3N5AVCNFSM6AAAAACG4M64JWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMJTGA2TOMBYGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[alvarosg]

Could you share the attachment? Also, could you confirm that you are selecting the correct checkpoint and the correct data before running the next cell in the colab?

[yashdiggikar]

It turned out the issue was with loading the correct checkpoint, the colab dropdown appeared to switch to the checkpoint option, it was still loading random weights. I was able to resolve it by forcing the notebook to use the checkpoint directly, and now it works as expected. Thank you for your help!

…

On Fri, Sep 19, 2025 at 4:08 PM Alvaro ***@***.***> wrote: *alvarosg* left a comment (google-deepmind/graphcast#183) <#183 (comment)> Could you share the attachment? Also, could you confirm that you are selecting the correct checkpoint and the correct data before running the next cell in the colab? — Reply to this email directly, view it on GitHub <#183 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3W5A7AWM6JV53TCJHJCCB33TRPDDAVCNFSM6AAAAACG4M64JWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMJTGY3TCNJQGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[yashdiggikar]

Hi Alvaro, I am currently working with the official GraphCast release and trying to extend the forecasts from the default 40 steps (6-hourly) to 240 steps (60 days). Could you please advise what major changes, additional inputs, or best practices are required to correctly enable longer rollouts in GraphCast? In particular, I am unsure about how best to: - Extend the targets_template beyond 40 steps, - Handle forcings properly over the extended horizon (for example, TOA solar radiation), - Manage time-dependent vs constant input variables during rollout. For context, I tried extending targets_template to 240 steps and repeated the forcings, but the diurnal cycle did not appear and I occasionally ran into shape mismatch errors. Thank you for your time. Regards, Yash Diggikar On Sat, Sep 20, 2025 at 9:51 AM Yash Diggikar ***@***.***> wrote:

…

It turned out the issue was with loading the correct checkpoint, the colab dropdown appeared to switch to the checkpoint option, it was still loading random weights. I was able to resolve it by forcing the notebook to use the checkpoint directly, and now it works as expected. Thank you for your help! On Fri, Sep 19, 2025 at 4:08 PM Alvaro ***@***.***> wrote: > *alvarosg* left a comment (google-deepmind/graphcast#183) > <#183 (comment)> > > Could you share the attachment? Also, could you confirm that you are > selecting the correct checkpoint and the correct data before running the > next cell in the colab? > > — > Reply to this email directly, view it on GitHub > <#183 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/A3W5A7AWM6JV53TCJHJCCB33TRPDDAVCNFSM6AAAAACG4M64JWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMJTGY3TCNJQGY> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[alvarosg]

Thanks for your message:

Extend the targets_template beyond 40 steps,

This should be a matter of using the xarray library to do something that looks like the 40 step, but with more steps. You may be able to find other open source repos that are already doing this with the model.

Handle forcings properly over the extended horizon (for example, TOA
solar radiation),

There is code to compute forcings example usage.

You should just create a targets_template for the times of interest including only the variables you need and then call those function to add the forcings.

Manage time-dependent vs constant input variables during rollout.

I am nos sure what the problem is, since the constant variables only go in the inputs and the inputs look the same regardless of the number of steps.

I am closing this issue for now since this is now unrelated to the original query though!