noaa-oar-arl / monetio

The Model and ObservatioN Evaluation Tool I/O package
https://monetio.readthedocs.io
MIT License
17 stars 30 forks source link

TROPOMI updates including pressure calculation #184

Closed zmoon closed 2 months ago

zmoon commented 3 months ago

Based on https://github.com/NCAR/monetio/pull/30/commits/98405e9c6634433ca6eb919813860e32dca523fd

cc: @dwfncar @mlirenzhenmayi @rrbuchholz

zmoon commented 2 months ago

Thanks @blychs for the comments.

blychs commented 2 months ago

Hi @zmoon , I was wondering on how exactly are you planning on adding PH and PHB to the _wrfchem_mm reader. I need equivalent variables for the _camx_mm reader, and was just calling them "layer_height_agl" and "topo_height" as part of solving Issue #189 , but would rather make the names consistent with whatever you make. I also need to choose on those names for the TEMPO MM utility. (That is a bit different from just adding PH and PHB, since PH and PHB include the topographic height as bottom_top_stagg=0) We would need to update every reader if we want TROPOMI and TEMPO to work with all of them, and having consistency would be useful. It shouldn't be too hard to make everything consistent to whatever choice you make.

zmoon commented 2 months ago

how exactly are you planning on adding PH and PHB to the _wrfchem_mm reader

@blychs I was just following what Meng had done, which was just add them to the var list. So I was assuming that means they are included in the model output or can be automatically derived via wrf-python getvar().

I need equivalent variables for the _camx_mm reader, and was just calling them "layer_height_agl" and "topo_height"

The reader already has height AGL and above MSL. I don't think the height of the topography comes out though, at least by default.

If @mlirenzhenmayi was only using PH, PHB to compute height as (PH+PHB)/g0, maybe we don't actually need them? And similar for P, PB.

blychs commented 2 months ago

@zmoon I thought that was mid layer height, whereas PH and PHB are the geopotential at the layer interface. This is quite useful, because then (PH + PHB)[:, 1:, :, :] - (PH + PHB)[:, -1, :, :]) / g0 is the layer thickness, which is needed for calculating the partial column. If this is not the case, please let me know, because my _camx_mm reader assumes it is, and I would have to change that (that is, I calculated the height at mid layer for that variable). (PH + PHB) / 9.81 at bottom_top_stagg=0 should be pretty much the topography, if I'm not wrong.

I don't think we need P, PB though. P + PB is just the pressure.

zmoon commented 2 months ago

@blychs I believe you are correct about the calculation. But if it's really the layer height thickness is needed, maybe we should have the reader return that instead, unless there is a chance of using the layer interface heights for something else.

Also for WRF-Chem reader it looks like getvar will give you the layer interface heights if you request "zstag". So maybe here we should use that.

blychs commented 2 months ago

@zmoon I am not sure about the calculations. Do you think that having the layer height could be useful to interpolate to other (intermediate) altitudes? I'm thinking mostly about the aircraft team - I know close to nothing about aircraft field campaigns. If it isn't, then changing this to layer thickness wouldn't be to hard.

mlirenzhenmayi commented 2 months ago

@zmoon @blychs PH and PHB are used to calculate the height for each layer, and then we can calculate the partial column for each layer. Pressure for each layer = PB + P, from WRF-Chem. It's used for averaging kernels revision, based on which we established a function of Pressure and averaging kernel for each layer from TROPOMI, interpolate the model pressure to TROPOMI pressure for each layer, and then get the layered averaging kernel for the model.

zmoon commented 2 months ago

Hi @mlirenzhenmayi thanks for the comments. Is it correct that PB + P is the pressure of the layer interfaces? To use for conservative vertical interp based on pressure, for example.

@rschwant and I think these calculations of interface height/pressure and layer height/pressure thickness might be better done inside the reader and assigned standardized variable names, like currently done for the mid-layer pressure/height. But that's outside the scope of this PR.

mlirenzhenmayi commented 2 months ago

Hi @mlirenzhenmayi thanks for the comments. Is it correct that PB + P is the pressure of the layer interfaces? To use for conservative vertical interp based on pressure, for example.

@rschwant and I think these calculations of interface height/pressure and layer height/pressure thickness might be better done inside the reader and assigned standardized variable names, like currently done for the mid-layer pressure/height. But that's outside the scope of this PR.

PB+P is the mid-layer pressure. Maybe it's the tricky part of WRF-Chem. WRF-Chem doesn't provide the standard mid-layer pressure, so we need to calculate it based on the PB and P. If there's a standard calculation for mid-layer pressure covering different models, we can use that instead of calculating separately.

rschwant commented 2 months ago

@mlirenzhenmayi I was more thinking that we can move your calculation for these variables into the WRF-Chem reader, since they are model dependent. And then each model will do these calculations differently. And the analysis code will just use the standard value across all the models. Does that make sense? This can be a version 2 satellite advancement once we start standardizing the code more too.

mlirenzhenmayi commented 2 months ago

@mlirenzhenmayi I was more thinking that we can move your calculation for these variables into the WRF-Chem reader, since they are model dependent. And then each model will do these calculations differently. And the analysis code will just use the standard value across all the models. Does that make sense? This can be a version 2 satellite advancement once we start standardizing the code more too.

I think that makes sense. I do have a separate calculation module for this: https://github.com/NOAA-CSL/MELODIES-MONET/blob/develop/melodies_monet/util/cal_mod_no2col.py . It can be straight forward to combine cal_mod_no2col.py with the reader.

zmoon commented 2 months ago

@mlirenzhenmayi I think the partial column calculation can be outside the reader (or inside, open to others' thoughts about that).

However, I do think it makes sense for the reader to provide the variables you need, instead of you needing to compute them from WRF-specific P,PB,PH,PHB,T.

[^1]: When surf_only_nc is false.

mlirenzhenmayi commented 2 months ago

@mlirenzhenmayi I think the partial column calculation can be outside the reader (or inside, open to others' thoughts about that).

However, I do think it makes sense for the reader to provide the variables you need, instead of you needing to compute them from WRF-specific P,PB,PH,PHB,T.

  • temperature is already provided1 as temperature_k (computed via T by wrf-python getvar)
  • pressure is already provided as pres_pa_mid (computed via P+PB by wrf-python getvar)
  • layer Δ z is not yet provided, we can add this (taking the diff of wrf-python getvar 'zstag')

Footnotes

  1. When surf_only_nc is false.

@zmoon The partial column calculation has already been calculated outside of the reader. It's done in cal_mod_no2col.py: https://github.com/NOAA-CSL/MELODIES-MONET/blob/develop/melodies_monet/util/cal_mod_no2col.py . I agree that the P, PB, PHB and PH should be read by default in the reader.