CRTM Technical Meeting Protocol

Core Topic of the Meeting: General Discussion & Catch-up

Date:  2020-08-10                               Time: 15:02h

Location: Virtual (Google Hangouts)

Invited Speakers: N/A

Meeting Chair: Benjamin Johnson (JCSDA)

Keeper of the Minutes: Patrick Stegmann (JCSDA)

Attendees: Benjamin Johnson, Patrick Stegmann, Cheng Dang, Bryan Karpowicz, Yingtao Ma, Daniel Abdi, Ming Chen, Hongli Wang, Edward Hyer, Nick Nalli, Ming Chen

 

Introduction by Ben:

No specific agenda. Anouncements:

-       Possibility to move ahead with CRTM 2.4; Ben has written a whitepaper. The new features will be:

-       Most of the work has already been done. The release date in October will coincide with the JEDI release.

-       The content of CRTM 2.4 will also carry over to REL-3.0

 

Agenda Item 1:

General Updates

Discussion:

Cheng, do you want to give an update on the NetCDF work?

 

Cheng: Sure, for aerosols you can use the same aerosols that are available in CRTM 2.3. The difference is that you can now specify if you want a NetCDF version. Within this month I will modify the code so that you can run different aerosol types. Yingtao also sent me the CMAQ aerosol table and the goal is also to include that once I finish GOCART/GEOS-5.

 

Ben: Any questions?

 

Mark Liu: You still using the binary file?

 

Cheng: Yes, the utility to read the NetCDF table is already in the CRTM.

 

Yingtao: You’re lookup table is GOCART only, right?

 

Cheng: Yes, there is a subtle difference. I compared CRTM vs. GOCART aerosol properties and there is a subtle difference on how the treat aerosol definitions. Since we already have GOCART GEOS-5 I try to include that in the CRTM, so we will have two GOCART aerosols.

 

Yingtao: So, there will be no code changes?

 

Cheng: No, I will have to make some small changes, how you select aerosol species.

 

Yingtao: In my code, the aerosol types are specified in the LUT alone. We could combine our two changes.

 

Cheng: We could make some changes to the aerosol type definition so we can include different aerosol type definitions.

 

Mark Liu: Yingtao, your work is already done? Do you need information from file?

 

Yingtao: I have finished modification from code. No need for user to change the CRTM. I compared original and new code with CMAQ table and they are the same. The GOCART table and the current CRTM is the same for the Forward part. I may need to talk with you Mark offline about TL and AD part because I know there are some variables in the AD part that are not initialized but if that’s fine everything is done.

 

Mark Liu: Do you both share the code so we can work as a team?

 

Yingtao: We will. I will share the code with Cheng.

 

Ben: We had a coefficient coordination meeting last week and I am quite happy.

Any more updates?

 

Mark Liu: I will continue on version 3.0 because there are some issues with the computational efficiency. Do we plan to have more capabilities for CRTM 3.0? One is to have NetCDF I/O and the other is to have a flexible aerosol definition? This should be relatively simple because only the I/O parts need to be modified. We shouldn’t remove the utility to read binary files.

 

Ben: I agree completely. We won’t remove the binary file capability. What might be different is that for new experimental builds we will only use NetCDF, e.g. for backscattering efficiency. With NetCDF we have a lot more flexibility. We want to get to a point where nobody uses binary anymore.

 

Mark Liu: Some people might not be able to use NetCDF.

 

Ben: Yes, we need backward compatibility for old operational machines, so both NetCDF and OpenMP will be optional.

 

Yingtao: Or we could add a warning to our release and supply a converter to the user.

 

Ben: Yes.

 

Yingtao: And Mark, when I do the aerosol verification, when I do the SPC coefficients I noticed a central frequency difference.

 

Yingtao: SPC coefficients release 7 and 8 for GOES-R the center frequency is different.

 

Mark Liu: At that time when we developed that the sensor was just a placeholder. No we have the actual sensor.

 

Ben: That’s a common problem and one of the reasons why we want to switch to NetCDF that makes it clear where the coefficients came from.

 

Yingtao: Mark, what’s the difference between release and version number?

 

Mark Liu: That was designed by Paul van Delst and I am also confused by that.

 

Ben: Often there would be multiple internal versions to be tested before a final release.

 

Mark Liu: Ben’s explanation is probably what actually happened.

 

Yingtao: I don’t know. In the code there is a comment that the release number is related to the coefficients and there are some inconsistencies.

 

Mark Liu: For the CRTM code that reads the transmittance coefficients, does it check the release number?

 

Yingtao: I don’t know. In the CRTM is a check if the LUT release number is the right one it can handle. If that’s not the case the code will stop.

 

Mark Liu: So, release number is only changed if the interface is changed?

 

Yingtao: Yes.

 

Ben: This is something we will revisit to keep track of different NetCDF coefficient versions. This will also be for reporting and publication purposes. We will have a strong requirement to cite the coefficient version in publications to avoid the problem of RTTOV that people will create their own releases. If you do publish using the CRTM you will have to provide meta data.

 

Yingtao: All our coefficients use binary form. Are there any plans to replace that?

 

Mark Liu: All the coefficients start of as NetCDF and then are converted to binary.

 

Yingtao: Yeah, this also relates to my aerosol work since I can only differentiate between GOCART and CMAQ coefficients by looking at the version number.

 

Haixia: Yingtao, when you mention the release 7 and 8 ABI coefficients and the difference between the center differences what are you talking about exactly?

 

Yingtao: You don’t have to worry about that since this wasn’t released in your version.

 

Haixia: Ben, have you made a decision on how to deal with the cloud fraction?

 

Ben: I had a discussion with Allan Gear. They also agree that a cutoff of .05 cloud fraction is bad. My solution is to go down to zero. The decision is that if cloud fraction goes down to zero, the radiance should approach the clearsky value. We can discuss if there should be an additional warning. That seems the logical approach.

 

Haixia: That requires GSI to be changed. In any case the pixel is considered overcast.

 

Mark Liu: I think it’s better to not affect the user. If you do not set up the optional cloud fraction input then it will be clearsky.

 

Haixia: In the CRTM 2.3 if we do not provide a cloud fraction and there is a cloud CRTM will consider it overcast.

 

Mark Liu: Yes, the number of clouds determines if the profile is overcast. Cloud fraction is additional.

 

Haixia: I tried running GSI once with initializing cloud fraction to zero. I do not know how to control the cloud fraction behavior.

 

Mark Liu: If you have a cloud and a cloud fraction of zero this doesn’t make sense. You just don’t need to input anything about cloud fraction.

 

Ben: Haixia, feel free to set up a separate meeting where we can go through the GSI code to double-check.

 

Yingtao: What part of CRTM distinguishes between cloud fraction is zero and no input?

 

Ben: The default value is one.

 

Mark Liu: The default value is not set anywhere. Cloud fraction is optional.

 

Yingtao: If you don’t use optional than is one.

Mark Liu: No. If you don’t use the optional input then this cloud fraction is never used in the CRTM.

 

Yingtao: How do you combine clear and cloudy?

Mark Liu: If you don’t set up cloud fraction then you either do cloudy or clear.

 

Haixia: Ben, you have to make a decision on how to move forward. Do you have an estimate how long this will take and what’s the impact in GSI?

 

Ben:  We can look at it during the meeting. It’s a very simple change.

 

Mark Liu: There are some places you need to change. The cloud water is scaled.

 

Ben: Yes, Jim has already checked that and and the water content can become very large.

 

Yingtao: Why do you want to change the water content? I thought this was independent.

 

Mark Liu: No, the NWP people scale the water content for the whole layer.

 

Yingtao: I understand what you are saying. But most of the current NWP don’t have a concept of cloud fraction.

 

Mark Liu: Then the assumption from the NWP model would be confused. The cloud water content is for the whole grid.

 

Yingtao: The cloud water content should only be for the partial cloud.

 

Mark Liu: No.

 

Yingtao: But if the CRTM user is not from the NWP community they will not understand that.

 

Mark Liu: Yes, then they will need to read the manual.

 

Haixia: Can this be made optional?

 

Ben: I agree with Yingtao. The way we do cloudy radiance computation is weird. You will need to corresponding paper to understand it. They had to come up with a scheme, Paul and the RTTOV team. There are better ways to do it, but I agree with Haixia’s comment. The treatment should be more intuitive.

 

Mark Liu: In the future the NWP community might change in the future, as cloud fraction and cloud water content might become prognostic.

 

Yingtao: So currently at least let the user know this.

Mark Liu: That’s why I suggested to Ben to have the JCSDA have a dedicated website.

 

Ben: Yes, but we don’t have a lot of web development people. Anything else?

 

Patrick: The documentation for the transmittance coefficient generation process is finished.

 

Ben: Where can we find it?

 

Patrick: In the CRTM_coef/doc/UserGuide repository. It’s a Latex document, so you will need to compile it first.

 

Ben: Maybe we can add a pdf for people to look at.

 

Haixia: Have you tested the accuracy yet?

 

Patrick: Yes, for the layer-to-space transmittance the difference to the old values is about 0.2% and for the Jacobians it is similar.

 

Mark Liu: There may be a number of reasons for the differences. Different versions of LBLRTM and the ECMWF83 and UMBC48 profiles.

 

Yingtao: Mark do you know the combination of molecules? Do you know what they used before?

 

Mark: Actually, there are two versions for the transmittance training. The first one is to divide and then have a training for the difference.

Second method is to compute water vapor first, then divide it by water vapor and so on for the second gas.

Right now we are only dealing with 6 gases. If we use more gases in the future we will have a problem.

 

Ben: Yes, I think Yong Chen had a number of publications on that. Any further updates?

 

Daniel: I looked at the OpenMP branch of the CRTM. There are about 5 OpenMP directives. Is that what I should look at?

 

Ben: Look at what has been already done before. Investigate if there are any additional places where the CRTM would benefit from OpenMP. Just have a look and see if what is already there makes sense to you.

 

Results:

  • CRTM REL-2.4 will be released in October 2020 together with JEDI.
  • CRTM NetCDF I/O is now available for aerosols.
  • Transmittance Coefficient Generation documentation is available on the CRTM_coef repository.

Tasks:

  • Finish work on NetCDF I/O.
  • Cheng: Modify CRTM code to allow for different aerosol types.
  • Patrick: Provide pdf version of coefficient generation documentation.
  • Ben: Modify cloud fraction code to behave correctly when cloud fraction goes to zero.
  • Ben & Haixia: Check GSI impact of CRTM cloud fraction.
  • Daniel: Look at OpenMP CRTM modifications.

Responsible People:

Cheng, Yingtao, Ben, Haixia, Patrick, Daniel

Deadline:

October 2020

 

 

16:01h Final end of meeting.