From d5bd80192de8f3406d9a53bf50cc87c01c1dad4e Mon Sep 17 00:00:00 2001 From: braczka Date: Mon, 9 Sep 2024 11:07:04 -0600 Subject: [PATCH 01/18] Remove GOES converter channel offset --- observations/obs_converters/GOES/goes_ABI_L1b_mod.f90 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/observations/obs_converters/GOES/goes_ABI_L1b_mod.f90 b/observations/obs_converters/GOES/goes_ABI_L1b_mod.f90 index 8681809939..65b81751aa 100644 --- a/observations/obs_converters/GOES/goes_ABI_L1b_mod.f90 +++ b/observations/obs_converters/GOES/goes_ABI_L1b_mod.f90 @@ -462,8 +462,9 @@ subroutine make_obs_sequence (seq, map, lon1, lon2, lat1, lat2, & specularity = MISSING_R8 end if - ! the RTTOV ABI coefficients start from channel 7 - goes_channel = map%channel-6 + ! Defines the GOES ABI wavelength channels (band_id) + ! Channels range from 1-16 covering UV/VIS/NIR/IR spectrum + goes_channel = map%channel ! add additional metadata for this obs type. returns key to use in create call call set_visir_metadata(key, sat_az, sat_ze, sun_az, sun_ze, platform_id, sat_id, sensor_id, & From 89932c4806b80927c763f5e073616bb8dc605e04 Mon Sep 17 00:00:00 2001 From: braczka Date: Mon, 9 Sep 2024 11:09:12 -0600 Subject: [PATCH 02/18] Enhance GOES converter docs --- observations/obs_converters/GOES/README.rst | 192 +++++++++++++------- 1 file changed, 125 insertions(+), 67 deletions(-) diff --git a/observations/obs_converters/GOES/README.rst b/observations/obs_converters/GOES/README.rst index 661ae5dd07..53d1a7a839 100644 --- a/observations/obs_converters/GOES/README.rst +++ b/observations/obs_converters/GOES/README.rst @@ -35,70 +35,128 @@ observation type). Specifying a vertical location ------------------------------ -Jeff Steward added (PR 48) the capability to specify a vertical location -if desired. This allows for localization in the vertical. - - It’s sometimes helpful, even though definitely wrong from a theoretical - standpoint, to give a vertical location to satellite observations - (which are integrated quantities). This has been an issue with - observation-space localization for some time, and this is the standard - workaround pioneered by Lili Lei and Jeff Whittaker. - -A short description of the namelist options -------------------------------------------- - -This table is meant to familiarize you with some of the options -available. Until we fully implement automatic documentation generation, -you would be well advised to familiarize yourself with the code. This is -not the full list of namelist variables … - -+-------------------------+---------------------+---------------------+ -| variable | default | meaning | -+=========================+=====================+=====================+ -| x_thin | 0 | Skip this many per | -| | | X scan. | -+-------------------------+---------------------+---------------------+ -| y_thin | 0 | Skip this many per | -| | | Y scan. | -+-------------------------+---------------------+---------------------+ -| goes_num | 16 | GOES Satellite | -| | | number. | -+-------------------------+---------------------+---------------------+ -| reject_dqf_1 | .true. | Bad scan rejection | -| | | criteria. If .true. | -| | | and DQF /= 0, the | -| | | scan is rejected. | -| | | If .false. any DQF | -| | | > 1 rejects the | -| | | scan. | -+-------------------------+---------------------+---------------------+ -| verbose | .false. | Run-time output | -| | | verbosity | -+-------------------------+---------------------+---------------------+ -| obs_err | MISSING_R8 | The observation | -| | | error standard | -| | | deviation (std dev, | -| | | in radiance units) | -| | | TODO: make this | -| | | more sophisticated. | -| | | You must supply a | -| | | value other than | -| | | MISSING_R8. Be | -| | | aware that the | -| | | observation | -| | | sequence files | -| | | convert this to a | -| | | variance. | -+-------------------------+---------------------+---------------------+ -| vloc_pres_hPa | -1.0 | The vertical | -| | | location of this | -| | | observation (hPa). | -| | | A negative means | -| | | there is no | -| | | vertical location | -| | | (which is typical | -| | | for a | -| | | ve | -| | | rtically-integrated | -| | | quantity). | -+-------------------------+---------------------+---------------------+ +Top of the atmosphere radiance observations are sensitive to the +atmospheric constituents (e.g. water vapor) that reside in the vertical +profile of the atmosphere. Given this is an integrated quantity and does +not depend on a single vertical location, it may be appropriate to leave +the vertical location unassigned (i.e. VERTISUNDEF) within the ``obs_seq.out`` +file. This approach, however, limits the application of vertical localization +during the assimilation step. + +Alternatively, for some applications it may be appropriate to assign +a vertical location to the radiance observation. This is an ongoing area +of observation-space localization research, and is the standard +workaround pioneered by Lili Lei and Jeff Whittaker. + +Radiance versus Brightness Temperature +-------------------------------------- + +This converter assigns the observation type as ``GOES[16-19]_ABI_RADIANCE``. +The default setup in DART is that this radiance observation type is assigned +the quantity ``QTY_RADIANCE``. Radiance observations are commonly expressed +in spectrally resolved units of mW/cm/m^2/sr. + +Alternatively, radiances can also be expressed as brightness temperatures +(units: Kelvin) and the DART code also supports observation quantities of +``QTY_BRIGHTNESS_TEMPERATURE``. Both the spectral and temperature units +quantify the same physical properties of the atmosphere +(emitted and reflected radiation), however, in some applications it may +be advantageous to use brightness temperatures given their Gaussian +distribution. This is an ongoing area of research. + + +An overview of the namelist options +----------------------------------- + +A description of the most important namelist options. Note that supplying +an observation error value is mandatory. This is not the full list of namelist +variables. + ++-------------------------+------------+-----------------------------+ +| Variable | Default | Description | ++=========================+============+=============================+ +| x_thin | 0 | Skip this many observations | +| | | per X scan | ++-------------------------+------------+-----------------------------+ +| y_thin | 0 | Skip this many observations | +| | | per Y scan | ++-------------------------+------------+-----------------------------+ +| goes_num | 16 | GOES Satellite number | ++-------------------------+------------+-----------------------------+ +| reject_dqf_1 | .true. | Bad scan rejection critera. | +| | | If .true. and DQF /= 0, the | +| | | scan is rejected. If | +| | | .false. any DQF > 1 | +| | | the scan. | ++-------------------------+------------+-----------------------------+ +| verbose | .false. | Run-time output verbosity | ++-------------------------+------------+-----------------------------+ +| obs_err | MISSING_R8 | The observation error | +| | | standard deviation in units | +| | | of radiance. IMPORTANT: | +| | | the user must supply a | +| | | value other than MISSING_R8 | +| | | Be aware that the | +| | | observation sequence files | +| | | convert this to a variance. | ++-------------------------+------------+-----------------------------+ +| vloc_pres_hPa | -1.0 | If a positive value, the | +| | | vertical location of the | +| | | observation (hPa), with | +| | | vertical coordinate of | +| | | VERTISPRESSURE. If negative | +| | | value there is no vertical | +| | | location and the coordinate | +| | | is VERTISUNDEFINED. | ++-------------------------+------------+-----------------------------+ + +Radiance metadata supplied to obs_seq.out file +---------------------------------------------- + +This converter is designed to supply metadata to the radiative transfer +model (RTTOV) :doc:`../../observations/forward_operators/obs_def_rttov_mod` +that supports the calculation of the expected radiance +observation during the assimilation step. Below is a description +of this metadata information. + +The integer values that describe the platform/satellite/sensor/channel +combination for the GOES satellite are required by the RTTOV radiance +model to assign the appropriate coefficent file during the radiance +calculation. For more details refer to the +`RTTOV user guide. `__ + + ++-------------------------+------------+-----------------------------+ +| Variable | Value | Description | ++=========================+============+=============================+ +| sat az/el | Supplied | GOES satellite azimuth and | +| | by data | elevation angle | +| | file | | ++-------------------------+------------+-----------------------------+ +| sun az/el | -888888 | Sun azimuth and elevation | +| | | angle. The default is for | +| | | missing values. For IR | +| | | channels reflected solar | +| | | has no impact. For NIR/ | +| | | VIS/UV providing sun az/el | +| | | may be desirable but not | +| | | required by RTTOV. | ++-------------------------+------------+-----------------------------+ +| platform | 4 | Platform number supplied | +| | | by converter code. | ++-------------------------+------------+-----------------------------+ +| sat_id | 16 | Satellite ID number | +| | | supplied by converter code. | ++-------------------------+------------+-----------------------------+ +| instrument | 44 | Sensor number supplied by | +| | | converter code | ++-------------------------+------------+-----------------------------+ +| channel | Supplied | The wavelength channel | +| | by data | (1-16) assigned from band_id| +| | file | variable in data file. | ++-------------------------+------------+-----------------------------+ + + + + + From f2f2e8dfc45067c740ce1b6a293b5bb026454d3f Mon Sep 17 00:00:00 2001 From: braczka Date: Mon, 9 Sep 2024 12:36:01 -0600 Subject: [PATCH 03/18] Enhance obs_def_RTTOV docs for coefficent files --- .../forward_operators/obs_def_rttov_mod.rst | 103 +++++++++++++++++- 1 file changed, 98 insertions(+), 5 deletions(-) diff --git a/observations/forward_operators/obs_def_rttov_mod.rst b/observations/forward_operators/obs_def_rttov_mod.rst index df98b706cc..d271328f61 100644 --- a/observations/forward_operators/obs_def_rttov_mod.rst +++ b/observations/forward_operators/obs_def_rttov_mod.rst @@ -46,19 +46,112 @@ Although a model may not have the necessary inputs by itself, the defaults in RTTOV based on climatology can be used. The impact on the quality of the results should be investigated. -The quanities for each observation type are defined in obs_def_rttov{13}_mod.f90, like so: +The quanities for each observation type are defined in obs_def_rttov{13}_mod.f90, for example: .. code:: - ! HIMAWARI_8_AHI_RADIANCE, QTY_RADIANCE + ! HIMAWARI_9_AHI_RADIANCE, QTY_RADIANCE If you want to change the quantity associated with an observation, for example, if you want -to assimilate HIMAWARI_8_AHI_RADIANCE as QTY_BRIGHTNESS_TEMPERATURE, edit the QTY -in obs_def_rttov{13}_mod.f90 and rerun quickbuild.sh. +to assimilate HIMAWARI_9_AHI_RADIANCE as QTY_BRIGHTNESS_TEMPERATURE, edit the QTY +in obs_def_rttov{13}_mod.f90 and rerun quickbuild.sh. Although both spectral radiance +(mW/cm/m^2/sr) and brightness temperature (Kelvin) quantify the same emitted/reflected +radiance from the atmosphere, the tendency for brightness temperatures to adhere closer +to a gaussian distribution may improve the quality of the assimilation overall if using +a DART filter type that depends on Gaussian assumptions (e.g. EAKF). This is +an ongoing area of research. -Known issues: +RTTOV Metadata +--------------- + +The RTTOV module ingests metadata from the ``obs_seq.out`` file in order to calculate the +expected observed radiance. For example, a single ``HIMAWARI_9_AHI_RADIANCE`` +synthetic observation in units of brightness temperature (Kelvin) looks like: + +.. code:: + + + OBS 1 + 288.370817896852 + 288.456378689407 + 0.000000000000000E+000 + -1 2 -1 + obdef + loc3d + 1.766273140907288 0.1535889655351639 34000.00000000000 2 + kind + 304 + visir + 100.500000000000 46.6700000000000 -888888.000000000 + -888888.000000000 + 31 9 56 8 + -888888.000000000 + 1 + 0 154166 + 1.00000000000000 + + +Please note, that in the radiance observation example a vertical level (34000 Pa) was +assigned to the observation with the ``VERTISPRESSURE`` (integer = 2) vertical coordinate. +Although radiance/BT observations are technically representative of the entire atmospheric +column and not a single vertical level, in some applications +this approximation improves the skill of the assimilation forecast. This is an ongoing +area of research. As an alternative, it is also common to leave the vertical level +as undefined (VERTISUNDEF, integer = -2), however this limits the ability to vertically +localize the impact of the observation on the model state. + +The RTTOV specific metadata is located after the ``visir`` line. This includes the +azimuth and elevation angle of the satellite and the sun respectively. Note, in this +instance the sun azimuth/elevation are given missing values (-888888) because solar +reflectance has no impact on an IR radiance observation. Also note, the observation +provides a 4 integer description (31/9/56/8) of the platform/satellite/sensor/channel +combination specific to this satellite observation. For more information on this +metadata refer to this GOES observation converter example here: +:doc:`../obs_converters/GOES/README.rst` + +**It is imperative that the user confirms the satellite integer metadata matches the +appropriate RTTOV coefficient (parameter) file. See next section for more information.** + +RTTOV coefficient files +----------------------- + +The RTTOV coefficent file contains the appropriate parameter values for a specific satellite +radiance observation. The RTTOV database file (``rttov_sensor_db.csv``) refers to the coefficent +file. For the ``HIMAWARI_9_AHI_RADIANCE`` observation type, for example, the following information +is provided: + +.. code:: + + HIMAWARI_9_AHI 31 9 56 ir rtcoef_himawari_9_ahi.dat + +The coefficent files (.dat) are included with the RTTOV installation and can be found at the +path ``~{RTTOV_install}/rtcoef_rttov13/rttov9pred54L/rtcoef_himawari_9_ahi.dat``. This file +should be included in your run folder at runtime. + +It is good practice to always view your coefficent file (.dat) to confirm that the +channels listed in the file include the channel from the ``obs_seq.out`` file. The coefficent +file will include a list of channels (wavebands) with the associated wavelength (microns). +For exammple the rtcoef_himawari_9_ahi.dat file looks like: + + + +.. Important :: + + The RTTOV package includes multiple coefficent files (e.g. all wavelengths, IR only, etc.) that + contain the appropriate parameter data for each satellite/sensor/channel combination. Whether + the file contains all wavelengths versus only IR wavelengths is **extremely important** because + it will shift the value of the channel number. If you subset your coefficent file to only include + IR channels, for example, you will also have to adjust your channel number in the obs_seq.out file. + If RTTOV always returns expected observations of radiance == 0, or if the prior expected radiance + is unusually biased from your prior, this could be a sign there is a mismatch between the + obs_seq.out channel and the coefficient file channel. + + + +Known issues: +------------- - DART does not yet provide any type of bias correction - Cross-channel error correlations are not yet supported. A principal component approach has been discussed. For now, the best bet is to use a subset of channels that are nearly independent of one another. From 7b00844c501891392b36e260e7a0e5849a0090e7 Mon Sep 17 00:00:00 2001 From: braczka Date: Mon, 9 Sep 2024 14:07:24 -0600 Subject: [PATCH 04/18] syntax corrections --- .../forward_operators/obs_def_rttov_mod.rst | 34 +++++++++++-------- observations/obs_converters/GOES/README.rst | 15 ++++---- 2 files changed, 27 insertions(+), 22 deletions(-) diff --git a/observations/forward_operators/obs_def_rttov_mod.rst b/observations/forward_operators/obs_def_rttov_mod.rst index d271328f61..fab68e5cc7 100644 --- a/observations/forward_operators/obs_def_rttov_mod.rst +++ b/observations/forward_operators/obs_def_rttov_mod.rst @@ -57,7 +57,7 @@ to assimilate HIMAWARI_9_AHI_RADIANCE as QTY_BRIGHTNESS_TEMPERATURE, edit the QT in obs_def_rttov{13}_mod.f90 and rerun quickbuild.sh. Although both spectral radiance (mW/cm/m^2/sr) and brightness temperature (Kelvin) quantify the same emitted/reflected radiance from the atmosphere, the tendency for brightness temperatures to adhere closer -to a gaussian distribution may improve the quality of the assimilation overall if using +to a gaussian distribution may improve the quality of the assimilation if using a DART filter type that depends on Gaussian assumptions (e.g. EAKF). This is an ongoing area of research. @@ -68,7 +68,7 @@ RTTOV Metadata The RTTOV module ingests metadata from the ``obs_seq.out`` file in order to calculate the expected observed radiance. For example, a single ``HIMAWARI_9_AHI_RADIANCE`` -synthetic observation in units of brightness temperature (Kelvin) looks like: +synthetic observation in units of brightness temperature (Kelvin) looks like the following: .. code:: @@ -93,13 +93,13 @@ synthetic observation in units of brightness temperature (Kelvin) looks like: 1.00000000000000 -Please note, that in the radiance observation example a vertical level (34000 Pa) was -assigned to the observation with the ``VERTISPRESSURE`` (integer = 2) vertical coordinate. +Please note, that in this example the radiance observation was assigned a vertical level (34000 Pa) +with the ``VERTISPRESSURE`` (integer = 2) vertical coordinate. Although radiance/BT observations are technically representative of the entire atmospheric column and not a single vertical level, in some applications this approximation improves the skill of the assimilation forecast. This is an ongoing area of research. As an alternative, it is also common to leave the vertical level -as undefined (VERTISUNDEF, integer = -2), however this limits the ability to vertically +as undefined (VERTISUNDEF, integer = -2), however, this limits the ability to vertically localize the impact of the observation on the model state. The RTTOV specific metadata is located after the ``visir`` line. This includes the @@ -109,10 +109,12 @@ reflectance has no impact on an IR radiance observation. Also note, the observa provides a 4 integer description (31/9/56/8) of the platform/satellite/sensor/channel combination specific to this satellite observation. For more information on this metadata refer to this GOES observation converter example here: -:doc:`../obs_converters/GOES/README.rst` +:doc:`../observations/obs_converters/GOES/README.rst` -**It is imperative that the user confirms the satellite integer metadata matches the -appropriate RTTOV coefficient (parameter) file. See next section for more information.** +.. Important :: + + **It is imperative that the user confirms the satellite integer metadata matches the + appropriate RTTOV coefficient (parameter) file. See next section for more information.** RTTOV coefficient files ----------------------- @@ -126,14 +128,15 @@ is provided: HIMAWARI_9_AHI 31 9 56 ir rtcoef_himawari_9_ahi.dat -The coefficent files (.dat) are included with the RTTOV installation and can be found at the -path ``~{RTTOV_install}/rtcoef_rttov13/rttov9pred54L/rtcoef_himawari_9_ahi.dat``. This file -should be included in your run folder at runtime. +The coefficent file (.dat) is included with the RTTOV installation and can be found at the +path ``~{RTTOV_install}/rtcoef_rttov13/rttov9pred54L/rtcoef_himawari_9_ahi.dat``. This file +should be included in your run folder at runtime. Additional coefficent files for a given +satellite sensor may be required. It is good practice to always view your coefficent file (.dat) to confirm that the -channels listed in the file include the channel from the ``obs_seq.out`` file. The coefficent +channels listed in the file match the channel from the ``obs_seq.out`` file. The coefficent file will include a list of channels (wavebands) with the associated wavelength (microns). -For exammple the rtcoef_himawari_9_ahi.dat file looks like: +For example the rtcoef_himawari_9_ahi.dat file looks like: @@ -142,9 +145,10 @@ For exammple the rtcoef_himawari_9_ahi.dat file looks like: The RTTOV package includes multiple coefficent files (e.g. all wavelengths, IR only, etc.) that contain the appropriate parameter data for each satellite/sensor/channel combination. Whether the file contains all wavelengths versus only IR wavelengths is **extremely important** because - it will shift the value of the channel number. If you subset your coefficent file to only include + it will shift the value of the channel number. Recommended practice is to choose a coefficient file + with all channels included, however, If you subset your coefficent file to only include IR channels, for example, you will also have to adjust your channel number in the obs_seq.out file. - If RTTOV always returns expected observations of radiance == 0, or if the prior expected radiance + If RTTOV always returns expected observations of radiance = 0, or if the prior expected radiance is unusually biased from your prior, this could be a sign there is a mismatch between the obs_seq.out channel and the coefficient file channel. diff --git a/observations/obs_converters/GOES/README.rst b/observations/obs_converters/GOES/README.rst index 53d1a7a839..7637d0a8c5 100644 --- a/observations/obs_converters/GOES/README.rst +++ b/observations/obs_converters/GOES/README.rst @@ -39,7 +39,7 @@ Top of the atmosphere radiance observations are sensitive to the atmospheric constituents (e.g. water vapor) that reside in the vertical profile of the atmosphere. Given this is an integrated quantity and does not depend on a single vertical location, it may be appropriate to leave -the vertical location unassigned (i.e. VERTISUNDEF) within the ``obs_seq.out`` +the vertical location undefined (i.e. VERTISUNDEF) within the ``obs_seq.out`` file. This approach, however, limits the application of vertical localization during the assimilation step. @@ -54,7 +54,7 @@ Radiance versus Brightness Temperature This converter assigns the observation type as ``GOES[16-19]_ABI_RADIANCE``. The default setup in DART is that this radiance observation type is assigned the quantity ``QTY_RADIANCE``. Radiance observations are commonly expressed -in spectrally resolved units of mW/cm/m^2/sr. +in spectrally resolved units (mW/cm/m^2/sr). Alternatively, radiances can also be expressed as brightness temperatures (units: Kelvin) and the DART code also supports observation quantities of @@ -87,7 +87,7 @@ variables. | | | If .true. and DQF /= 0, the | | | | scan is rejected. If | | | | .false. any DQF > 1 | -| | | the scan. | +| | | rejects the scan. | +-------------------------+------------+-----------------------------+ | verbose | .false. | Run-time output verbosity | +-------------------------+------------+-----------------------------+ @@ -95,15 +95,16 @@ variables. | | | standard deviation in units | | | | of radiance. IMPORTANT: | | | | the user must supply a | -| | | value other than MISSING_R8 | +| | | value other than MISSING_R8.| | | | Be aware that the | | | | observation sequence files | | | | convert this to a variance. | +-------------------------+------------+-----------------------------+ | vloc_pres_hPa | -1.0 | If a positive value, the | | | | vertical location of the | -| | | observation (hPa), with | -| | | vertical coordinate of | +| | | observation (hPa) is | +| | | assigned with a vertical | +| | | coordinate of | | | | VERTISPRESSURE. If negative | | | | value there is no vertical | | | | location and the coordinate | @@ -114,7 +115,7 @@ Radiance metadata supplied to obs_seq.out file ---------------------------------------------- This converter is designed to supply metadata to the radiative transfer -model (RTTOV) :doc:`../../observations/forward_operators/obs_def_rttov_mod` +model (RTTOV) :doc:`../../../observations/forward_operators/obs_def_rttov_mod` that supports the calculation of the expected radiance observation during the assimilation step. Below is a description of this metadata information. From e470a4a162a603198a9486d81ffbd22e05a01462 Mon Sep 17 00:00:00 2001 From: braczka Date: Mon, 9 Sep 2024 14:14:31 -0600 Subject: [PATCH 05/18] Remove unnecessary line of docs --- observations/forward_operators/obs_def_rttov_mod.rst | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/observations/forward_operators/obs_def_rttov_mod.rst b/observations/forward_operators/obs_def_rttov_mod.rst index fab68e5cc7..fb3c839913 100644 --- a/observations/forward_operators/obs_def_rttov_mod.rst +++ b/observations/forward_operators/obs_def_rttov_mod.rst @@ -136,8 +136,6 @@ satellite sensor may be required. It is good practice to always view your coefficent file (.dat) to confirm that the channels listed in the file match the channel from the ``obs_seq.out`` file. The coefficent file will include a list of channels (wavebands) with the associated wavelength (microns). -For example the rtcoef_himawari_9_ahi.dat file looks like: - .. Important :: @@ -146,8 +144,8 @@ For example the rtcoef_himawari_9_ahi.dat file looks like: contain the appropriate parameter data for each satellite/sensor/channel combination. Whether the file contains all wavelengths versus only IR wavelengths is **extremely important** because it will shift the value of the channel number. Recommended practice is to choose a coefficient file - with all channels included, however, If you subset your coefficent file to only include - IR channels, for example, you will also have to adjust your channel number in the obs_seq.out file. + with all channels included. If, on the other hand, you subset your coefficent file to only include + IR channels, you will also have to adjust your channel number in the obs_seq.out file. If RTTOV always returns expected observations of radiance = 0, or if the prior expected radiance is unusually biased from your prior, this could be a sign there is a mismatch between the obs_seq.out channel and the coefficient file channel. From 7031c9dd24831af754862b23d7d8244e7983b237 Mon Sep 17 00:00:00 2001 From: braczka Date: Mon, 9 Sep 2024 14:52:43 -0600 Subject: [PATCH 06/18] THM is mandatory WRF temp variable --- models/wrf/readme.rst | 13 ++++++++++++- models/wrf/tutorial/README.rst | 6 +++++- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/models/wrf/readme.rst b/models/wrf/readme.rst index ebb3227511..0e36421e67 100644 --- a/models/wrf/readme.rst +++ b/models/wrf/readme.rst @@ -24,7 +24,10 @@ Some important WRF-DART updates include: operator calculations. - Version 11.5.0: Improves compatibility with WRFv4+ versions where - the prognostic 3D temperature variable is THM. + the prognostic 3D temperature variable is THM. It is now mandatory to + include THM instead of T in the ``wrf_state_variables`` namelist. + + It is always recommended that you update your DART version to the `latest release `__ before beginning new research. @@ -336,6 +339,14 @@ For example: 'PSFC','QTY_PRESSURE','TYPE_PS','UPDATE','999', +.. Important:: + + It is mandatory to include ``THM`` instead of ``T`` as the ``TYPE_T`` WRF + temperature variable. This is because ``THM`` is the prognostic temperature variable + that will impact the forecast when updated. Also, including ``T`` can give + boundscheck errors as described in `issue #728. `__ + + - polar, periodic_x The ``Polar`` and ``periodic_x`` namelist values are used in global WRF simulations. diff --git a/models/wrf/tutorial/README.rst b/models/wrf/tutorial/README.rst index 2dd00180d9..4a0bd6c4e7 100644 --- a/models/wrf/tutorial/README.rst +++ b/models/wrf/tutorial/README.rst @@ -19,12 +19,16 @@ either WRF or DART. versions 11.4.0 and earlier because those older versions do not account for different coordinate systems including the sigma hybrid coordinates as described in `DART Issue #650 `__. + Furthermore, older versions do not account for the prognostic temperature variable switch from ``T`` (perturbation potential temperature) to ``THM``, (either perturbation potential temperature or perturbation moist potential temperature) as described in `DART issue #661 `__. The current implementation of the code sets ``T=THM`` because within &dynamics section of ``namelist.input`` - ``use_theta_m=0``. + ``use_theta_m=0``. For this reason, It is mandatory to include ``THM`` instead of + ``T`` as the ``TYPE_T`` within the wrf_state_variables namelist. Furthermore, including + ``T`` in the namelist can lead to errors in the WRF model_mod bounds check as + described in `Issue #728. `__ Earlier version of WRF (v3.9) may run without errors with more recent versions of DART (later than 11.4.0), but the assimilation performance will be deprecated. From 4f969a4f5db265941998de567e06c8c4d073d1da Mon Sep 17 00:00:00 2001 From: braczka Date: Wed, 2 Oct 2024 10:17:11 -0600 Subject: [PATCH 07/18] Make input.nml compatible with RTTOV13 --- .../obs_converters/GOES/work/input.nml | 88 ++----------------- 1 file changed, 9 insertions(+), 79 deletions(-) diff --git a/observations/obs_converters/GOES/work/input.nml b/observations/obs_converters/GOES/work/input.nml index 12dfacad97..4670d10498 100644 --- a/observations/obs_converters/GOES/work/input.nml +++ b/observations/obs_converters/GOES/work/input.nml @@ -5,7 +5,7 @@ output_obs_qty_mod_file = '../../../../assimilation_code/modules/observations/obs_kind_mod.f90' input_obs_def_mod_file = '../../../../observations/forward_operators/DEFAULT_obs_def_mod.F90' output_obs_def_mod_file = '../../../../observations/forward_operators/obs_def_mod.f90' - obs_type_files = '../../../../observations/forward_operators/obs_def_rttov_mod.f90' + obs_type_files = '../../../../observations/forward_operators/obs_def_rttov13_mod.f90' quantity_files = '../../../../assimilation_code/modules/observations/atmosphere_quantities_mod.f90', '../../../../assimilation_code/modules/observations/chemistry_quantities_mod.f90', '../../../../assimilation_code/modules/observations/land_quantities_mod.f90', @@ -13,15 +13,15 @@ / &convert_goes_ABI_L1b_nml - l1_files = '' - l1_file_list = 'l1_files_to_process' + l1_files = 'OR_ABI-L1b-RadF-M6C08_G16_s20211841720210_e20211841729518_c20211841729575.nc' + l1_file_list = '' outputfile = 'obs_seq.test' - x_thin = 5 - y_thin = 5 - lon1 = 235.0 - lon2 = 293.0 - lat1 = 25.0 - lat2 = 50.0 + x_thin = 7 + y_thin = 7 + lon1 = -80.2 + lon2 = -71.8 + lat1 = 14.9 + lat2 = 22.1 goes_num = 16 obs_err = 1.0 verbose = .true. @@ -83,74 +83,4 @@ &obs_def_rttov_nml rttov_sensor_db_file = '../../../forward_operators/rttov_sensor_db.csv' - first_lvl_is_sfc = .true. - mw_clear_sky_only = .false. - interp_mode = 1 - do_checkinput = .true. - apply_reg_limits = .true. - verbose = .true. - fix_hgpl = .false. - do_lambertian = .false. - lambertian_fixed_angle = .true. - rad_down_lin_tau = .true. - use_q2m = .true. - use_uv10m = .true. - use_wfetch = .false. - use_water_type = .false. - addrefrac = .false. - plane_parallel = .false. - use_salinity = .false. - apply_band_correction = .true. - cfrac_data = .true. - clw_data = .true. - rain_data = .true. - ciw_data = .true. - snow_data = .true. - graupel_data = .true. - hail_data = .false. - w_data = .true. - clw_scheme = 1 - clw_cloud_top = 322. - fastem_version = 6 - supply_foam_fraction = .false. - use_totalice = .true. - use_zeeman = .false. - cc_threshold = 0.05 - ozone_data = .false. - co2_data = .false. - n2o_data = .false. - co_data = .false. - ch4_data = .false. - so2_data = .false. - addsolar = .false. - rayleigh_single_scatt = .true. - do_nlte_correction = .false. - solar_sea_brdf_model = 2 - ir_sea_emis_model = 2 - use_sfc_snow_frac = .false. - add_aerosl = .false. - aerosl_type = 1 - add_clouds = .true. - ice_scheme = 1 - use_icede = .false. - idg_scheme = 2 - user_aer_opt_param = .false. - user_cld_opt_param = .false. - grid_box_avg_cloud = .true. - cldstr_threshold = -1.0 - cldstr_simple = .false. - cldstr_low_cloud_top = 750.0 - ir_scatt_model = 2 - vis_scatt_model = 1 - dom_nstreams = 8 - dom_accuracy = 0.0 - dom_opdep_threshold = 0.0 - addpc = .false. - npcscores = -1 - addradrec = .false. - ipcreg = 1 - use_htfrtc = .false. - htfrtc_n_pc = -1 - htfrtc_simple_cloud = .false. - htfrtc_overcast = .false. / From 02c92ad0edb05d4007b4339f5119da0742f9def8 Mon Sep 17 00:00:00 2001 From: braczka Date: Wed, 2 Oct 2024 17:45:56 -0600 Subject: [PATCH 08/18] Review edits for obs_def_rttov docs --- .../forward_operators/obs_def_rttov_mod.rst | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/observations/forward_operators/obs_def_rttov_mod.rst b/observations/forward_operators/obs_def_rttov_mod.rst index fb3c839913..c7cfe86947 100644 --- a/observations/forward_operators/obs_def_rttov_mod.rst +++ b/observations/forward_operators/obs_def_rttov_mod.rst @@ -74,8 +74,7 @@ synthetic observation in units of brightness temperature (Kelvin) looks like the OBS 1 - 288.370817896852 - 288.456378689407 + 288.370817896852 0.000000000000000E+000 -1 2 -1 obdef @@ -102,14 +101,14 @@ area of research. As an alternative, it is also common to leave the vertical lev as undefined (VERTISUNDEF, integer = -2), however, this limits the ability to vertically localize the impact of the observation on the model state. -The RTTOV specific metadata is located after the ``visir`` line. This includes the -azimuth and elevation angle of the satellite and the sun respectively. Note, in this -instance the sun azimuth/elevation are given missing values (-888888) because solar -reflectance has no impact on an IR radiance observation. Also note, the observation +In this example where the observation is infrared (IR) radiance, the metadata is located after +the ``visir`` line (Note: for microwave observations the metadata would follow 'mw'). +The metadata includes the azimuth and elevation angle of the satellite and the sun respectively. In this instance the sun azimuth/elevation are given missing values (-888888) because +solar reflectance has no impact on an IR radiance observation. Also note, the observation provides a 4 integer description (31/9/56/8) of the platform/satellite/sensor/channel combination specific to this satellite observation. For more information on this metadata refer to this GOES observation converter example here: -:doc:`../observations/obs_converters/GOES/README.rst` +:doc:`../../observations/obs_converters/GOES/README` .. Important :: @@ -129,7 +128,7 @@ is provided: HIMAWARI_9_AHI 31 9 56 ir rtcoef_himawari_9_ahi.dat The coefficent file (.dat) is included with the RTTOV installation and can be found at the -path ``~{RTTOV_install}/rtcoef_rttov13/rttov9pred54L/rtcoef_himawari_9_ahi.dat``. This file +path ``${RTTOV_install}/rtcoef_rttov13/rttov9pred54L/rtcoef_himawari_9_ahi.dat``. This file should be included in your run folder at runtime. Additional coefficent files for a given satellite sensor may be required. @@ -145,7 +144,7 @@ file will include a list of channels (wavebands) with the associated wavelength the file contains all wavelengths versus only IR wavelengths is **extremely important** because it will shift the value of the channel number. Recommended practice is to choose a coefficient file with all channels included. If, on the other hand, you subset your coefficent file to only include - IR channels, you will also have to adjust your channel number in the obs_seq.out file. + IR channels, you should edit your observation converter file such that the channels match. If RTTOV always returns expected observations of radiance = 0, or if the prior expected radiance is unusually biased from your prior, this could be a sign there is a mismatch between the obs_seq.out channel and the coefficient file channel. From 775e1bdad9b7aee80a12a6ffa852fa0711ff3d8b Mon Sep 17 00:00:00 2001 From: braczka Date: Wed, 2 Oct 2024 18:35:57 -0600 Subject: [PATCH 09/18] Review edits for channel metadata --- .../forward_operators/obs_def_rttov_mod.rst | 24 +++++++++++-------- observations/obs_converters/GOES/README.rst | 7 +++--- 2 files changed, 18 insertions(+), 13 deletions(-) diff --git a/observations/forward_operators/obs_def_rttov_mod.rst b/observations/forward_operators/obs_def_rttov_mod.rst index c7cfe86947..ba9b164eeb 100644 --- a/observations/forward_operators/obs_def_rttov_mod.rst +++ b/observations/forward_operators/obs_def_rttov_mod.rst @@ -112,16 +112,18 @@ metadata refer to this GOES observation converter example here: .. Important :: - **It is imperative that the user confirms the satellite integer metadata matches the - appropriate RTTOV coefficient (parameter) file. See next section for more information.** + **It is important that the user confirms the satellite integer metadata within + the obs_seq.out file matches the metadata within rttov_sensor_db.csv. Furthermore, + confirm that the channel as defined in the obs_seq.out file matches the channel + available in the RTTOV coefficient file (.dat). See next section for more information.** RTTOV coefficient files ----------------------- -The RTTOV coefficent file contains the appropriate parameter values for a specific satellite -radiance observation. The RTTOV database file (``rttov_sensor_db.csv``) refers to the coefficent +The RTTOV coefficent file (.dat) contains the appropriate parameter values for a specific satellite +radiance observation. The DART file (``rttov_sensor_db.csv``) refers to the RTTOV coefficent file. For the ``HIMAWARI_9_AHI_RADIANCE`` observation type, for example, the following information -is provided: +is provided within ``rttov_sensor_db.csv``: .. code:: @@ -253,11 +255,13 @@ RTTOV v12 Namelist +------------------------+--------------------+----------------------------------------------------------------------+ | Item | Type | Description | +========================+====================+======================================================================+ - | rttov_sensor_db_file | character(len=512) | The location of the RTTOV sensor database. The format for the | - | | | database is a comma-separated file. The columns of the database are | - | | | the DART observation-kind, the platform/satellite/sensor ID, the | - | | | observation type, the coefficient file, and a comma-separated list | - | | | of RTTOV channels to use for this observation type. | + | rttov_sensor_db_file | character(len=512) | The location of the DART file with RTTOV sensor metadata. The format | + | | | is a comma-separated file. The columns are the DART | + | | | observation type, the platform/satellite/sensor ID, the | + | | | wavelength band, the coefficient file, and a comma-separated list | + | | | of RTTOV channels to use for this observation type. The default file | + | | | does not provide a list of channels, thus default behavior is to | + | | | make all channels available. | +------------------------+--------------------+----------------------------------------------------------------------+ | first_lvl_is_sfc | logical | Whether the first level of the model represents the surface (true) | | | | or the top of the atmosphere (false). | diff --git a/observations/obs_converters/GOES/README.rst b/observations/obs_converters/GOES/README.rst index 7637d0a8c5..5dea404be9 100644 --- a/observations/obs_converters/GOES/README.rst +++ b/observations/obs_converters/GOES/README.rst @@ -40,11 +40,12 @@ atmospheric constituents (e.g. water vapor) that reside in the vertical profile of the atmosphere. Given this is an integrated quantity and does not depend on a single vertical location, it may be appropriate to leave the vertical location undefined (i.e. VERTISUNDEF) within the ``obs_seq.out`` -file. This approach, however, limits the application of vertical localization -during the assimilation step. +file, by setting the ``vloc_pres_hPa = -1`` (See namelist options below). This approach, +however, limits the application of vertical localization during the assimilation step. Alternatively, for some applications it may be appropriate to assign -a vertical location to the radiance observation. This is an ongoing area +a vertical location to the radiance observation, by setting the ``vloc_pres_hPa`` +to the appropriate pressure level. This is an ongoing area of observation-space localization research, and is the standard workaround pioneered by Lili Lei and Jeff Whittaker. From ddfec02420f8a580b07bdd8424b6109aecc30d55 Mon Sep 17 00:00:00 2001 From: braczka Date: Thu, 3 Oct 2024 08:24:16 -0600 Subject: [PATCH 10/18] More docs on radiance channel settings --- .../forward_operators/obs_def_rttov_mod.rst | 31 ++++++++++--------- observations/obs_converters/GOES/README.rst | 2 +- 2 files changed, 18 insertions(+), 15 deletions(-) diff --git a/observations/forward_operators/obs_def_rttov_mod.rst b/observations/forward_operators/obs_def_rttov_mod.rst index ba9b164eeb..7e65f32a01 100644 --- a/observations/forward_operators/obs_def_rttov_mod.rst +++ b/observations/forward_operators/obs_def_rttov_mod.rst @@ -6,7 +6,7 @@ MODULE ``obs_def_rttov_mod`` Overview -------- -DART RTTOV observation module, including the observation operators for the two primary +The DART RTTOV observation module, including the observation operators for the two primary RTTOV-observation types -- visible/infrared radiances and microwave radiances/brightness temperatures. @@ -68,7 +68,7 @@ RTTOV Metadata The RTTOV module ingests metadata from the ``obs_seq.out`` file in order to calculate the expected observed radiance. For example, a single ``HIMAWARI_9_AHI_RADIANCE`` -synthetic observation in units of brightness temperature (Kelvin) looks like the following: +observation in units of brightness temperature (Kelvin) looks like the following: .. code:: @@ -95,14 +95,15 @@ synthetic observation in units of brightness temperature (Kelvin) looks like the Please note, that in this example the radiance observation was assigned a vertical level (34000 Pa) with the ``VERTISPRESSURE`` (integer = 2) vertical coordinate. Although radiance/BT observations are technically representative of the entire atmospheric -column and not a single vertical level, in some applications -this approximation improves the skill of the assimilation forecast. This is an ongoing +column and not a single vertical level, for some applications where specific channels (wavelength) +are especially sensitive to constituents at particular atmospheric levels, assigning +a vertical level to the observation may improve the skill of the assimilation forecast. This is an ongoing area of research. As an alternative, it is also common to leave the vertical level as undefined (VERTISUNDEF, integer = -2), however, this limits the ability to vertically localize the impact of the observation on the model state. In this example where the observation is infrared (IR) radiance, the metadata is located after -the ``visir`` line (Note: for microwave observations the metadata would follow 'mw'). +the ``visir`` line (Note: for microwave observations the metadata would follow ``mw``). The metadata includes the azimuth and elevation angle of the satellite and the sun respectively. In this instance the sun azimuth/elevation are given missing values (-888888) because solar reflectance has no impact on an IR radiance observation. Also note, the observation provides a 4 integer description (31/9/56/8) of the platform/satellite/sensor/channel @@ -112,10 +113,10 @@ metadata refer to this GOES observation converter example here: .. Important :: - **It is important that the user confirms the satellite integer metadata within + It is important that the user confirms the satellite integer metadata within the obs_seq.out file matches the metadata within rttov_sensor_db.csv. Furthermore, confirm that the channel as defined in the obs_seq.out file matches the channel - available in the RTTOV coefficient file (.dat). See next section for more information.** + available in the RTTOV coefficient file (.dat). See next section for more information. RTTOV coefficient files ----------------------- @@ -146,7 +147,7 @@ file will include a list of channels (wavebands) with the associated wavelength the file contains all wavelengths versus only IR wavelengths is **extremely important** because it will shift the value of the channel number. Recommended practice is to choose a coefficient file with all channels included. If, on the other hand, you subset your coefficent file to only include - IR channels, you should edit your observation converter file such that the channels match. + IR channels, you should edit your observation converter such that the channels match. If RTTOV always returns expected observations of radiance = 0, or if the prior expected radiance is unusually biased from your prior, this could be a sign there is a mismatch between the obs_seq.out channel and the coefficient file channel. @@ -155,12 +156,14 @@ file will include a list of channels (wavebands) with the associated wavelength Known issues: ------------- -- DART does not yet provide any type of bias correction -- Cross-channel error correlations are not yet supported. A principal component approach has been discussed. For now, - the best bet is to use a subset of channels that are nearly independent of one another. -- Vertical localization will need to be tuned. Turning off vertical localization may work well if you have a large - number of ensemble members. Using the maximum peak of the weighting function or the cloud-top may be appropriate. - There are also other potential approaches being investigated. +- DART does not provide any type of observation bias correction. It may be appropriate to preprocess your radiance + observations to remove systematic bias before assimilation, using techniques such as cumulative distribution + function (CDF) matching. +- Cross-channel error correlations are not supported. A principal component approach has been discussed. For now, + we recommend to use a subset of channels that are nearly independent of one another. +- Vertical localization will need to be tuned based on the research application. Turning off vertical localization + may work well if you have a large number of ensemble members. Using the maximum peak of the channel weighting + function or the cloud-top height to set a vertical location for an observation may be appropriate. The namelist ``&obs_def_rttov_mod_nml`` is read from file ``input.nml``. Namelists start with an ampersand '&' diff --git a/observations/obs_converters/GOES/README.rst b/observations/obs_converters/GOES/README.rst index 5dea404be9..08d1bcac69 100644 --- a/observations/obs_converters/GOES/README.rst +++ b/observations/obs_converters/GOES/README.rst @@ -45,7 +45,7 @@ however, limits the application of vertical localization during the assimilation Alternatively, for some applications it may be appropriate to assign a vertical location to the radiance observation, by setting the ``vloc_pres_hPa`` -to the appropriate pressure level. This is an ongoing area +to a vertical pressure level (hPa). This is an ongoing area of observation-space localization research, and is the standard workaround pioneered by Lili Lei and Jeff Whittaker. From c9a330bab340a3888e0d54fe511720705d873cac Mon Sep 17 00:00:00 2001 From: braczka Date: Thu, 3 Oct 2024 08:33:31 -0600 Subject: [PATCH 11/18] Ignore GOES obs converter exec --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 7874132504..f306e88a3c 100644 --- a/.gitignore +++ b/.gitignore @@ -168,6 +168,7 @@ L1_AMSUA_to_netcdf convert_airs_L2 convert_amsu_L1 convert_L2b +convert_goes_ABI_L1b # Test programs built by developer_tests rttov_test From 0f5f41616243770c550c810d3ec1679e1d554ada Mon Sep 17 00:00:00 2001 From: braczka Date: Thu, 3 Oct 2024 16:09:29 -0600 Subject: [PATCH 12/18] Force error for WRF variable T --- models/wrf/model_mod.f90 | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/models/wrf/model_mod.f90 b/models/wrf/model_mod.f90 index 9ca5ddbe74..82684bb995 100644 --- a/models/wrf/model_mod.f90 +++ b/models/wrf/model_mod.f90 @@ -694,6 +694,19 @@ subroutine static_init_model() ! JPH now that we have the domain ID just go ahead and get type indices once ! NOTE: this is not strictly necessary - can use only stagger info in the future (???) + + ! If using WRF temperature variable 'T' instead of 'THM' fail immediately to + ! prevent boundscheck errors. For WRFv4 and later version variable 'T' is + ! diagnostic, thus updating the 'THM' variable (prognostic) is preferred. + + if ( wrf%dom(id)%type_t >= 0 .and. get_type_ind_from_type_string(id,'T') >=0) then + + write(errstring,*)'WRF temperature variable T in model_nml must be replaced & + with THM for WRFv4 and later' + call error_handler(E_ERR,'static_init_model', errstring, source, revision, revdate) + + endif + wrf%dom(id)%type_u = get_type_ind_from_type_string(id,'U') wrf%dom(id)%type_v = get_type_ind_from_type_string(id,'V') wrf%dom(id)%type_w = get_type_ind_from_type_string(id,'W') From fac042b175cb936cfe516f3dbb7715a8e6c8076d Mon Sep 17 00:00:00 2001 From: braczka Date: Wed, 9 Oct 2024 08:38:28 -0600 Subject: [PATCH 13/18] Simplify THM error call --- models/wrf/model_mod.f90 | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/models/wrf/model_mod.f90 b/models/wrf/model_mod.f90 index 82684bb995..45c5967947 100644 --- a/models/wrf/model_mod.f90 +++ b/models/wrf/model_mod.f90 @@ -695,14 +695,10 @@ subroutine static_init_model() ! JPH now that we have the domain ID just go ahead and get type indices once ! NOTE: this is not strictly necessary - can use only stagger info in the future (???) - ! If using WRF temperature variable 'T' instead of 'THM' fail immediately to - ! prevent boundscheck errors. For WRFv4 and later version variable 'T' is - ! diagnostic, thus updating the 'THM' variable (prognostic) is preferred. - - if ( wrf%dom(id)%type_t >= 0 .and. get_type_ind_from_type_string(id,'T') >=0) then + if (get_type_ind_from_type_string(id,'T') >=0) then - write(errstring,*)'WRF temperature variable T in model_nml must be replaced & - with THM for WRFv4 and later' + write(errstring,*)'WRF temperature variable T in model_nml must be replaced', & + ' with THM for WRFv4 and later' call error_handler(E_ERR,'static_init_model', errstring, source, revision, revdate) endif @@ -747,6 +743,23 @@ subroutine static_init_model() !wrf%dom(id)%type_fall_spd = get_type_ind_from_type_string(id,'VT_DBZ_WT') wrf%dom(id)%type_hdiab = get_type_ind_from_type_string(id,'H_DIABATIC') + ! If using WRF temperature variable 'T' instead of 'THM' fail immediately to + ! prevent boundscheck errors. For WRFv4 and later version variable 'T' is + ! diagnostic, thus updating the 'THM' variable (prognostic) is preferred. + + if ( wrf%dom(id)%type_t >= 0 .and. get_type_ind_from_type_string(id,'T') >=0) then + + write(errstring,*)'WRF temperature variable T in model_nml must be replaced & + with THM for WRFv4 and later' + call error_handler(E_ERR,'static_init_model', errstring, source, revision, revdate) + + endif + + + + + + ! variable bound table for setting upper and lower bounds of variables var_bounds_table(1:wrf%dom(id)%number_of_wrf_variables,1) = wrf%dom(id)%lower_bound var_bounds_table(1:wrf%dom(id)%number_of_wrf_variables,2) = wrf%dom(id)%upper_bound From 934d82ed8e022bda3b7ae78c0a7ffb11cbb4d3f0 Mon Sep 17 00:00:00 2001 From: braczka Date: Wed, 9 Oct 2024 08:42:01 -0600 Subject: [PATCH 14/18] Correct THM error call --- models/wrf/model_mod.f90 | 22 +++++----------------- 1 file changed, 5 insertions(+), 17 deletions(-) diff --git a/models/wrf/model_mod.f90 b/models/wrf/model_mod.f90 index 45c5967947..9f135421b7 100644 --- a/models/wrf/model_mod.f90 +++ b/models/wrf/model_mod.f90 @@ -695,6 +695,11 @@ subroutine static_init_model() ! JPH now that we have the domain ID just go ahead and get type indices once ! NOTE: this is not strictly necessary - can use only stagger info in the future (???) + ! If using WRF temperature variable 'T' instead of 'THM' fail immediately to + ! prevent boundscheck errors. For WRFv4 and later version variable 'T' is + ! diagnostic, thus updating the 'THM' variable (prognostic) is preferred. + + if (get_type_ind_from_type_string(id,'T') >=0) then write(errstring,*)'WRF temperature variable T in model_nml must be replaced', & @@ -743,23 +748,6 @@ subroutine static_init_model() !wrf%dom(id)%type_fall_spd = get_type_ind_from_type_string(id,'VT_DBZ_WT') wrf%dom(id)%type_hdiab = get_type_ind_from_type_string(id,'H_DIABATIC') - ! If using WRF temperature variable 'T' instead of 'THM' fail immediately to - ! prevent boundscheck errors. For WRFv4 and later version variable 'T' is - ! diagnostic, thus updating the 'THM' variable (prognostic) is preferred. - - if ( wrf%dom(id)%type_t >= 0 .and. get_type_ind_from_type_string(id,'T') >=0) then - - write(errstring,*)'WRF temperature variable T in model_nml must be replaced & - with THM for WRFv4 and later' - call error_handler(E_ERR,'static_init_model', errstring, source, revision, revdate) - - endif - - - - - - ! variable bound table for setting upper and lower bounds of variables var_bounds_table(1:wrf%dom(id)%number_of_wrf_variables,1) = wrf%dom(id)%lower_bound var_bounds_table(1:wrf%dom(id)%number_of_wrf_variables,2) = wrf%dom(id)%upper_bound From 2d99f18ee4b8ffc2e2c5c94d958590f10c7b3cb0 Mon Sep 17 00:00:00 2001 From: braczka Date: Thu, 10 Oct 2024 15:42:29 -0600 Subject: [PATCH 15/18] Enforcing inclusion of THM --- models/wrf/model_mod.f90 | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/models/wrf/model_mod.f90 b/models/wrf/model_mod.f90 index 9f135421b7..381c60cc16 100644 --- a/models/wrf/model_mod.f90 +++ b/models/wrf/model_mod.f90 @@ -695,15 +695,17 @@ subroutine static_init_model() ! JPH now that we have the domain ID just go ahead and get type indices once ! NOTE: this is not strictly necessary - can use only stagger info in the future (???) - ! If using WRF temperature variable 'T' instead of 'THM' fail immediately to - ! prevent boundscheck errors. For WRFv4 and later version variable 'T' is - ! diagnostic, thus updating the 'THM' variable (prognostic) is preferred. + ! The model_nml must contain WRF temperature variable 'THM' to + ! prevent boundcheck error. For WRFv4 and later versions variable 'T' is + ! diagnostic, thus updating the 'THM' variable (prognostic) is also preferred + ! for all DA applications. + - if (get_type_ind_from_type_string(id,'T') >=0) then + if (get_type_ind_from_type_string(id,'T') >=0 .or. get_type_ind_from_type_string(id,'THM') <=0) then - write(errstring,*)'WRF temperature variable T in model_nml must be replaced', & - ' with THM for WRFv4 and later' + write(errstring,*)'WRF temperature variable THM must appear in DART model_nml', & + ' for WRFv4 and later' call error_handler(E_ERR,'static_init_model', errstring, source, revision, revdate) endif From 75b25ce5803faf0c6b8ef3681ce60b1c5746670c Mon Sep 17 00:00:00 2001 From: Brett Raczka Date: Tue, 22 Oct 2024 10:57:06 -0600 Subject: [PATCH 16/18] Apply suggestions from code review Co-authored-by: Helen Kershaw <20047007+hkershaw-brown@users.noreply.github.com> --- models/wrf/readme.rst | 3 +-- models/wrf/tutorial/README.rst | 4 +--- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/models/wrf/readme.rst b/models/wrf/readme.rst index 0e36421e67..04fc4267b0 100644 --- a/models/wrf/readme.rst +++ b/models/wrf/readme.rst @@ -343,8 +343,7 @@ For example: It is mandatory to include ``THM`` instead of ``T`` as the ``TYPE_T`` WRF temperature variable. This is because ``THM`` is the prognostic temperature variable - that will impact the forecast when updated. Also, including ``T`` can give - boundscheck errors as described in `issue #728. `__ + that will impact the forecast when updated. - polar, periodic_x diff --git a/models/wrf/tutorial/README.rst b/models/wrf/tutorial/README.rst index 4a0bd6c4e7..6e3a7be73c 100644 --- a/models/wrf/tutorial/README.rst +++ b/models/wrf/tutorial/README.rst @@ -26,9 +26,7 @@ either WRF or DART. `DART issue #661 `__. The current implementation of the code sets ``T=THM`` because within &dynamics section of ``namelist.input`` ``use_theta_m=0``. For this reason, It is mandatory to include ``THM`` instead of - ``T`` as the ``TYPE_T`` within the wrf_state_variables namelist. Furthermore, including - ``T`` in the namelist can lead to errors in the WRF model_mod bounds check as - described in `Issue #728. `__ + ``T`` as the ``TYPE_T`` within the wrf_state_variables namelist. Earlier version of WRF (v3.9) may run without errors with more recent versions of DART (later than 11.4.0), but the assimilation performance will be deprecated. From 95fbd1af91ea9cfa7a2fb6c80263536c52d9c839 Mon Sep 17 00:00:00 2001 From: braczka Date: Tue, 22 Oct 2024 10:58:30 -0600 Subject: [PATCH 17/18] Editing boundscheck error comment --- models/wrf/model_mod.f90 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/models/wrf/model_mod.f90 b/models/wrf/model_mod.f90 index 381c60cc16..b481672949 100644 --- a/models/wrf/model_mod.f90 +++ b/models/wrf/model_mod.f90 @@ -695,8 +695,8 @@ subroutine static_init_model() ! JPH now that we have the domain ID just go ahead and get type indices once ! NOTE: this is not strictly necessary - can use only stagger info in the future (???) - ! The model_nml must contain WRF temperature variable 'THM' to - ! prevent boundcheck error. For WRFv4 and later versions variable 'T' is + ! Prevent boundscheck error by making WRF temperature variable 'THM' as mandatory. + ! Also, for WRFv4 and later versions variable 'T' is ! diagnostic, thus updating the 'THM' variable (prognostic) is also preferred ! for all DA applications. From effe72017db24f894d1abc570507e67250c5131a Mon Sep 17 00:00:00 2001 From: Helen Kershaw Date: Tue, 22 Oct 2024 14:29:04 -0400 Subject: [PATCH 18/18] bump version and changelog for release --- CHANGELOG.rst | 5 +++++ conf.py | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.rst b/CHANGELOG.rst index 8bc9db08b3..b466545457 100644 --- a/CHANGELOG.rst +++ b/CHANGELOG.rst @@ -22,6 +22,11 @@ individual files. The changes are now listed with the most recent at the top. +**October 22 2024 :: Bug-fixes: WRF and GOES. Tag 11.8.2** + +- Force THM to be the WRF-DART temperature variable +- Remove offset on GOES observation converter + **September 27 2024 :: MOM6 mask bug-fix. Tag 11.8.1** - Fix for MOM6 CESM3 workhorse 2/3 degree grid TL319_t232 to diff --git a/conf.py b/conf.py index d78663aefd..902f7875d9 100644 --- a/conf.py +++ b/conf.py @@ -21,7 +21,7 @@ author = 'Data Assimilation Research Section' # The full version, including alpha/beta/rc tags -release = '11.8.1' +release = '11.8.2' root_doc = 'index' # -- General configuration ---------------------------------------------------