GFS cloud cover - what does it mean?

[jgf]

i'm trying to understand this GFS field, from a grib 1 file

"Total cloud cover (Mixed_intervals Average) @ Entire atmosphere"

in the grib 2 inventory it says this:

"

230 entire atmosphere (considered as a single layer) TCDC 0-6 hour ave Total Cloud Cover [%]

 

 

i think that is the same quantity...

 

what is the meaning of a cloud cover %, at a point?

 

is it a _probability_ of there being cloud cover at a particular location at the valid time?

 

so the variable TCDC would be the average probability of cloud cover at that point, over the 6hr interval?

 

if that is true, and I plot TCDC, what relationship does it have to what a satellite image might look like at that time?

 

can I think of a plot of TCDC as a prediction of the satellite image?

 

 

[ohleary]

Correlate the percentage at a point to this chart of sky cover.  And yes, using the imagination the image you posted can be likened to what a satellite image would look like.

 

[dtk]

i'm trying to understand this GFS field, from a grib 1 file

"Total cloud cover (Mixed_intervals Average) @ Entire atmosphere"

in the grib 2 inventory it says this:

"

230 entire atmosphere (considered as a single layer) TCDC 0-6 hour ave Total Cloud Cover [%]

 

 

i think that is the same quantity...

 

what is the meaning of a cloud cover %, at a point?

 

is it a _probability_ of there being cloud cover at a particular location at the valid time?

 

so the variable TCDC would be the average probability of cloud cover at that point, over the 6hr interval?

 

if that is true, and I plot TCDC, what relationship does it have to what a satellite image might look like at that time?

 

can I think of a plot of TCDC as a prediction of the satellite image?

 

The total cloud cover is a prescribed/diagnostic variable (not the model prognostic variable).  It is essentially the total column cloud cover % within a box (sort of as described by ohleary) to help define the radiative properties of the column.  There is certainly a correlation to this field and satellite images in general, but in order to see an actual prediction of a satellite image, one would need to run a radiative transfer calculation on the model forecast fields (to produce what the satellite image actually is: the radiation "seen" from space at a given wavelength in terms of brightness temperature/radiance/etc.). 

 

We do already produce these types of fields in separate grib files to mimic the channels on goes.  They are available in with names like:

gfs.t${hh}z.goessimpgrb*

 

There are several files for each forecast hour (grib1/grib2, different grids, etc.)....but basically as part of the model post processor, we run a radiative transfer calculation to produce the TOA brightness temperature.  Take a look and compare this with the %cloud clover, and I think you'll see what I mean (there will be certainly be correlation....but the former will give the more direct comparison to what you are used to seeing on satellite images).

[jgf]

thanks.

 

 

The total cloud cover is a prescribed/diagnostic variable (not the model prognostic variable)

 

can you explain the difference between these?

 

i note that total cloud cover is not in the 00hr forecast, so i have interpreted that to mean that it is not a quantity that is initialized, but rather is a forecast quantity.

 

 

[dtk]

thanks.

 

 

 

can you explain the difference between these?

 

i note that total cloud cover is not in the 00hr forecast, so i have interpreted that to mean that it is not a quantity that is initialized, but rather is a forecast quantity.

The model prognostic variable is cloud condenstate mixing ratio (the cloud % is derived from that, in combination with specific humidity & temperature [thereby RH]).  The cloud % field is probably output from some of the model physics (microphysics I guess) routines, which may not be setup to write out the fields after the very first model time step (the f00 files denote fields after the first model time step, not the actual analysis/initial condition).  We do in fact initialize the cloud condensate field, however.

 

I know much more about the analysis (and some about the model itself) than I do the post processing that goes into the grib files (the model itself does not generate the files you are utilizing), so I would have to do some digging to see why the fields are not in the 00hr files.

[jgf]

i guess i thought that f00 was the initialization..., so that for the 12z run, the data with a VT of 12z is the initialization, and that f03 is the first real forecast.

 

this is partly because when i look at the "inventory" page, they have one list for f00 and another list for all the other times. the list for 00 is missing things that are either averages or totals over the previous time interval.

 

i guess that on thinking about it, there is no reason why you couldn't initialize those quantities, but it makes sense that they wouldn't be in the first forecast

 

i have seen other files designated "analysis" - are you saying that they are the initialization?

[dtk]

i guess i thought that f00 was the initialization..., so that for the 12z run, the data with a VT of 12z is the initialization, and that f03 is the first real forecast.

 

this is partly because when i look at the "inventory" page, they have one list for f00 and another list for all the other times. the list for 00 is missing things that are either averages or totals over the previous time interval.

 

i guess that on thinking about it, there is no reason why you couldn't initialize those quantities, but it makes sense that they wouldn't be in the first forecast

 

i have seen other files designated "analysis" - are you saying that they are the initialization?

Files with an "anl" in the name (i.e. gfs.t06z.pgrb2banl) are derived from fields generated from the actual analysis/initialization code.  Files with F00 are actually derived from the model state after the very first time step (which for the current model is 120 seconds, I think).  Although this doesn't seem like a big deal, there is a significant adjustment that can occur in the first time step.  There are also many things that the model produces that the analysis/initialization does not (for example the cloud properties, surface fluxes, etc.), making the F00 quite useful in that regard.

[jgf]

the "anl" files do not appear to be gribs, or anything else i can recognize.

 

what are they?

[dtk]

the "anl" files do not appear to be gribs, or anything else i can recognize.

 

what are they?

There is a file called gfs.t00z.pgrbanl.grib2 that is made publicly available (where t00z is 00z obviously)....this is the post processed, grib2 output from the actual analysis/initialization.  There are also files called "sanl" and "sfcanl", but these are binary, model specific files (there is information out there on how to read/use these files, but it's non-trivial).

[jgf]

interesting..., so not only is f00 not the initialization..., it's not even the first forecast!

 

i note that the pgrbanl file doesn't have either the cloud cover parameter i asked about above, nor PRATE.

 

So does that mean they are not part of the analysis, and are not initialized?

 

thanks very much by by the way..., I really appreciate your taking the time to answer my questions.

[dtk]

interesting..., so not only is f00 not the initialization..., it's not even the first forecast!

 

i note that the pgrbanl file doesn't have either the cloud cover parameter i asked about above, nor PRATE.

 

So does that mean they are not part of the analysis, and are not initialized?

 

thanks very much by by the way..., I really appreciate your taking the time to answer my questions.

Well this is getting into some of the nitty gritty, so perhaps we can take the discussion off-line and I can help you get exactly what you need.

 

F00 is a forecast, valid for the very first model time step (I suspect some of the fields are labelled "analysis" when they in fact are not the actual analysis).  The pgrbanl file should be the only file that is different than other grib files, since it is derived from the actual analysis (and therefore none of the model diagnostic variables are yet computed, things like clouds, surface fluxes, etc.).  It is true that we do not analyze/initialize precipitation rate, surface fluxes, "total cloud %", and many, many other variables that you find in some of the grib output (as these are actually produced by the model itself).

 

In terms of what is actually initialized, the analysis updates the model state variables themselves.  For the GFS currently, this requires an update to the spectral coefficients (the gfs is a spectral model) for wind (in terms of vorticity & divergence), temperature, three tracers (specific humidity, ozone mixing ratio, and cloud liquid water mixing ratio), and surface pressure.  There is also and update once/day to the surface boundary conditions (SST, snow, ice, etc.).

 

The main point I should convey, all of the base grib files that are generated from the model states (this includes f00) are consistent and should in fact include the entire list of fields (including total cloud cover).  For example, digging into the f00 file from today's 00Z file, the total cloud variable is available:

 

$ wgrib2 -V gfs.t00z.pgrb2f00 | grep -i 'total cloud'

208:35451877:vt=2013011500:convective cloud layer:anl:TCDC Total Cloud Cover [%]:

 

If you expand the entry :

208:35451877:vt=2013011500:convective cloud layer:anl:TCDC Total Cloud Cover [%]:

    ndata=259920:undef=0:mean=0:min=0:max=0

    grid_template=0:

        lat-lon grid:(720 x 361) units 1e-06 input WE:NS output WE:SN res 48

        lat 90.000000 to -90.000000 by 0.500000

        lon 0.000000 to 359.500000 by 0.500000 #points=259920

Now, we produce many different files and things are disseminated in many different ways, so the problem is like somewhere in the middle in terms of what data is being passed where.  Hopefully this information helps clarify your questions. 

[DaculaWeather]

Awesome DTK, I find this fascinating, thanks for your insight, greatly appreciated!