commit changes for AMSU-A and ATMS switch from Ta to Tb

[gmao-yzhu]

GEOS has been assimilating antenna temperature from AMSU-A and ATMS (except NOAA-15 and 16, where an old version of brightness temperature data are used), radiance bias correction has been used to try to fill the role of antenna correction. As all other organizations especially NCEP move forward to use brightness temperature, it is time for us to make the move too. Related code changes are brought into GEOS in this pull request.

[github-actions[bot]]

Label error. Requires at least 1 of: 0 diff, 0 diff trivial, Non 0-diff, 0 diff structural, 0-diff trivial, Not 0-diff, 0-diff, automatic, 0-diff uncoupled. Found:

[gmao-msienkie]

If we were to want to use this code (with ta2tb set to .true.) with the reprocessed AMSUA data for a historical run I think we would want to change the code where the ta2tb is not done for N15 and N16 since I believe that the reprocessed AMSUA N15 and N16 had antenna temperatures written rather than brightness temperatures.

[gmao-yzhu]

Thanks Meta. I’d like to get a clarification – do we use the reprocessed AMSUA N15 data for reanalysis only, or we use them for all historic runs? If they are used for all historic runs, is there a way to tell in GSI code if a run is a historic run or not?

It could also be more complicated, when AMSU-A NOAA15 and 16 were reprocessed, do you know what version of antenna correction coefficients were used?

Thanks, Yanqiu

From: Meta Sienkiewicz @.> Reply-To: GEOS-ESM/GEOSana_GridComp @.> Date: Friday, June 9, 2023 at 3:29 PM To: GEOS-ESM/GEOSana_GridComp @.> Cc: "Zhu, Yanqiu (GSFC-6101)" @.>, Assign @.***> Subject: [EXTERNAL] [BULK] Re: [GEOS-ESM/GEOSana_GridComp] commit changes for AMSU-A and ATMS switch from Ta to Tb (PR #127)

CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC.

If we were to want to use this code (with ta2tb set to .true.) with the reprocessed AMSUA data for a historical run I think we would want to change the code where the ta2tb is not done for N15 and N16 since I believe that the reprocessed AMSUA N15 and N16 had antenna temperatures written rather than brightness temperatures.

— Reply to this email directly, view it on GitHubhttps://github.com/GEOS-ESM/GEOSana_GridComp/pull/127#issuecomment-1585194309, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARUMEBXRNCBXSWBCQXV2JUTXKOPV7ANCNFSM6AAAAAAXEIZAPU. You are receiving this because you were assigned.Message ID: @.***>

[rtodling]

Yanqiu, I can give you partial answer to your question above: there is no way to tell whether GSI is running a present or historical run - we don't ever want to make that distinction: in my view this is nearly an impossible decision to make: what's new today is old tomorrow.

In my view it is unfortunate that a change like this is not controlled w/ a KT-like number - in GEOS, KT is the variable name, just like KT=44 is TV, KT=4 is U-wind, etc, but GSI does not have this concept.

It might be worth thinking a little more about how to implement this in a way that the experiment doesn't have to know cat's being handled ...

[rtodling]

Another question is this: does setting ta2tb to false gives identical results to before any changes were introduced?

[gmao-yzhu]

Ricardo, setting ta2tb to false should give identical results because the changes were introduced within the ta2tb option "if" statement. But I have to admit that I didn't do a test. I can run a test.

Another thing I want to let you know -- this week Meta checked processing code for MHS, and she found the note in the code saying that Tb is stored for MHS. In read_bufrtovs.f90, amsub and mhs are included in the changes of (llll==1) section. I contacted Andrew, he is still trying to work out what the process is for MHS. It seems to be very different compared to AMSU-A. But he thinks Meta is correct. For MHS we are assimilating 3 water vapor channels (bias corrected).

I'm sorry, I will need to submit the following change to the PR once I get confirmation from Andrew: Replace if (llll == 1) then call ufbrep(lnbufr,data1b8,1,nchanl,iret,'TMBR') if ( (amsua .or. amsub .or. mhs) .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then

By if (llll == 1) then call ufbrep(lnbufr,data1b8,1,nchanl,iret,'TMBR') if (amsua .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then

[rtodling]

Ricardo, setting ta2tb to false should give identical results because the changes were introduced within the ta2tb option "if" statement. But I have to admit that I didn't do a test. I can run a test.

Another thing I want to let you know -- this week Meta checked processing code for MHS, and she found the note in the code saying that Tb is stored for MHS. In read_bufrtovs.f90, amsub and mhs are included in the changes of (llll==1) section. I contacted Andrew, he is still trying to work out what the process is for MHS. It seems to be very different compared to AMSU-A. But he thinks Meta is correct. For MHS we are assimilating 3 water vapor channels (bias corrected).

I'm sorry, I will need to submit the following change to the PR once I get confirmation from Andrew: Replace if (llll == 1) then call ufbrep(lnbufr,data1b8,1,nchanl,iret,'TMBR') if ( (amsua .or. amsub .or. mhs) .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then

By if (llll == 1) then call ufbrep(lnbufr,data1b8,1,nchanl,iret,'TMBR') if (amsua .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then

@gmao-yzhu did you ever get confirmation for the above from Andrew? Where the changes needed for this to be a complete this work added to this branch?

[gmao-yzhu]

Ricardo, setting ta2tb to false should give identical results because the changes were introduced within the ta2tb option "if" statement. But I have to admit that I didn't do a test. I can run a test. Another thing I want to let you know -- this week Meta checked processing code for MHS, and she found the note in the code saying that Tb is stored for MHS. In read_bufrtovs.f90, amsub and mhs are included in the changes of (llll==1) section. I contacted Andrew, he is still trying to work out what the process is for MHS. It seems to be very different compared to AMSU-A. But he thinks Meta is correct. For MHS we are assimilating 3 water vapor channels (bias corrected). I'm sorry, I will need to submit the following change to the PR once I get confirmation from Andrew: Replace if (llll == 1) then call ufbrep(lnbufr,data1b8,1,nchanl,iret,'TMBR') if ( (amsua .or. amsub .or. mhs) .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then By if (llll == 1) then call ufbrep(lnbufr,data1b8,1,nchanl,iret,'TMBR') if (amsua .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then

@gmao-yzhu did you ever get confirmation for the above from Andrew? Where the changes needed for this to be a complete this work added to this branch?

Yes, the changes are needed and already included in R21C version I believe.

[rtodling]

Ricardo, setting ta2tb to false should give identical results because the changes were introduced within the ta2tb option "if" statement. But I have to admit that I didn't do a test. I can run a test. Another thing I want to let you know -- this week Meta checked processing code for MHS, and she found the note in the code saying that Tb is stored for MHS. In read_bufrtovs.f90, amsub and mhs are included in the changes of (llll==1) section. I contacted Andrew, he is still trying to work out what the process is for MHS. It seems to be very different compared to AMSU-A. But he thinks Meta is correct. For MHS we are assimilating 3 water vapor channels (bias corrected). I'm sorry, I will need to submit the following change to the PR once I get confirmation from Andrew: Replace if (llll == 1) then call ufbrep(lnbufr,data1b8,1,nchanl,iret,'TMBR') if ( (amsua .or. amsub .or. mhs) .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then By if (llll == 1) then call ufbrep(lnbufr,data1b8,1,nchanl,iret,'TMBR') if (amsua .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then

@gmao-yzhu did you ever get confirmation for the above from Andrew? Where the changes needed for this to be a complete this work added to this branch?

Yes, the changes are needed and already included in R21C version I believe.

@gmao-yzhu the important thing to me is: are the changes above (that you say were included in R21C) also in the branch associated w/ this PR?

[gmao-yzhu]

I just checked, in this PR, that line

[gmao-yzhu]

I just checked this PR, that line "if ( (amsua .or. amsub .or. mhs) .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then" has not been changed to "if (amsua .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then"

I could add this change tomorrow. I am attending a workshop now.

[rtodling]

I just checked this PR, that line "if ( (amsua .or. amsub .or. mhs) .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then" has not been changed to "if (amsua .and. & .not.(jsatid == 'n15' .or. jsatid == 'n16') )then"

I could add this change tomorrow. I am attending a workshop now.

@gmao-yzhu I just pushed this change to the branch. Now, I wonder if a line similar to this should also be edit right after the else of llll==1

if ( amsua .or. amsub .or. mhs .AND. spc_coeff_versions /= 1 .AND. sacv /= 1)then

line 761 in the code.

[rtodling]

Unfortunately, the changes in this PR are not zero diff when ta2tb = .false. - as the default sets it to be. I can see a few reasons for it - read_bufrtovs seems to mix two issues. handling of the Spc-files and ta2tb - not clear these are related; but at a minimum some of the changes there must be protected for ta2tb ...

when I add the following protection in line 685:

if (llll > 1) then ...

changed to

if (ta2b .and. llll > 1 ) then

it seems still not able to get zero diff ... I am looking at the M21C code and I see other differences there ... I suppose those need to be placed here to get zero diff ---

[rtodling]

Just sync read_bufrtovs with version in M21C tag ... still testing to see if this will give zero diff when ta2tb is false.

[rtodling]

I might have approved this to quickly ... there is an issue when triggering the Ta to Tb conversion ...

@gmao-yzhu @elakkraoui @gmao-msienkie any clue what this is?

[gmao-yzhu]

Need to check this AC file in CRTM connected in analyzer. I will take tomorrow morning off from the workshop and check this.

From: rtodling @.> Date: Wednesday, September 25, 2024 at 4:59 PM To: GEOS-ESM/GEOSana_GridComp @.> Cc: Zhu, Yanqiu (GSFC-6101) @.>, Mention @.> Subject: [EXTERNAL] [BULK] Re: [GEOS-ESM/GEOSana_GridComp] commit changes for AMSU-A and ATMS switch from Ta to Tb (PR #127) CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC.

I might have approved this to quickly ... there is an issue when triggering the Ta to Tb conversion ...

@gmao-yzhuhttps://github.com/gmao-yzhu @elakkraouihttps://github.com/elakkraoui any clue what this is? ta2tb_error.png (view on web)https://github.com/user-attachments/assets/e26c08f4-50f2-4f99-bde5-bcba95015ccf

— Reply to this email directly, view it on GitHubhttps://github.com/GEOS-ESM/GEOSana_GridComp/pull/127#issuecomment-2375186527, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARUMEBR5KYY5M4SA3LWPYPLZYMP4NAVCNFSM6AAAAABOYFPGC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZVGE4DMNJSG4. You are receiving this because you were mentioned.Message ID: @.***>

[rtodling]

@gmao-yzhu Oh my ... I am finding out that the antenna correction routine here is a copy of a CRTM routine! I am going to take the code as is ... and implement this in a way where this routine comes from CRTM and not be placed in GSI ...

please let me work on this first in another PR.

[gmao-msienkie]

@gmao-yzhu I just pushed this change to the branch. Now, I wonder if a line similar to this should also be edit right after the else of llll==1

if ( amsua .or. amsub .or. mhs .AND. spc_coeff_versions /= 1 .AND. sacv /= 1)then

line 761 in the code.

I had suggested the removal of MHS and AMSU-B from the earlier section because NOAA processing for them is different from the AMSU-A processing and the MHS/AMSU-B code explicitly said that only brightness temperatures were being produced. So they presumably do not need to have an antenna correction (whatever it might be) applied again.

The radiances from the 'else' section are from another source (EARS I think) and I don't know what the processing is for that data type. NCEP has been using this data for quite some time and I guess we can just leave it to be handled the way that they do it because we do not have data from this source and thus we do not use it. So better to leave it alone, I think.

[gmao-yzhu]

Meta, you are right we can leave EARS and DB part as is. We don’t use these data.

Yanqiu From: Meta Sienkiewicz @.> Date: Thursday, September 26, 2024 at 9:59 AM To: GEOS-ESM/GEOSana_GridComp @.> Cc: Zhu, Yanqiu (GSFC-6101) @.>, Mention @.> Subject: [EXTERNAL] [BULK] Re: [GEOS-ESM/GEOSana_GridComp] commit changes for AMSU-A and ATMS switch from Ta to Tb (PR #127) CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC.

@gmao-yzhuhttps://github.com/gmao-yzhu I just pushed this change to the branch. Now, I wonder if a line similar to this should also be edit right after the else of llll==1

if ( amsua .or. amsub .or. mhs .AND. spc_coeff_versions /= 1 .AND. sacv /= 1)then

line 761 in the code.

I had suggested the removal of MHS and AMSU-B from the earlier section because NOAA processing for them is different from the AMSU-A processing and the MHS/AMSU-B code explicitly said that only brightness temperatures were being produced. So they presumably do not need to have an antenna correction (whatever it might be) applied again.

The radiances from the 'else' section are from another source (EARS I think) and I don't know what the processing is for that data type. NCEP has been using this data for quite some time and I guess we can just leave it to be handled the way that they do it because we do not have data from this source and thus we do not use it. So better to leave it alone, I think.

— Reply to this email directly, view it on GitHubhttps://github.com/GEOS-ESM/GEOSana_GridComp/pull/127#issuecomment-2377060288, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARUMEBU3JCWPOYMWVWHF5Z3ZYQHNDAVCNFSM6AAAAABOYFPGC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXGA3DAMRYHA. You are receiving this because you were mentioned.Message ID: @.***>

[gmao-msienkie]

I was chatting with Yanqiu and we remembered that Amal had trouble running her code because there was a problem with a coefficient file. I guess her problem was with the file being bigendian and not littlendian so it may not have anything to do with your problem reading the AC coeffs from the CRTM coefficient file. However I believe M21C is successfully running with the following setting in the 'analyzer' Assignfn( "$fvInput/$myetc/r21c_ncep20221018/Little_Endian","CRTM_Coeffs"); I'm mentioning this in case it would help (and if you have not already resolved your earlier problem)

The README file in the referenced directory mentions that Amal replaced the 'amsua_metop-c_v2.SpcCoeff.bin' file.