Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add 2001lvl qnwfa #126

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

gthompsnWRF
Copy link
Contributor

Existing entries of QNWFA and QNIFA variables coming from RAP/HRRR grib files are not treated same as all the microphysics variables with an extra fake surface level (2001.mb). This brings those 2 variables to be consistent with the same number of vertical levels. An alternative is to eliminate the fake surface level for all variables of cloud, rain, snow, etc. since it is falsified anyway; but this keeps the total number of levels for all incoming data the same as temperature, winds, humidity, etc.

…physical variables like QR, QS, QC, etc. with a pre-set false surface (2001.mb) level.
…physical variables like QR, QS, QC, etc. with a pre-set false surface (2001.mb) level.
@davegill
Copy link
Collaborator

@gthompsnWRF @mgduda
Greg,
This change impacts the monthly data:

========================================
name=QNWFA_DEC ; output_name=W_WIF_DEC
========================================
name=W_WIF_DEC
        z_dim_name=num_wif_levels
        interp_option=four_pt+average_4pt
        flag_in_output=FLAG_QNWFA
========================================

We already have the flags FLAG_QNWFA and FLAG_QNIFA associated with the monthly data. We need to look at this more carefully:

  1. If we rename a flag, there are several mods required in real.
  2. If we re-use a flag, then we have other concerns:
    a. Is each use still correct
    b. Is there a scenario where both data streams for QNIFA / QNWFA come in

I would like to push this to release-v4.1.1

@gthompsnWRF
Copy link
Contributor Author

@davegill Yes, I didn't catch the overlap with FLAG_QNWFA because I thought perhaps the each-month value might have done it differently. I think it would be safe to remove from my modification that these flags are set since they do not matter anyway. We have a mismatch of the Q* variables that I know have led to weird things in real.exe and I wish we could just resolve in a 4.1.1 with a proper fix - which may be to remove the false surface level data since we also know that 'use_sfc_level' in real is improper for all of these variables, except RH. However, I'm not sure how this would impact other things since we have always assumed same number of vertical levels for Temp, moist, etc. that typically have the 2-meter level in incoming data.

@mgduda
Copy link
Collaborator

mgduda commented Apr 20, 2020

@gthompsnWRF @davegill Should this PR be included in the v4.2 release?

@gthompsnWRF
Copy link
Contributor Author

I did things with my own WRF code to eliminate the bogus 2001 level - that way all MP species, moist & scalar only ever have WPS num_metgrid_levels since none of those make sense for a special 2-meter (or similar) level.

@mgduda
Copy link
Collaborator

mgduda commented Apr 20, 2020

@gthompsnWRF Sorry for being obtuse, but does this mean we can close this PR, or that we need to replace this PR with a different one?

@gthompsnWRF
Copy link
Contributor Author

@mgduda Actually, I mis-spoke/wrote! The number of levels for QNWFA and QNIFA depends on whether these data are coming in from another model (e.g., RAP/HRRR) or from the Climatology data. In a more recent PR from Pedro Jimenez, I believe he has now separated the two entirely, since we truly want a "climo" dataset to help set the surface flux 2D field (QNWFA2D) and, potentially, a separate first-guess field such as from RAP/HRRR on their native (50) levels. So the climo needs "num_wif_levels" whereas a parent model could supply a first guess. Lastly, if my memory serves, there was some code - perhaps it was in Real, that assumed we had MP moist/scalar variables at the fake 2001hPa level. I definitely wanted to eliminate that.

As the PR is now about a year old, parts of this storyline have been getting foggy in my brain.

@davegill
Copy link
Collaborator

@gthompsnWRF @mgduda @pedro-jm
Folks,
We are not modifying the way that we process these friendly aerosols in real for v4.2. When we do make that change in real, we can make a coordinated effort with WPS. There are problems in real with shared flags, packaging, and monthly data that need to be untangled.

Pedro has a PR that we chose to ignore for the v4.2 release of WRF: wrf-model/WRF#1158 "Improved logic to initialize aerosols in mp = 28"

@mgduda
Copy link
Collaborator

mgduda commented Apr 21, 2020

@davegill Is it your opinion that we should not include this PR in v4.2? Should this PR be closed or left open?

@davegill
Copy link
Collaborator

@mgduda @gthompsnWRF
Michael,
Let us leave this open. This will be part of a larger and coordinated commit to handle the Thompson aerosols in both WPS and WRF.

See the last set of comments by me in wrf-model/WRF#1158 "Improved logic to initialize aerosols in mp = 28".

@mgduda mgduda changed the base branch from release-v4.1 to develop April 21, 2020 16:55
@mgduda mgduda removed the v4.1.1 label Dec 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants