Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

sfc_update (18:00:00)

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.



I am using a sfc_update file for every 6 hours of my MPAS-A run. After successfully running the model for several days, I used the ncl scrip to find the difference between the model output (history) and the sfc_update file to ensure the SST was updating correctly. It seems that for the 0,6, & 12 hours intervals, the SST model output and the sfc_update file match quite well. However, every day, during hour 18, there seem to be significant discrepancies. I have included images to demonstrate the problem. Do you have thoughts on why this may occur?

Thanks as always,



    3.4 MB · Views: 63
I can't think of an obvious reason why only 1800 UTC would show the sorts of differences seen in the plots. Could you attach the NCL script that you're using to make the plots, as well as your namelist.atmosphere and streams.atmosphere files? Also, could you attach your log.atmosphere.0000.out file? If you run 'ncdump -v xtime' on the netCDF surface update files, does that indicate that the 1800 UTC time is in the surface update files?
Attached are the files that you requested.

Thank you for all you help,



  • log.atmosphere.0000.out.txt
    1.7 MB · Views: 53
  • xtime.png
    132.4 KB · Views: 1,359
  • namelist.rtf
    2.1 KB · Views: 61
  • streams.rtf
    2.2 KB · Views: 61
  • Globe.ncl.txt
    7.2 KB · Views: 61
Everything looks fine to me in your namelist and streams files. I see that the time index in the surface update file is hardwired in the NCL script you attached. Is it possible that there's an error in editing the time index when plotting the SST differences at 18 UTC? For example, in your NCL script, time index 20 would be valid at 0000 UTC and not 1800 UTC.
Although it is possible, I believe it is unlikely as I have hardwired each time step and the error occurred each day at hour 1800, but never at 0000, 0600, or 1200. Additionally, I just created a via the ncconvert script and ran the output through panoply with the same discrepancies at only 1800 UTC.


    4.6 MB · Views: 62
Do you happen to have run the simulation on Cheyenne? If so, I could take a look at the netCDF files myself, and perhaps see whether I can reproduce the issue.
Yes, I ran the simulation through Cheyenne. The log files, namelist, streams, and history outputs are in my work directory (/glade/work/zmenzo/MPAS_db/east_ENSO) and my diag and restart files are currently in my scratch (/glade/scratch/zmenzo/east_scratch). If you have trouble locating anything, please let me know.

Thanks again!
Thanks very much for pointing me to your directories. I think I have a guess as to what might be happening.

Is it possible that, although your source of SST data provides files every six hours, the SST field over water is only updated every 24 hours at 1200 UTC? If I haven't made a mistake with NCO commands, this does appear to be the case: the SST over water seems to only change between 1200 UTC and 1800 UTC.

If it is the case that the SSTs over water only change every 24 hours at 1200 UTC, the apparent difference in the SST field at 1800 UTC may be due to the way that our run loop is organized. Here's roughly what takes place during a simulation:

  1. Read initial conditions
  2. Write initial output streams
  3. While the current time is not the end time of the simulation
    • If alarms are ringing, read input streams
    • Advance model state
    • Advance simulation clock by dt
    • If alarms are ringing, write output streams

Because the model output files are written at the end of an iteration of the time loop (d) before input streams are read at the beginning of the next iteration (a), the SST that is written to an output file are those that were present at the beginning of the timestep.

So, if the SSTs only change at 1200 UTC, it won't be until the next output time after 1200 UTC that the new SST field would be visible in the model output.