CRTM Monthly Meeting Protocol
Core Topic of the Meeting: Monthly meeting
Date: 2021-07-29 Time: 15:00 EST
Location: Google hangout
Invited Speakers: None
Meeting Chair: Patrick Stegmann (JCSDA)
Keeper of the Minutes: Cheng Dang (JCSDA)
Attendees: Patrick Stegmann, Cheng Dang, Hongli Wang, Igor Polonsky, Issac Moradi, Jim Jung, Kevin Garrett, Ming Chen, Mingjing Tong, Nick Nalli, Punyam Satya, Quanhua Liu, Scott Sieron, Shih-wei Wei, Yanqiu, Yingtao Ma, Zhenglong Li.
Agenda Item 1: | CRTM Monthly Meeting Agenda |
Discussion: |
Talk: Patrick Stegmann
Update on CRTM 2.4.1 - Internal release - New transmittance coefficients - NC IO for TauCoeff and SpcCoeff - New Aerosol Schemes Upcoming JCSDA meetings - AMS 2022 - CRTM Tech meeting (Virtual, Oct) - Coefficient Generation Roundtable Meeting
Scattering data structure refactoring - Recurring issues - Remove duplicates - Enforcing physical representations Coefficient
Questions: Issac: how about using the YAML file to help remove the duplicates? Mark: It's a very good suggestion to make the code readable. We made the code this way to reduce the internal memory, but if someone can make the code clean, that would be great. Patrick: yes, efficiency is also something we should consider. Mark: is someone working on this? Patrick: this might be a AOP task, but off the top of my head, I don't have Yingtao: I remember Ben was working on some autoconfiguration tools. In the future, will you only support cmake or autoconfig? Patrick: I cannot speak for management decisions, but the current plan might be cmake and ecbuild to match the JEDI system. Shared links: https://github.com/ecmwf/ecbuild https://github.com/JCSDA-internal/crtm/blob/develop/CMakeLists.txt Ming: For the development of data structure, are you going to change the data structure in vectorized algorithms provided by Mark? Patrick: when we make changes to the data structure, we also will coordinate with Mark. Ming: yes, we need to design some consistent data structure for efficiency. Mark: this is probably more of a long-term change for version 3.0
Mark: what's the status of CRTM 2.4.1? Have you finished the testing? Patrick: we still have several PR to be closed, and Ben is working on a release now. Yingtao: In your slides, you mentioned you are using the measured SRF instead of the boxcar, have you done any tests on which one is better? Patrick: Yes, I did some tests, and the results are pretty similar. It's hard to tell which one is better. Kevin: What Paul did is for ATMS. Mark: Yingtao, in principle, it is better to use measured SRF, and what Paul did was a one-time experiment.
Mark: do you need to modify the sensor data parameter for a new sensor? In the past, when you have SRF data, you still need to modify the sensor data parameter, is this the case? The risk is the central frequency peaks are hardcoded and need to be revisited for new sensors. Patrick: we did not modify the SRF hard-coded section, and there is more work to be done. Issac: this also depends on how you calculate the central frequencies. Mark: yes, someone just uses average or mean, but there are many approaches to compute average, which can be different from the sensor to sensor. In the long term, we just need to make sure CRTM provides consistent data. Yingtao: you mean, for the transmittance generation package, we need to change the central frequencies manually? Mark: The reason I mentioned this is because of the discussion we had in MW sensor workshop yesterday. I noticed changes in acquired values after modifying this parameter. In the future, we might want to spend some time thinking about how to make this process easier. Patrick: this might be a good first application for YAML files. |
Tasks: | |
Responsible People: | |
Deadline: |
Agenda Item 2: | Updates by Issac Moradi |
Discussion: | Cloud scattering tables - MW: changes to the cloud coefficients and densities - The table will include different habits. Yingtao: what are the differences between your table and the CRTM table? Issac: the number of densities is 3 for MW and 4 for IR, but in this case, it's tricky to implement the table for different habits, so I modified the LUTs to have other habits. The habits for IR and MW should also be independent. Ming: are you using the JCSDA package? Is this for operational or research only? Issac: eventually, I'll merge everything into the JCSDA development branch. Mark: in the future, it's better to have a CRTM interface to let the users provide optical properties. Issac: Yes, you can have such an interface, but this might be too complex for users. What I am working on is the cloud tables adopted by RTTOV, which is 3-5 years ahead of us, so there is no reason to stick to the current CRTM cloud coefficient table. Ming: CRTM should be more operationally focused. Issac: The modifications I made will not alter the efficiency and performance of CRTM. Mark/Yongtao: for significant changes to the code, we need to have internal scientific justifications and review on the codes through PR. Issac: yes, the operational is one thing and the scientific-justified developments are also important for the future applications. Mark: I agree. That requires careful planning and balancing as well, especially based on our previous experiences. |
Result: | |
Tasks: | |
Responsible People: | |
Deadline: |
Agenda Item 3: | Open discussions |
Discussion: |
|
Result: | 3D RT/ Monte Carlo Mark, Yingtao, Jgor discussed about the possibility on RT with curvatures and Monte Carlo algorithms. Igor will try to find an existing 3D Monte Carlo code for limb geometry and share it with the CRTM group. Igor may also give a review on Monte Carlo methods in CRTM technical meetings. CRTM Drive: Punyam Satya - NOAA Affiliate 2:03 PM This is Satya from OSPO/NESIDS. We use CRTM in our SST retrieval codes. I have always felt the need for a driver. After Igor Polonsky verbalised the need for a driver. I feel compelled to second his suggestion. I can run the driver and get specific info from CRTM. That is a great idea. Patrick Stegmann 2:03 PM Thank you Satya. Yingtao Ma - NOAA Affiliate 2:04 PM Punyam is basically want a standalone version of CRTM, right? Punyam Satya - NOAA Affiliate 2:05 PM Yes. That way, I do not have to build my whole code to test/validate/extract from CRTM. Yingtao Ma - NOAA Affiliate 2:06 PM Does SimObs work for Punyam's requirement? Patrick Stegmann 2:06 PM @Yingtao SimObs should do that, but it's still in the early stages. pyCRTM might be a solution. Punyam Satya - NOAA Affiliate M 2:08 PM Mone Carlo discussion was very interesting. Thank you. |
Tasks: | |
Responsible People: | |
Deadline: |
16:10 EST End of meeting.