ATMS_NPP satellite radiance hofx in MPAS-JEDI missing value

[xyzemc]

Testing the atms_npp radiance data converted by bufr2ioda with combining the atms_npp yaml file into current mpas_jedi yaml file for CONUS_15km case. There are missing values found in the hofx brightness temperature which makes the filter of gross check (o-b) failed. From the plot of hofx, I found the missing value should be located in outside of the CONUS-15km domain. From the plot of atms_npp ioda file, there are missing value (1e11) in brown color.

So, the following things need to be figured out as Emily Liu's suggestion: (1) In the IODA file converted from BUFR, we need to find out why the missing values (1e11) are not treated as missing values in the IODA file.
(2) We need to check why the hofx0 values are missing in the north and south part of your domain. How to add filter to QC out those data

[hongli-wang]

I am having issue in running CRTM with JEDI AOD data assimilation for the online CMAQ model that coupled with regional FV3 model with UFS dynamical core. CRTM reported negative temperature and pressure and then stoped there. I guess the reason is that AOD data is out of model domain. There is a domain check function. But it doesn't work well though I changed the model project parameters to mine. I don't have time to dig into this yet. The example yaml is here if you want to check it out: jedi-bundle/fv3-jedi/test/testinput/3dvar_lam_cmaq.yaml You also can check that source code of the function in UFO.

[xyzemc]

I am having issue in running CRTM with JEDI AOD data assimilation for the online CMAQ model that coupled with regional FV3 model with UFS dynamical core. CRTM reported negative temperature and pressure and then stoped there. I guess the reason is that AOD data is out of model domain. There is a domain check function. But it doesn't work well though I changed the model project parameters to mine. I don't have time to dig into this yet. The example yaml is here if you want to check it out: jedi-bundle/fv3-jedi/test/testinput/3dvar_lam_cmaq.yaml You also can check that source code of the function in UFO.

Thanks for your suggestion. I have tested the LAMDomainCheck with the projection 'circle' which works for my case.

[xyzemc]

The temporary solution for this issue is to add the existing LAMDomainCheck filter in the yaml file. The LAMDomainCheck obsfunction returns a value of 1 if the observation is determined to be located inside the specified domain and a value of 0 if it lies outside. This function includes a subroutine (lam_domaincheck_circle_c) to deal with the MPAS limited area domain in circle. For my ellipse domain case, I temporarily use the short radius of the ellipse as the radius of a circle to make this domain check. yaml file example:

Regional Domain Check

• filter: Bounds Check fileter variables:
• name: brightnessTemperature test variables:
• name: LAMDomainCheck@ObsFunction options: map_projection: circle save: true cenlat: 38.5 cenlon: -97.5

  radius: 1700000

  radius: 1700 #km minvalue: 1.0

This method will reject more data outside of the circle, but inside the ellipse. So this is a temporary solution to make the MPAS-JEDI work for ATMS in this case. Here is an example of the LAMDomainCheck values:

After passed all QC filters, the simulated ATMS brightness temperature (hofx):