CRTM Technical Meeting Protocol

Core Topic of the Meeting: Technical Discussion

Date:  2020-12-14                                 Time: 15:05 h

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, Yingtao Ma, Ming Chen, Nick Nalli, Hongli Wang, Daniel Abdi, Liu Quanhua

 

Agenda Item 1:

Introduction

Discussion:

 

Introduction by Benjamin Johnson:


Ben: I wanted to talk shortly about the new cloud coefficient files.

 

Yingtao: I have a question, are those new coefficients included in the 2.4 Release?

 

Ben: Yes, we have multiple coefficients, including the Texas A&M coefficients from 2014 and a version with expanded effective radius. The expanded properties right now only use Mie theory. The work that still needs to be done is to achieve the correct normalization of the phase function.

There is also one that has expanded frequencies up to 600 GHz. But those don’t have the non-spherical scattering properties. The idea is to cover the ice cloud imager range.

 

Yingtao: Was the scattering properties something that Ping Yang has provided?

 

Ben: Yes, that was also something that Patrick has provided.

 

Mark: So, Ping Yang’s work is funded by Joint Center?

 

Ben: That is a Kevin question, I have not detailed information on that. I think he has provided OAR funding.

 

Mark: So, the Joint Center is not working on a joint proposal?

 

Ben: No, not for external contributions. It’s hard to get universities involved without funding.

 

Mark: Yes, for instance Tom Greenwald.

 

Ben: Yes, he’s still working on radiative transfer, but not funded by the Joint Center. I agree, I have a problem with that. We have to find a way to find external contributors.

 

Result:

 

Tasks:

-        

Responsible People:

 

Deadline:

 

 

 

Agenda Item 2:

Surface Emissivity Discussion

Discussion:

 

Mark: I just wanted to share some information with you. Jim Hawk and I had an email communication. For the parallel RTTOV the parallel parts are only used for postprocessing. But for the DA part they still use the single process.

 

Ben: I don’t know if they told you but there is a plan for me to go to UK MetOffice to help them get their parallel work going in July. I don’t know if it’s going to happen or not.

 

Mark: In 2010 I was invited as well and they paid the lodging cost. They invited me for one month to work on the FASTEM model. But I only staid two weeks because of the Soumi NPP launch.

 

Mark: They have a lot of programs to invite people from other countries. The JCSDA has also programs.

Ben: I try to encourage that, but so far, it’s been only French students. I tried to get a visitor from Goddard, but that didn’t work out.

 

Mark: For the profile loop adding parallelization that is very fast, but at the channel level that takes longer. I have the code at the channel level, it works fine. But for the channel loop there is some overhead because you need to define some private variables. The overhead is about 5%.

 

Ben: I think we are kind of ahead of the curve already.

 

Mark: Yeah, that’s different from ATS. At that time John Derber asked to have a parallel part. The operational system at the time had threads. If you use a serial implementation you waste a few threads. Today I talked to IT people and in today’s machines each thread is treated as an individual CPU. But still, going parallel has some advantages, such as saving some memory.

 

Ben: Nick, did you want to give an overview of your ISSI talk?

 

Nick: I joined a little late, did you talk about the ISSI already?

 

Ben: Yes, it’s a team under the lead of Steve English to create a reference ocean emissivity model with most of the expertise in MW. We had some guests already to work from L-band upwards. We realized we had a gap in the IR and so I suggested to invite Nick.

 


Nick: Right, Steve English is the team leader/coordinator and they’re focused on MW for the ocean emissivity. They want this good, reference model treatment across the entire IR realm, so Steve asked me to give a 20-minute briefing about the state of IR modelling. I overviewed it at a high level with a historic perspective. The only reason we have IR under wraps is because of high-accuracy Airy instrument observations. We have these instruments looking at the ocean surface and this is the only reason why IR has become an established part of the forward operator. Right now, the challenge is really the consistent treatment of the surface itself. If you put a detector above the surface you are looking at the radiance, which is a convolution of the reflectance part as well. That’s where the real problem with the IR part is. If we just model the emissivity itself the Suder 2006 model is good enough but you also have to take the BRDF into account.

The MW is very focused on modelling the foam. In the MW spectrum the foam has a large impact. In the IR it doesn’t change the refractive index, but it changes the slope. They brought my attention to some papers. In the MW they also have the same concern in the CRTM/RTTOV world, all these models are fast models. If we really want to do the full-blown double-integral radiation we can do that but it’s not fast enough for a practical model. That is the concern right now. Back to you Ben.

 

Ben: Thanks Nick, I put a link in the chat about the notes of our first meeting. I hope we can publish at this high level so that we can work at this referene model level.

 

Mark: Ben, I think for the next meeting maybe Ming Chen can attend the surface meeting.

 

Ben: I agree.

 

Ming: I think that it’s certainly very important to have a reference model. But the problem is what the reference model looks like. If it’s a physical model can we be sure that the physics are accounted in the current model, or are we formulating it in an accurate way? For a physical model there are some issues already, notwithstanding a practical model. We need something that at least discusses the physics, let’s say the reference data from observations. So, in this case we have cross-validation with satellite. In this case we can extend that. Over land we have more desire to have some high-quality data. We can already see some improvement but it’s very challenging on a global scale. This will be hard. I don’t know if they have a plan to bring in a reference model and bring it back to DA. So, this is not a simple problem for a small group. All the members are certainly experts in their sphere but if it’s possible and if they really want they should invite more people. Even within the CRTM you provide the framework for cross-validation. I know that Mark was working on this (or Paul). But there is some slight difference in the spectral regions. But also, in the computational assimilation. Many pieces to work on. Also, we needed to combine expertise to include e.g. wind speeds. I have been focusing on a model framework. Also, Mark raised some very good point with the wave spectrum. We didn’t consider any development in ocean waves.

 

Mark: Ming, I just wanted to check, did you get the version 3.0 beta version?

 

Ming: No, I think Kevin said Yingtao should do some testing.

 

Mark: If Ben has time he can share it.

 

Ben: Mark, you deleted the REL-3.0 from the ftp site?

Mark: I deleted the REL-3.0 tarball because the ftp site of STAR is public.

 

Ben: Ming, on the sea surface emissivity reference model we are starting with the dielectric constant but if you have that perfectly characterized there is still the issue of the interface with issues such as wave age. They are very focused on getting the physical base model very well characterized.

 

Mark: Two weeks ago Steve English and Thomas Meiser contacted me and it looks like for the operational ocean surface emissivity model there are two groups. One model is FASTEM and the other is the remote sensing system that Thomas Meiser has. Thomas contacted me because before he coded the FASTEM part based on a paper, he mentioned one coefficient is a Sine and the other is square and he got some results that look different when he followed the paper. When he changed the sine and the predictor from square to cubic he gets very good agreement. He is right, it was a typo in the paper. But the code is correct. Only in the paper is a typo. In this sense RSS and FASTEM agree well. But he also pointed out for the salinity their model is probably more realistic. I haven’t got time to check the low frequency part.

Ming: I did a comparison between RSS and FASTEM in the L-band.

 

Mark: Right now, RSS and FASTEM agree well.

 

Ming: True. Two, three years you told me that they need some standalone version of FASTEM. For example, the JPL model they use a different calibration.

 

Mark: RSS is a company. They are very strong. Frank Weights has lots and lots of expertise in the MW.

 

Ming: But RSS separates into L-band and not-L-band. When I coded their TL/AD it’s very challenging.

 

Mark: But there is some physical background as Ben already mentioned, which is called the boundary layer. Currently all the physical models depend on the sea-surface speed. But they never consider the development of these things. Another issue is foam. For the MW the foam impact is very large.

 

Ben: Foam can persist even if the wind slows down. At high frequencies foam becomes more of a scattering problem. For RSS they only go up to 89 GHz. We definitely want to go up to 183. The surface has a significant impact. There is an effort in this group to improve the high-frequency surface properties. The Aquarius mission was very helpful in this regard. So far, the RSS model has only been compared to few other models. The frontier in MW models is in high-frequencies.

 

Result:

 

Tasks:

-        

Responsible People:

 

Deadline:

 

 

 

Agenda Item 3:

STAR Gitlab Discussion

Discussion:

 

Ben: Anyobdy else want to give update on repository or technical issues?

 

Yingtao: I have some issue making a mirror of the repository in Gitlab.

 

Ben: There is nothing preventing you from doing it.

Yingtao: I tried, but I had some SSH problems.

 

Ben: It should be ok, but send me an email and I will help you.

 

Mark: Mirror means that you synchronize both sites daily?

 

Yingtao: All I do is setting up a mirror on Gitlab that mirrors all changes. Right now, we are using a community version of Gitlab. Right now, I am using a cron job that will pull the contents from Github to a local machine and push the changes to Gitlab from there. But for that I need some automatic way to access Github. We also can set the other direction to push from Gitlab.

 

Mark: It seems to me that synchronization is more helpful. Are you getting everything or just the changes?

 

Yingtao: Just the changes.

 

Ben: The way Yingtao is trying to do it is just not automatic. It’s probably the best way to do it. Ok, has there been any news on public access to your repository?

 

Yingtao: Oh, it seems Kevin is waiting for the STAR IT guys to set up a Github repo. Then we are pushing the things to the STAR Github. I don’t know what the progress is on that. It should be finished quickly. Then we are going to publish it on the STAR Github and then we need to synchronize STAR and JCSDA.

 

Ben: Tom and Harry had a meeting last week.

 

Mark: Harry will retire next week. His replacement will be a person from North Carolina. January 1st he will be acting director of STAR.

 

Ben: Looks like it’s Joe Pica.

 

Ming: What’s the background of this guy?

 

Ben: He’s an ocean guy. He worked in the OCEANOS project. What’s Harry gonna do?

 

Mark: Retire.

 

Ben: I was surprised.

 

Yingtao: Any changes on the JCSDA side?

 

Ben: If there has been any discussion on it I am not aware of it but it should happen soon. It’s at the discretion of the MOB. I haven’t heard anything. I think the reason we hired Dick Dee was as a replacement for Tom. He’d be a good choice, but it’s pure speculation.

 

Ming: Dick is UCAR, right?

 

Ben: Yeah.

 

Result:

 

Tasks:

-        

Responsible People:

 

Deadline:

 

 

 

Agenda Item 4:

Short Discussions with Hongli and Daniel

Discussion:

 

Hongli: Anyone is working with GSI CRTM 2.4?

 

Ben: Emily was supposed to test it but she’s very busy. Jason Otkin will also be testing some things for us.

 

Hongli: I compiled version 2.4 successfully.

 

Ben: I did that as well.

 

Hongli: I did a radiance calculation and it worked.

 

Ben: There should be differences. Maybe you can give us a couple of slides of O-B?

 

Hongli: If I have them I can show them.

 

Mark: The information about computational efficiency is also very important.

 

Ben: Daniel, any updates?

 

Daniel: I built FV3-JEDI in debug mode and ran about 800 profiles and it’s kinda slow. Now I need to modify the cmake system to use the PGI compiler. The simulations are slow and it takes a lot of time. I am focusing on modifying a couple of modules based on the current profiles.

 

Ben: You are using PGI for the OpenACC interoperability?

 

Daniel: I need to use PGI for OpenACC.

 

Ben: If you have any PGI issues let us know. Just a quick note, Intel has released their OneAPI for everybody. I put the link in the description. This will allow us to put ifort compilers in containers.

Link from the chat:

https://software.intel.com/content/www/us/en/develop/articles/intel-oneapi-fortran-compiler-release-notes.html

 

Ben: Anything else? Thanks guys. The next meeting will be during the holidays on the 28th. I’ll probably just cancel that one. Also the CRTM monthly meeting is on the 31st, I’ll probably cancel that as well.

 

Result:

 

Tasks:

-        

Responsible People:

 

Deadline:

 

 

 

Conclusion:

 

16:05h Final end of meeting.