-
Notifications
You must be signed in to change notification settings - Fork 7
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
evaluation and fix of surface emissivity adjoint in CRTMv3 #170
Comments
Ming, |
Mark, I have a question on your Table. Mathematically, the FWD-TL-AD consistency testing need to provide two separate and systematic tests: the consistency between the FWD and TL, and the consistency the TL and AD (K-matrix). Your table just shows some kind of the consistency between TL and AD(K-matrix). So the Finite-Difference column is TL values? Not sure how you configured your testing? Can you share your testing codes? Also, there are two conditions in the User's Input case, cloudy scattering vs clear-sky, can you attach also the testing result of the clear-sky? |
@gmao-yzhu, @BenjaminTJohnson , @MingjingTong-NOAA , @emilyhcliu , @gmao-wgu , @quanhualiu, @mingchen36 |
typo error in the PDF: Ratio =Emiss_Finite-Differ / Emiss_TL |
Did you use If yes, which CRTM version I can use for the test? |
Mark, you may use the branch hotfix/cm_surface_EmissAD. After your testing, I may create pull request. |
Ming, |
The TLAD test code tests |
In short, neither pd(Radiance)/pd(emissivity), nor pd(emissivity)/pd(wind_speed), nor pd(Radiance)/pd(wind_speed) although it is so straightforward to get the pd(Radiance)/pd(wind_speed) from this test. K-matrix is nothing more than a transpose of the jacobian. It is essential to know the difference where a variable (e.g., surface emissivity) is a control variable or is a intermediate variable. Otherwise, it should be very difficult to understand the related testing algorithms. |
@gmao-yzhu, @BenjaminTJohnson , @MingjingTong-NOAA , @emilyhcliu , @gmao-wgu , @quanhualiu, @mingchen36
I just noticed that the Common_RTSolution.f90 in this repository had already tried to adopt some of the "fix" codes from the release 2.4.x, where I highlighted the importance to discern the surface emissivity adjoint for use in the 1DVAR retrieval and the DA QC. Someone made a code structure adjustment in this V3 using different order of the IF statement blocks (IF SfcOptics%Compute vs .NOT. SfcOptics%Compute). This should not a problem logically. BUT it lost my fix of the surface emissivity adjoint for the SfcOptics%Compute case. Consequently, this version missed the key point I highlighted in the release 2.4.x.
CRTM_Surface_Emissivity_Jacobian_Final.pdf
I already created one branch hotfix/cm_surface_EmissAD with the updated Common_RTSolution.f90 and the FWD-TL-AD consistency testing programs.
Mark, can you add your testing results for the NOT. SfcOptics%Compute case?
The text was updated successfully, but these errors were encountered: