2022-01-27

Agenda Item 1:

v2.4.1 release planning: bug fixes, features, and testing.  

Discussion:

Ben: We are currently working on CRTM v2.4.1, which will be the final scalar release before the first polarized release. For v3.0 we are making great progress thanks to Mark Liu and I will let him give an update shortly.

Mark: Ben, I can show a few slides on the v3.0 status after you.

Ben: Ok, so currently we have a few PRs aimed at the v2.4.1 release. The biggest effort is to get the OMP over channels working correctly. We are adding that in the Forward and K-Matrix operator. We are running into a bug with channel subsetting and these are identified in the issues section. If you don’t have access, please let me know. The main thing I just wanted to highlight are the leftovers here. Cheng is finishing the aerosols. We want to make sure all binary files have a netCDF equivalent. This might be too much for the surface files, because they haven’t been converted yet. But we want to get to a point where we can transition to netCDF. Conversely, building the CRTM requires netCDF now, which is causing some headaches for people who do not have the libraries ready. Some coefficients have been added. We would like to get the GOES-18 files from Yingtao.

Yingtao: There ready and I will add them to the repository.

Ben: We want to add a tiered testing set. Tier 2 are tests you can run with nightly builds. After all this is complete, we will create candidate releases. Nancy, who is the main point of contact in your organization?

Nancy: I have not information on that yet.

Ben: Do you have any information on v2.4?

Nancy: It seems to work like it’s intended.

Ben: One thing we need to do is timing and resource analysis. We want to provide that to partners. A recent addition from Dom Heinzeller from JCSDA to turn off OMP compilation.

Nancy: For OMP we are having issues when we are using tracking. Yannick is working on a fix in OOPS that might affect the CRTM as well.

Ben: Ok, then we will still have to update the documentation. We will continue to support the scalar version indefinitely. Any questions about what I have said so far?

Result:

N/A

Tasks:

N/A

Responsible People:

N/A

Deadline:

N/A

Agenda Item 2:

CRTM v3.0 integration into Github

Discussion:

Quanhua: I can show a few slides for CRTM v3.0. For v3.0, Ben has already the new functions in v2.4.1. Here I compare the current version v2.3 and also last year’s release v2.4 against v3.0. For the current instruments, they’re all MW and IR. V3.0 will add UV and VIS and backscattering from aerosols and clouds. The three models have the same transmittance. For the aerosols Yingtao and Cheng Dang added CMAQ. For clouds, the cloud fraction wasn’t correctly handled in v2.3 and v2.4. For v2.4.1 the Forward and K-Matrix model have OMP, but no TL and AD OMP. For v3.0 we added OMP at the profile level for the TL and AD as well. So far, we added the OMP for the TL as well. Testing the TL is very time consuming because you need to call it for every variable change. Other part is very similar. So, we probably need to compare the CPU efficiency, because for example the efficiency. For v3.0 there are a lot of code changes, because we added a new solver. But for the interface there is no change for the user. If you want to use a visible sensor, there is an optional parameter. There are large changes in the ADA module for the code. The other part is aerosol coefficients and binary file I/O. Here I list all modules with code changes. In total, for v3.0 there are more than 4000 lines changed. For current MW and IR sensors, there is no impact, except for OMP at profile and channel level. Otherwise it’s the same. I also compare the efficiency. v3.0 and v2.4 are practically the same for MW and IR. The one thing I would like to bring out is the testing. In the past the testing is done by Paul van Delst and David Groff. At that time, we were only working on MW and IR channels. The testing was focused on ECMWF profiles and IR. For v3.0 we have a lot of new stuff, so we need to add new tests for the visible and for different zenith angles, not just nadir, and day time cases. In the past we didn’t do consistent testing between Forward and K-Matrix modules. Because of the OMP changes we need to test the consistency there. Testing is very time consuming. It’s very hard to find errors. For the OMP Forward model the result is not right, but the code is running normally. So, you need to dig in. I read the code several times, but couldn’t find any problem. Finally, it came out that the error is only caused by two lines. As you can see here, SfcOptics is an array of the thread. This array can only find the array for MW sensors over the ocean. In other cases, you won’t find the error. That is why it is so hard to find this error. Right now, we have another OMP error. For ATMS you have 22 channels. If you have 6 threads or 6 channels from subsets, the value here will be 22/6 and then the value down here will be 22/3 = 7. But the declared number of threads is only 6. This causes a problem right now. This channel loop using this methodology is not efficient, because it divides channels in chunks, but we know that some channels compute very fast, while others are slow, e.g. in the troposphere are clouds, while there are none in the stratosphere. The main point is that we need many people to contribute to testing. That’s all what I have right now.

Ben: Thank you Mark, that’s really nice. I like your document, could you share that with me. I agree that the testing framework needs to be extended and I appreciate your effort. I also wanted to add NLTE testing.

Quanhua: Can from your side someone establish a testing code similar to what Paul and David did in the past? I mean Tier 1 will take more time.

Ben: You have seen the existing testing framework that we have with about 90 tests.

Quanhua: Maybe we can add channel subsetting and certain old sensors.

Ben: Let me just show my screen. These are the tests we have right now. I designed it in a way so you can just add any instrument you want. This is all based on what Paul did. Typically, there are channel subsetting tests right here. There are AOD tests. Your point is well taken, we need to be more comprehensive. The 5000 profile is maybe the

Yingtao: In the CRTM repo there is a lot of code for the development. Some code has actually been updated because it wasn’t working anymore. I remember Mark had an issue because Read_AtmProfile broke.

Qhanhua: That is probably hard, because your input structure is different from what we use right now. Some applications might not have been used for a while.

Ben: My position on that is it’s really up to the developer to make sure that adequate tests for the application are provided. Your point is taken. If we use old code that hasn’t been used in a while we need to make sure that it works. I’m trying to get away from the autotools build system and get to a cmake system.

Quanhua: Probably we need to test the new things. Bottom line is we need to make sure that the release version is working. In the past the transmittance package heavily used code from the release version. Once that is changed, the transmittance code breaks. It is probably better to have a separate transmittance application that is independent, so that it is not too tight.

Yingtao: That is one solution. For the coefficient reader for example, that is also needed.

Quanhua: If we want to incorporate the changes, someone who is responsible for the transmittance package will take charge.

Ben: Alright, that’s where coordination really helps. We probably need Mariusz give a change to talk about aerosols.

Result:

N/A

Tasks:

N/A

Responsible People:

N/A

Deadline:

N/A

Agenda Item 3:

Aerosol status 

Discussion:

Mariusz: Can you share the slides? Thanks. In addition to AOD retrievals, Aeronet also provides retrievals of absorption AOD. In 2012, there are about 500 Aeronet sites on the continents and islands. This provides a comprehensive view for validation. In addition to this standard AOD retrievals, there are also Almukantar retreivals. They were generated from 1993 to present in near real time. I had this recent citation on how the data have been selected and the QC. We call it AAOD in addition to AOD operators in JEDI and used it in evaluations. One thing that is really important for this comparison is that NOAA and other centers want to include aerosol interactions with meteorology. That will potentially have impact on weather and chemical forecasting. If we look at how this relation between AAOD and AOD looks, we can have some look at how these aerosol interactions work. We used NASA tables to calculate AOD and AAOD. The NASA tables also have SSA. So we calculate AOD with this formula, 1 -  SSA is this expression. And AE is generally the absorption Angstrom exponent.

Ben: You said Aeronet retrievals obtain AAOD. How can they distinguish absorption from extinction?

Mariusz: I don’t know these details, I would have to look much deeper into the literature. It’s a good point.

Quanhua: Mariusz, looks like the Aeronet AAOD value is derived, not measured.

Mariusz: Yes, the basic value they obtain is SSA (albedo).

Ben: So, there will be a bias between your retrieval and the NASA tables you use. You require an SSA assumption in your retrieval.

Mariusz, Ok, let’s look at the second slide. So, there was a paper written by Cazorla from the observation group from the aerocom community. He determined based on his observations that AAE is an expression of the chemical type of the aerosol and SAE is an expression of the size distribution and now we plotted Almukantar AOD and this is in close correspondence with his findings. Now with the model we found something that we called a bug first, but we always obtained the same result. Then we talked to Nancy who is working for the GMAO and she found that already for MERRA-2. It looks like there’s a lack of scattering in terms of absorption by aerosols. I don’t know how to explain this. There may be a deficiency in how GOCART is looking at the atmosphere and we want to follow up with NASA. I would be really willing to hear what you are thinking about.

Ben: I have done something similar with hydrometeors. We looked at multiple frequencies. When we modeled it, we found that it was extremely overfitted. That came done to the particle morphology, which were spheres at the time. Your results show that you are over-constraining the relationship for your aerosols. My very first would be to use a completely different aerosol table.

Mariusz: Ok, our choice is to use the CRTM with the CRTM table. So, you don’t see this. What do you think about the statement from Cazorla? That is different from droplets. Droplets seem to have similar composition.

Ben: If your index of refraction is wrong from the composition that also affects your scattering. However, I’m not sure that I understand the AAE > 1 in your results.

Cheng: Mariusz, a quick comment organic carbon, the AE doesn’t seem to be entirely correct.

Mariusz: Betsy also mentioned that the larger variability in absorption could come from internal mixing, unlike GOCART, which assumes that all species are separate. Carbon often has lots of sulfate. Dust is also a mixture of carbon and dust. That’s a limitation that GOCART cannot overcome.

Cheng: Yes, I think for CRTM we just assume that all aerosols are externally mixed. There are a lot of models for internal mixing. But still, the AE shouldn’t be constrained from 1 to 1.5.

Sarah: So Mariusz, if you look at dust laden regions, are they different?

Mariusz: Yes, that is something I should have done originally in JEDI. This is plotted for the whole domain.

Ben: And this is the sum over all species?

Mariusz: Yes, the whole blob. We use the JEDI temporal filter that uses the observation that is closest in time.

Ben: It would be interesting to see the plot separated by species. If it’s multiple species you would expect a lot more variation.

Ben: Ok, so what’s the next step?

Mariusz: I want to have a look at how the original evaluation looks. I want to contact Peter Colarco to see what they think.

Ben: Could you loop is in? How about Andy, did you get to this level of analysis yet?

Andy: No, not yet.

Ben: I think it could be useful. Maybe the observations are wrong as well.

Mariusz: Alright, thanks.

Ben: Any other topics that need to be brought up here? Just generic updates on progress?

Quanhua: Does the person working on the OMP channels still work for the CRTM?

Ben: Daniel Abdi? No, he was just a short-term in-kind contributor.

Quanhua: Another problem is the overflow of the array which we needed to discuss.

Ben: He is a nice person who would probably agree to a meeting.

Ben: Just one more announcement: I have submitted a proposal to BAMS. I got feedback and within a week or two we should have feedback on whether we can move forward and we are willing to accept co-authors. And the CRTM v3.0 topic will probably become a separate series of articles.

Ben: Cheng do you have anything to update?

Cheng: Just a question for Mark, did you update the phase function expansion?

Mark: Just for the binary coefficients. The code is almost the same. I added a few lines in the reader there. When this condition happens is the code for the fully polarized model.

Yingtao: Isaac made some modifications to the cloud tables. Do you know what kind of modifications he made?

Ben: There’s a draft PR you can look at, but these are significant modifications and it’s not even guaranteed that these changes will be included.

Yingtao: I mentioned this because we are working on new tables from Ping Yang’s group and we would like to extend the dimension by temperature and density.

Ben: Ok, I can set up a meeting. But I wouldn’t want to do that during a monthly meeting.

Ben: Ming, you wanted to say something?

Ming: I think that it’s time to make a roadmap for integrating CSEM. But I have a few things, so, do you think that in v3.0 we will just use CMAQ, or something else?

Quanhua: Ming, I think both are available CMAQ and GOCART.

Ming: The other thing is, for [unintelligible].

Ben: Which version of CRTM are you using?

Ming: [unintelligible] In any case I think it’s not possible to have CSEM with CSEM. So, I would like to suggest to have both netCDF and binary for v2.4.1 and then just netCDF for v3.0. The other thing is, the BAMS article is also a good chance to include something from CSEM. I’m still working on the MW BRDF, because it’s very challenging. I’m just struggling with the regression. That’s the most challenging part. The other thing is, we need a lot of validation things, like a reference data set. For the UV part I am also working on the BRDF, but in v3.0 we just need to include everything possible in the LUT. For example, Wisconsin has a data set.

Ben: It would be helpful to set up a technical meeting where we can have a look at the regression model.

Ming: I just used linear interpolation.

Ben: Please feel free to set up a technical meeting and invite whomever you feel might be useful for it.

Ming: CSEM itself is a part of the CRTM. But right now, it’s parked in the NOAA STAR Gitlab domain. Either we could put a fork in the current JCSDA Github. I just found that you disabled the forking functionality?

Ben: No, EMC has a fork. I’ll double check.

Ming: I think that a first version of CSEM is ready on the NOAA STAR Github.

Ben: I don’t think I have access to the STAR repo.

Quanhua: Ben, do you have like an initial plan for v2.4.1?

Ben: I am hesitant to do that once the pieces fall into place. I want to make sure we have a really nice release because we were very quick with v2.4.

Quanhua: I agree, OMP on the channel level has some new challenges. Is the active sensor also part of v3.0?

Ben: Yes, but not of v2.4.1. It’s something Isaac was working on, but he is stalled at the moment.

Quanhua: The schedule is too tight, so merging v2.4.1 and v3.0 is also possible.

Ben: Maybe. My feeling right now is that there is no rush for v3.0. So I don’t want to rush an early release, so that people can find an advantage in the polarized RT.

Quanhua: Another thing is also for people to demonstrate the usefulness. Do you think we can share the code on Github?

Ben: Yes.

Quanhua: And once people are using the code, maybe they find new problems before the release.

Ben: I have no problem with that, having folks being active and do testing.

Ming: As for v3.0, probably STAR is the major user.

Quanhua: Yeah, we have operational users. Perhaps we can make it available for more broader users, such as Europeans.

Ming: [unintelligible]

Result:

N/A

Tasks:

N/A

Responsible People:

N/A

Deadline:

N/A