CRTM Monthly Meeting Protocol

Core Topic of the Meeting: General discussion

Date: 2022-07-28                                  Time: 15:00h EST

Location: Virtual

Invited Speakers: N/A 

Meeting Chair: Benjamin Johnson

Keeper of the Minutes: Patrick Stegmann

Attendees: Benjamin Johnson, Cheng Dang, Patrick Stegmann, Nick Nalli, Cory Martin, Bryan Karpowicz, Yingtao Ma, Shih-wei Wei, Andrew Collard, Guillaume Vernieres, Sarah Lu, Dan Holdaway, Quanhua Liu, Haidao Lin, Ming Chen, Haixia Liu, Yanqiu Zhu



Agenda Item 1:

General Discussion

Discussion:


Ben: Let’s start with complaints? I saw a question from EMC folks, is Emily on?


Andrew: No, She is in training today.


Haixia: Ben, I think the problem is WCOS2 cannot get the data from git-lfs, only from the ftp.


Ben: Ok, I think that’s the only outstanding issue with 2.4.0 that I am aware of. Who wants to start with an overview? Cheng?


Cheng: Yes, in the past month I have been doing a lot of code modifications for the snow surface emissivity. Besides that, I have also been working on a minor fix for reflectivity types. I am also doing some work on the AOD calculation in JEDI. There’s a proposal on work with the NR folks.


Yingtao: Cheng, what update have you done for the snow emissivity?


Cheng: Nick has done some work in the IR. With the update you have more snow grain sizes. I also added TL and AD for the new development. Previously they were zero.


Yingtao: Mark found some issues with the emissivity. Does your table also have these issues?


Cheng: That was for FASTEM tables for water.


Quanhua: For the ocean surface emissivity, there is a BRDF effect. For clearsky we only calculate one direction downward, and one direction upward. So, there is an assumption that we have an effective reflected radiation direction. That can make the reflectivity larger than one. For MW sensors you have larger radiation at angle compared to nadir. So, the effective radiation will become larger to compensate.

For ocean MW emissivity, there are two components.


Yingtao: So, for all other surface types you just assume it’s Lambertian?


Cheng: Yes and no. If there are aerosols in the sky, you have number of streams and at the surface you also integrate over the streams. If there is no cloud, you just assume it’s specular.


Mark: Cheng, one question for the emissivity. Are you computing emissivity and reflectivity separately?


Cheng: CRTM is not computing emissivity. Reflectivity is just one minus emissivity. In the future, a BRDF will be more important.


Ben: I just created an invite for a biweekly meeting for CRTM v3.0 where we can discuss who is working on what.


Mark: I would like to task about the status of v3.0. Did Ming Cheng integrate the CSEM?


Ben: Not on the JCSDA repository. But I think Ming is really waiting for us to pull the trigger on that development.


Ming: I think after Ben is merging your branch into the master it will be straightforward to test CSEM features. It shouldn’t be a big issue to integrate CSEM after v3.0 is available.


Mark: Ming, would you be willing to send the link for your Github branch to the group? Then people can test it.


Ming: I don’t know.


Mark: That branch you are working on… so right now it is not in the JCSDA repository?


Ming: It is kind of a JCSDA repository.


Mark: It’s not clear to me. The question is easy, it is already there, or not? Seems complicated.


Ben: I agree with Mark, it’s time to bring it on speed.


Ming: Anytime, we can migrate the branch.


Ben: Ok, go ahead. I think within a week we will be working on it.


Ming: [unintelligible]


Ben: Ok, do what you need to do.


Ben: EMC, any questions or comments?


Andrew: Not really. We understand the inconsistency of the coefficient files between the emc- and the new releases. With netCDF at least we don’t have to track little- and big endian.


Ben: It’s also about versioning. That should be easier with netCDF.


Andrew: But, what we have been using in operations, are we using the correct ones?


Ben: Which coefficients were those?


Andrew: AMSU-A TauCoeffs.


Ben: It’s not clear what the in-kind and contributor situation will look like for AOP2022 and we will just continue to work the same way we are working right now. Guillaume, what are you working on right now?


Guillaume: I am not working on coupled DA. I am working on Anna and Yannick to unify the model communication.


Ben: I think ocean is going to be easier to do land. As soon as ocean is available that will provide a path for Andy to do land coupling.


Ben: Yingtao, would you like to talk about the coefficients you just generated?


Yingtao: I just created MTG coefficients and uploaded it to the repository.


Ben: And the SRF you used?


Yingtao: I don’t remember.


Mark: When you generate the transmittance coefficients you first generate the SRF file?


Yingtao: No, different organizations have different formats. Do we need to provide the SRFs in the future?


Ben: The repository is private.


Ming: [unintelligible]


Quanhua: I just wanted to talk about the AI development with TensorFlow. It’s good for the training, but if we apply the model on a profile by profile basis, it’s dramatically slower, by a factor of 1000. We compared the benchmark test with 200000 profiles. If you just call the code just once, it’s very fast. But if you have a loop for each profile, then it’s much slower than the common CRTM model. All DA systems call the CRTM profile by profile. That’s a big challenge. We just developed a forward code using Fortran. But for the Fortran code you don’t have the Jacobian calculation, so we need to code that again. It’s a big problem for TensorFlow. They always assume big input data sizes.


Ben: It kinda makes sense. For retrieval users, the forward model is fine. But for DA, we eventually want a AI Jacobian.


Yingtao: Mark, you said you use a Fortran code. Can you create the Jacobian from that code?


Mark: I already did. But even if we use the fast Fortran code, the CPU ratio is about 2 times slower for the Jacobian. But for the AI model, that ratio is proportional to the number of profiles.


Yanqui: I have a question for Ben. I heard that the UFO is supporting 2.4.0 in the future. We have been using 2.3.0. Will you continue to support 2.3.0 in the future?


Ben: Yes, we will have different UFO versions to support both. Both versions are different and operational people will want to compare that.


Yanqiu: I missed the first part, but are there any issues with the AMSU-A file? Please keep us updated.


Ben: I don’t think so, but we will keep you updated.


Ming: [unintelligible]




Result:


-        

Tasks:


-        

Responsible People:


-        

Deadline:

N/A



Meeting End: 16:05h EST








  • No labels