CRTM Technical Meeting Protocol

Core Topic of the Meeting: General Discussion

Date:  2021-02-08                                 Time: 15:02 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, Hongli Wang, Nick Nalli, Ming Chen, Yingtao Ma, Quanhua Liu


Agenda Item 1:

Update from Nick Nalli on Ocean Emissivity

Discussion:


Introduction by Benjamin Johnson:

Ben: Nick you want to fill us in on how you have been doing? I don’t have any updates since we’ve been working on the AOP.


Ming: Any results?


Ben: No, it’s not ready yet.


Ming: That seems pretty late.


Ben: I agree.



Update by Nick:


Nick: Can you hear me ok? Ok, I’ll go ahead. So JPSS proving ground risk proposals approved work on this topic but it’s got to be under JPSS, so I will be funded to work on this topic in the next year. The first work will be ocean emissivity. Jim Yung was running some simulations and he found some improvements but also issues. What I have been working on is some new sets of refractive indices. This was from the ISSI meeting. We were working on new optical constants for supercooled water. The application was for clouds, not ocean surface emissivity. They have this new dataset with measurements for water below freezing temperature. I’ve taken those data and merged it with existing datasets at higher temperatures. The lowest is at 279K. There’s a distance between those two datasets but we have some nonlocal information that allows for interpolation between them. This is still not really an optimal solution but it is an alternative to the ad hoc dataset. Now I am regenerating look up tables and we are comparing them. I don’t know yet if this is gonna fix the problem that Jim found. He is concerned about the area about 900 cm^-1 but there is also about 800 cm^-1 that was investigated at the kCarta team. I have created a LUT that I can hand over to Ming Cheng.


Ming: Nick, I think this is a good effort. I think we need to make an effort to refine version 2. We already have all refractive index data in the model. Is it possible to share your refractive index data with us? Also, there are some efforts [unintelligible]. What’s the impact of the improvement of the refractive index? I think Kim is also doing tuning in the GSI. So, we have a comprehensive effort. But we need to linearize the calculations. Do you have an estimate of the impact in GSI?


Nick: That seems like a complicated question and I don’t fully understand what you mean. Jim Yung is doing these global assimilation tests and he’s giving me feedback. So far, we’re seeing some expected positive results but there’s some unexpected results. He’s showing that there’s temperature dependence in part of the spectrum that shouldn’t be there because the optical constants are zeroing out. But Jim’s results show that around 900 cm^-1 there’s still temperature dependence. And there are issues in the IR window so this is critical. The interpolation between the two datasets might be the cause. I’m not positive that I’ve answered your question.


Ming: Will you share the refractive index data with us?


Nick: Yeah, I have that stuff but I want to make sure I’m thoroughly testing it through before I hand it over. I want to make sure it looks ok. Another feedback from Jim and Sergio, he’s got a system with kCarta and a clear sky mask because we want to upgrade SARTA too. It’s not clear whether this will be advantageous to them because this is geared towards the CRTM. I got some feedback about problems from them too. We got this new set of data from December.


Ming: Another thing is about the model itself, the big difference with the new refractive index is in units. Do you think it’s because of some scattering deficiency?


Nick: That’s a good question. The larger angles are where things get difficult. Everything becomes more complicated. The atmospheric path and the shadowing effect of the waves are issues. With Mashuda and Smith data we can handle wave shadowing. But it also becomes more difficult to handle to reflection. With new more accurate sensors like CrIS we are seeing these things and it becomes more difficult. This translates from the optical constants. They become manifest within the Fresnel equations and they become magnified with larger angles. It all comes out within the Fresnel equations. Things become interesting within the larger angles.


Mark: First congratulations on your GNSS proposal. Second, quick question, will this emissivity part be released with version 3?


Ben: It’s really up to Nick if he says that things are done to his satisfaction.


Ming: Ben, I agree. The CSEM is there and everything is ready to go. There is no reason that we postpone this release, at least with the CSEM.


Mark: So, you’re still open, ok.


Ben: Thanks Nick. Quick question: the reason to add supercooled water is just for interpolation?


Nick: Yes, it’s a measurement at freezing.


Ben: And the salinity variance doesn’t matter?


Nick: Yeah, we’re ok with salinity because it has to do with the percent variation from a mean value. Salinity really doesn’t vary too much and we already have a correction for the global mean value. We are safe to ignore it.


Ben: Makes sense. You wouldn’t do this in the MW.


Ming: For MW I have a reader within the CSEM for the future. We just need to read in the salinity.


Mark: I just have a follow up question Nick. Do you mean the refractive index for pure water is different, so you need a different index for ocean and lakes?


Nick: Yes, I haven’t done a sensitivity study but there’s a big difference in salinity and my take on this is we want to have a separate set of data for fresh water.


Result:

Nick Nalli has produced a new refractive index dataset for ocean surface emissivity.

Tasks:

-       Testing the new refractive index dataset.

Responsible People:

Nick Nalli

Deadline:

N/A



Agenda Item 2:

REL-2.4.0 BT cooling issue in GSI

Discussion:


Ben: Thank you. Ok, one thing real quick: Haixia has investigated REL-2.4.0 and I have created a Github issue. There’s an apparent cold bias. I’ll be testing this in the next few days and we can see if there’s some fix. My initial suspicion is that it is related to the cloud fraction bug we fixed.


Ming: This is a global mean or specific surface?


Ben: I gave all the details in the issue and you may just want to read the issue. My understanding was that it was a single-cycle GSI run. She’s seeing some warm differences w.r.t. v2.3.0. She did swap out the coefficient files and there’s no change. There are also some instruments that are doing better with more observations included. The next I will try are some internal tests.


Mark: Ben, it might be related to the solar radiation.


Ben: That’s a great recommendation.


Yingtao: Why do you think so?


Mark: I don’t know the GSI operation version.


Ben: The MW instruments got worse, so it might be a cloud issue. She says the number of obs for IR got better.


Ming: So, it’s MW?


Ben: I have to look exactly at the channels being used. I just wanted to let you know about this issue.


Ming: So, this should be tested before release.


Ben: For any release you can only test so much. I talked to Emily and she did a compile run. She didn’t report any issues like this.


Result:

Haixia Liu’s GSI test runs show a cooling for MW instruments with the new 2.4 release.

Tasks:

-       Debugging the BT cooling issue

Responsible People:

Benjamin Johnson, Haixia Liu

Deadline:

N/A



Agenda Item 3:

Update from Yingtao on NLTE

Discussion:

Ben: Yingtao, how are you doing?


Yingtao: For the AOP I’ve been working on the NLTE but I would like to contact Chen Long and at the same time I need to do some documentation. I am working on that.


Ben: Are you happy with [Jonlang?]’s approach?


Yingtao: This approach is different. My approach is straightforward to change the coefficients.


Mark: At Wisconsin they were showing the NLTE effect even for night time. Is there any follow-up on the night time?


Yingtao: We don’t have much follow-up. [Jonlang?] suspects aurora. That night time NLTE is not conclusive. It will be difficult for the CRTM to predict that because we don’t have any information to put in. Because as [Chris Vanel?] said we are trying to predict the movement of the dark. That’s nothing we can do. We have a temperature profile with 2 layers. We need to introduce some other factors.


Ben: Ok, that’s kind of the assessment we are looking for, the diurnal issue, what kind of instruments are impacted. You still have the solar impact at TOA. I would be surprised if it were Aurora because it happens during the day as well.


Yingtao: During the day time sunshine is the major factor. I don’t believe it’s Aurora.



Result:

Yingtao is looking at different NLTE implementations in the CRTM.

Tasks:

-       Evaluate different NLTE implementation methods.

Responsible People:

Yingtao Ma

Deadline:

AOP2020



Agenda Item 4:

Update from Hongli

Discussion:

Ben: Thank you. Hongli is there anything you want to talk about?


Hongli: Yes, recently I started working on the GSI. Currently I am checking the input data. For the CRTM the input units for water path need to be checked.


Ben: Yes, there are some pretty straightforward conversions for the water path.


Hongli: Yes, I will let Cheng and Yingtao know.


Result:

N/A

Tasks:

N/A

Responsible People:

Hongli Wang

Deadline:

N/A



Agenda Item 5:

Cheng’s Update

Discussion:

Ben: Patrick or Cheng, any updates?


Ben: We did get a request to generate the FY4A sensor, AGRI instrument. Apparently, something similar to ABI. This person is probably working with Fuzheng.


Mark: It’s a Chinese sensor?


Ben: Yes. I know the Wisconsin folks are working with GIIRS. Cheng?


Cheng: I am still working on the aerosol tables and I am working on GOCART. Soon I will initiate a pull request and you can see the changes.


Ming: Do you have some plan to migrate everything to netCDF?


Ben: We have already done it for clouds and aerosols?


Ben: You raise a pretty good point on how we version the data internally. We probably should have a little more detailed discussion about that. Right now, we are trying to follow what was done previously but we don’t want to get mixed up in our own efforts. We should have a specific meeting on versioning.


Mark: Just an information for Cheng. She asked a question about two different coefficients. For 3.0 model the coefficients are for the most recent GOCART model. It’s old information and I couldn’t remember who provided the information to me. Maybe it was GOCART. This was done probably in 2015. I’m not sure. In the current baseline is GOCART version 2 and in release 3.0 it’s version 3. Sarah is writing about the GOCART version. The website didn’t mention anywhere what’s version 3 or 2. Once Sarah provided the document I saw the difference.


Cheng: I saw your comment but I do have some follow-up questions. What do you mean by version 2 and 3? I do have the latest GOCART version and they do not match at all. For the CRTM we divide the properties in bins but not in GOCART.


Mark: CRTM is more general. For CRTM each bin can have multiple modes. For the latest GOCART version they have multiple modes but in the CRTM we only have 2. The NASA website is not updated.


Cheng: Did you generate those tables?


Mark: For version 3. Version 2 was several different people.


Cheng: Did you generate those tables?


Mark: Yes, for version 3.


Cheng: I noticed for sea salt coarse mode sizes are the same.


Mark: That’s for version 3.


Cheng: So, these two sea salt modes are supposed to be the same.


Mark: CRTM is more general. What we did for the aerosol model we have one bin is the active mode. But this sea salt also depends on the relative humidity. Different mode corresponds to different size.


Cheng: Coarse mode 2 and 3 have the same size, is this correct?


Mark: CRTM can be used for multiple modes.


Cheng: I think I can point out the issues I have. The other question is we have talked about the delta-fit for a while. When we have the same. From the code you shared with me it seems impossible to get the coefficients in version 3. Do you have more insights you can share?


Mark: The delta-fit code I sent to you probably has some error. For all two streams when I write very small code and


Cheng: Even with the Fortran code you sent me it’s impossible to get the same coefficients with the same normalization.


Mark: You probably didn’t look into the delta-fit code. However, the last term in the CRTM is not zero but for delta-fit it is. The delta-fit will return two values. For the CRTM it’s the fit.


Cheng: Is there any documentation on this?


Mark: This setup is much easier. You don’t need to put the last value there. Otherwise the last value is always zero.


Cheng: I guess for the delta-fit coefficients you have you always divide by a factor of two.


Mark: I don’t remember who asked the question. In the CRTM the first value is 0.5, not 1.0. That’s why the CRTM just puts the 0.5 there. Energy conservation is the integration of the phase function, so that’s why there’s a 0.5 there.


Cheng: This is only for the first term?


Mark: No, all the terms need to be divided by two.


Cheng: Thank you.


Result:

Cheng is working on including the new GOCART table in CRTM3.0

Tasks:

N/A

Responsible People:

Cheng Dang

Deadline:

N/A



Agenda Item 6:

Meeting Conclusion

Discussion:

Yingtao: I have a question for Ben. Our coefficient directory is a separate site now?


Ben: I’m not happy with this setup but that’s what I had to do satisfy management. UCAR has a data service called DASH and I am working with the DASH people to get all of our coefficients into one place. Does that answer your question?


Yingtao: Yes, just when I was looking at the CRTM there is no fix directory.


Ming: Maybe we can learn something from RTTOV?


Ben: Yes, DASH would provide a web-based interface. DASH is a very robust data website. We have it set up for UFO right now. I just need to set it up for standalone CRTM right now.


Mark: There are also lots of people who don’t use Github. For the release you can have a website.


Ming: I think that’s a good idea. But for the surface part we can expect that developers will provide a website for downloading.


Ben: We can be intelligent about this. These data portals provide a uniform access workflow. The challenge allowing users to add data files, we want to be able to add data sets. We still need to have a PR and the internal versioning needs to be considered.


Ming: For the CSEM we will have a lot of research models on their own website. We need to consider this one.


Ben: I put it as an item in the AOP2021. The other thing I want to respond to is Mark’s comment about tarballs. Github provides tarballs.


Yingtao: But that’s for the whole repository?


Ben: I am happy to provide tarballs.


Yingtao: What Mark means is he just wants the build folder, not the whole repository.


Ben: Yes, I can look into that.


Ming: Ben, [Unintelligible] CSEM documentation. It didn’t have the ruby script as before. Normally I would follow the existing documentation.


Ben: We don’t use Paul’s Ruby scripts. We just modify existing Latex documents.


Nick: I might be able to help there.


Ming: Maybe for new programming languages it might work better.


Ben: We’re past time.


Ming: Anything related to AOP?


Ben: I have to contact each member of the executive team this week and have to work with them. I’ll let you know if I have something I can share.


Result:

N/A

Tasks:

N/A

Responsible People:

N/A

Deadline:

N/A



16:08h Final end of meeting.

  • No labels