How to interpret TGCLDIWP and ICLDIWP?

[jrvb]

From the variable documentation, and in my CAM history files, I see the following:

TGCLDIWP Total grid-box cloud ice water path kg/m2 dims=('time', 'lat', 'lon')
ICLDIWP In-cloud ice water path kg/m2 dims=('time', 'lev', 'lat', 'lon')

I initially assumed that ICLDIWP was the total kg of cloud ice in a (lat,lon,lev) voxel divided by the Earth surface area under that voxel, and that TGCLDIWP was the total kg of cloud ice in the column above a (lat,lon) grid cell divided by the area of that cell. In that case, I should have TGCLDIWP =~ ICLDIWP.sum('lev') but this is not what I see in my data.

Can someone help me understand these two variables?

Possibly related:

* What does "path" signify here? I would imagine a distance travelled, but that doesn't fit with the units.
* Is there a difference between "in-cloud" ice and other ice? Maybe TGCLDIWP counts more than in-cloud ice?

Thanks!

-Rob

 

[hannay]

Some concepts are explained here:

A New Two-Moment Bulk Stratiform Cloud Microphysics Scheme in the Community Atmosphere Model, Version 3 (CAM3). Part I: Description and Numerical Tests

Abstract A new two-moment stratiform cloud microphysics scheme in a general circulation model is described. Prognostic variables include cloud droplet and cloud ice mass mixing ratios and number concentrations. The scheme treats several microphysical processes, including hydrometeor collection...

journals.ametsoc.org

 

[jrvb]

Thanks much for the pointer, Cecile! From a quick skim, it looks like this describes some of the high-level aspects of the ice microphysics handling in CAM, which is helpful. I don't see any references to specific CAM output variables or definitions of what "ice water path" means, what "in-cloud" means in CAM, etc. So I guess I'm looking for something a bit more operational about the way some of these concepts have been realized in CAM. Do you happen to know of any resources like that?

Thanks!

-Rob

 

[mccluskey]

Hi Rob,

I can try to help! I took a look at the source code and the difference is likely due to a difference in the in-cloud quantity (ICLDIWP) vs. grid box quantity (TGCLDIWP). In each grid box there is a cloud fraction (variable name CLOUD); CLOUD is used to normalize cloud properties to determine in-cloud values. e.g., in-cloud ice water path = ice water path/cloud fraction. So, I think you just need to multiply the ICLDIWP by CLOUD to bring ICLDIWP back to grid box value.

I'm not sure what version of the model you are using, but try this:
TGCLDIWP =~ sum of ICLDIWP*CLOUD at each level

Hope that helps!!

 

[jrvb]

Hi Christina -

This is very helpful, thanks! Doing some quick checking, it looks like this is definitely the right direction. When I add up ICLDIWP across levels it is consistently > TGCLDIWP, which would make sense if the m^2 divisor for ICLDIWP is smaller. Multiplying by CLOUD before adding gets things closer, but the difference looks like more than roundoff error to me.

For fun, I took some lat,lon ranges, sorted the grid cells by TGCLDIWP and plotted values to compare. From my spot checks, it looks like (ICLDIWP * CLOUD).sum('lev') is usually (but not always) smaller than TGCLDIWP. It is often quite a bit smaller, so I expect there is some other thing happening here.

Here are a couple of illustrative lat,lon ranges:




Best,

-Rob