Agenda Item 1:

Quarterly Review

Discussion:

Introduction by Benjamin Johnson:

Ben: It’s a busy past month for us, especially with the 2.4 release. Everybody in management was very impressed. Thanks to everybody for their contributions.

Just a couple of quick things: We’re already starting to think of AOP2021. On the core team we’re thinking about how to structure the AOP to better align with our way of working on Github and so on. One thing I will do is to engage you as in-kind contributors and get your feedback on how you can contribute better and on the management level who is able to contribute. This is what we will do in the next 3 weeks. Especially for release 3.0 there’s still a lot of work to do.

Any comments on the quarterly review?

Result:

The CRTM REL-2.4.0 was a success.

Tasks:

N/A

Responsible People:

N/A

Deadline:

N/A

Agenda Item 2:

CSEM Discussion

Discussion:

Mark Liu: I looked at release 2.4. It is good to have the new function for the netCDF file. Paul wanted to do that for a long time but never had time. In the initial test I just tested the aerosol part. But only when I tested there are some problem that doesn’t come from 2.4. Maybe Ming Chen can answer this question. The surface model there is no TLAD model and the model is somehow very strange. The reason is I tried to run the baseline testing, the data is corrupted when the snow depth is larger than 50. The baseline tests check the consistency between forward and TLAD model. When you have snow-depth is +/- 50 the change is very little but the BT change is very large. Probably we can look into the surface part because I don’t see any TLAD there.

Ming: You can probably check Ben’s 2.4 documentation. He did a very good job. We haven’t included new features for 2.4, only 3.0.

Mark: So CSEM will come for 3.0?

Ming: Yes, I think in the current land model the snow is not so well optimized. Fuzhong told me they want a simple model. For snow we only use an empirical model, so we don’t have a TLAD model. But I think if you think that it’s very important to have MW snow depth or sea ice for DA, we can implement some simple physical models. For snow a physical model is very difficult though. For Ben or Patrick, we can work together to modify the CRTM to take full advantage of the CSEM.

Mark: It’s good to see that version 3.0 will include the surface part. I just had a look at the TL part and saw it was zero. When I tried the model 2.3 it had the same issue.

Ming: You mean the TLAD of land?

Mark: I saw the problem in the user input for snow depth a very different function is called.

Ming: Yes, it’s very complicated, which model is called in the CRTM right now. For instance, if the snow depth is a larger than a certain threshold it will call a convenient physical model but otherwise an empirical.

Mark: We’re looking to version 3.0 because the problem needs to be fixed.

Ben: Yes, they’re already discussing how to assimilate snow depth. It’s not just 2.4, it goes back to 2.1.

Ming: If we can find some physical model that includes a parameterization for snow depth we can implement that.

Yingtao: Even without a new model you won’t fix the TL issue?

Ming: Yes, we don’t have a TL model, it’s hard to implement.

Mark: I saw the forward model is already there. How hard is it to include a TL model?

Ming: You need to handle physical processes of the soil and scattering. It’s a lot of coding.

Mark: Yingtao is saying, if we just fix the current model, create a TL/AD for the current model…

Ming: It’s already done. It’s a little bit complicated.

Mark: Then we can include that in the next version.

Ben: I agree. There’s also the point of continuity across a threshold, because that’s what Mark was experiencing. I hope that’s going to be fixed in the CSEM and the NESDIS land model.

Ming: I think this is not an issue with CSEM, because we implemented that two years ago. The critical issue for me is how the user can handle the interface.

Ben: How about your Gitlab repository?

Ming: Gitlab is not an issue for Github. Kevin said that Harry …

Yingtao: I just got an email from Kevin to discuss this in the meeting. We may want to mirror the Gitlab repositories on Github.

Ming: But this is no help for the public access.

Yingtao: We don’t have any other published repos.

Mark: Ben, what is planned for the 3.0 release?

Ben: For the beta release? It would be some time before March 31^st.

Mark: So, you might want the CSEM sometime before the end of this year for testing and for consistency.

Ben: We need CSEM right now. I would ask Ming to push on Kevin to have the code, no matter where you host it. We got to get started on this right now because it’s going to be the hardest part for us to integrate. There’s a lot of work that needs to be done. We are going to be hard-pressed before March 31, but the sooner we can get CSEM, the better.

Ming: I think you are right, we need to get it included as soon as possible. Even in the software structure there needs to be some refinement. What I hope for is to work with EMC on Cal/Val or Land DA to find some very important issue we need to improve, that’s the problem I expect. Even in the current interface this is not an issue I think. End of this year is enough. Because the integration is done. The only thing is some refinement, probably testing. As I first try I hope to repeat the core functionality, but with the new features like land TLAD I already did the testing but testing from others is important.

Ben: Right, and that’s exactly why need to do this now, not only because of the integration, we also have to write unit and regression tests we need to write for all new features. The hard part really is testing and debugging with our partners. Mark brought up some good points.

Mark: Yeah, the surface part alone is probably the only issue. Therefor we need probably at least 2 or 3 months for testing and your current CSEM doesn’t have the polarization part and we need to vectorize it especially for solar radiation. You can’t do that in one month.

Ben: That’s what we need to understand for 3.0, what is missing.

Ming: I think for Ben talking about 3.0 means that we need to release some basic functionality.

Mark: No, 3.0 beta will be something like 2.4.

Ben: I want it to be a working version so that people can use it in a DA context. It doesn’t need to have all features, but the full functionality. The structure of the polarization, particularly for visible, needs to be present.

Ming: When we talk about the polarization that’s a very important feature for 3.0. At least for CSEM that’s designed for the current CRTM and it can accommodate for the polarization. That’s why I said that it’s good to have the 3.0 as early as possible.

Mark: Actually the 3.0 alpha version that I gave to Ben and Kevin, if we want to include the CSEM we can start from zero.

Ming: Just give me the alpha version and I can have a look. Perhaps we can have a parallel version or something that is integrated in the CRTM.

Mark: Probably to be more realistic for the release 3.0, there is not time to include the surface, but if you can solve the TLAD problems from the previous version, what do you think, Ben?

Ben: Ok, yes.

Mark: Just fix the current issues in the scalar release right now, that would be good for 3.0.

Ben: That’s good for me. We should see what is available from CSEM. Perhaps it has an easy Lambertian surface model available.

Ming: This is not an issue for the CSEM. The only issue is the interface for the CRTM. If CRTM for example requires polarization in the upper level, we can modify the interface. This is also the purpose of the CSEM. I don’t think this is something we need to worry about. We only need to test the full function in the CRTM. Especially Yingqu tested a lot in the GSI. I hope that it can be included in an official release of the CRTM.

Mark: I think at this point, Ming, don’t worry about the polarized CSEM and just supply what you have. It’s a good idea not to have a lot of new things for a new release.

Ming: Mark, the only thing is we wrap everything in the CSEM.

Mark: No, as you said the CSEM is already tested at CSEM? Just supply this version. Don’t worry too much about new functions.

Ming: Yeah, that’s the point, the CSEM can fit in the current CRTM version, but which version should we include it in for the official release?

Mark: Yes, I’m not in the core team, but just as a suggestion, we can have an official release in version 2.x, rather than 3.0.

Ming: Mark, that’s the question between minor and major release.

Yingtao: So, you said you can use the CSEM inside and outside the CRTM, so you can make your own repository for CSEM alone.

Ming: You are right, I think this is the way we are taking.

Yingtao: Yes, it’s like with the coefficients, you do your own maintenance and your own release.

Ben: Yes, that’s what we plan on doing.

Yingtao: Yes, but then you have the full responsibility if something goes wrong.

Ming: Yeah, that’s for sure. The way we are working with Ben is to go into the major release. I also asked Paul to have CSEM in a major release because these are major changes.

Yingtao: No, you can have your own CSEM release, like CRTM 3.0 and CSEM 1.0.

Ming: That works, but I think it should go together with REL-3.0

Mark: I think make it simple, it sounds too complicated.

Do you all agree to have a separate release of CRTM 3.0 and CSEM. Then for your part you don’t need to worry about the CRTM part.

Ben: So that puts the responsibility on us to integrate it and that’s the plan.

Ming: Yeah, that’s the way we are taking.

Mark: So, Ben is planning to release 3.0 in March and what’s the schedule for CSEM?

Ming: Hopefully a little bit earlier.

Ben: Are you talking about our current repository setup?

Ming: Yeah, this is a good approach but we need a public domain for CSEM.

Ben: I agree completely. The sooner you can do that the easier it will be for us to test and integrate.

I think what needs to happen next is to make the CSEM code public so we can start integrating and testing. The build system needs to work with CSEM, that’s a lot of work. There are gonna be some changes. We will not change the surface structure specifically but the sooner we get it the better. If you don’t mind please go back to Kevin and say that Ben is really pushing because especially with December that’s not much time to do a full major release.

Ming: In this case for 3.0 either you or Mark will have the beta version?

Mark: A couple of months ago I sent the alpha version to Ben and Kevin and I will send you what I call the beta version that just fixes some bugs.

Ming: I think it’s very interesting that you did some testing with 2.4 and found some differences with finite differences. Can you send me some testing results?

Mark: Sure, I am running the baseline testes.

Ming: That’s good, if we need some quick fix we can do that with the current version.

Mark: Yes, it’s because of snowmodel_1 and snowmodel_2.

Ming: I think Ben is also interested to share tested with partners.

Ben: Mark also did.

Ming: I think it’s very helpful to modify the current CSEM structure.

Mark: For 2.4 it’s very helpful we have learned something there. For 3.0 the netCDF interface can probably work on some pre-compiled version of the code. If the library is not available the user can use the pre-compiled. The only thing that needs to be changed is changing the atmosphere structure from INOUT to IN. Also, the current cloud fraction implementation makes the code slower. Also, we need to think about how to make things easier for the user.

Ming: Mark, I think in the future as Ben said in the future the users will use netCDF, but we can probably add some directive.

Mark: Yeah, that is what I said. Another thing I am thinking about, probably in the netCDF file the file already contains the cloud model, so you don’t need such a complicated interface because that information is already in the file.

Ben: Yes, that was done for the convenience of the user. I agree we want to make it a little bit more automatic.

Result:

The CSEM package needs to be available to the CRTM team for integration and testing ASAP.

Tasks:

-       Provide the CSEM to the CRTM team

Responsible People:

Ming Chen

Deadline:

January 1^st, 2021

Agenda Item 3:

Ben’s CloudCoeff investigation

Discussion:

I have been looking at the cloud coefficient files. With 2.4 we have been releasing a number of experimental cloud coefficient files. [Ben shares a presentation]

Just a few notes on 2.4. We have a few new building options. We have autoconf and ecbuild. The other thing is we don’t include the fix/ directory anymore because AWS is too expensive. I’m currently using the UCAR ftp, but that doesn’t work for our HPC users.

For the cloud coefficients, there’s a red and black line in these graphs. I wanted to compare the concatenation approach that we used for the data from Penn State. Cheng’s and Penn State’s concatenation method agree very well. Now here’s the comparison. Using check_crtm for a comparison with clearsky and nsow cloud cases. The green line is my new code, black is the original CRTM code, and blue is the Penn State data. So, the Penn State data has some weird thing going on here because it doesn’t go fully into the BT temperature depressions.

This is some unexpected behavior for snow.

Yingtao: This looks like some interpolation issue. Probably you are using a different interpolation scheme with Penn State.

Ben: I’m just swapping out the coefficients. I have to be more rigorous here. I also looked at Ping Yang’s earlier delivery and there are some interesting differences. The benefit of this approach is that it has full polarization support. I think it’s a good step to get linear polarization support.

Mark: What’s the x-axis, channel or frequency?

Ben: A little bit of both. It’s a mixture of channels and profiles from the test case. Next time I’ll plot it just versus channels. This is just an initial comparison.

One thing that is missing is the conversion of the Legendre coefficients for non-spherical particles. I just wanted to show this comparison.

Result:

Differences in the BT results of check_crtm.fpp for the Penn State snow coefficients.

Tasks:

-       Closer investigation of the Penn State coefficients.

Responsible People:

Benjamin Johnson

Deadline:

Next technical meeting

Agenda Item 4:

Updates from Bryan Karpowicz and Daniel Abdi

Discussion:

Any comments from Bryan or Daniel?

Mark: Just one comment, when I test netCDF it looks fine, but for the parallel part is it already in the code?

Ben: Yes.

Mark: How are people testing that?

Ben: Yes, you need a case with more than one profile. It takes the OpenMP environment variable and works with that.

Ming: Ben, You implemented the parallel part in the CRTM driver?

Ben: It’s inside the CRTM, not the driver.

Ming: In this case there is some code inside the CRTM, right?

Ben: Right.

Ming: But CRTM is only single-profile.

Mark: No, CRTM does multiply profiles. Ben, probably you can teach me something. If you have a CPU with 4 cores, is that still OpenMP?

Ben: That’s a longer converstion

Bryan: Moving forward with the stuff that needs to happen with pyCRTM, shall we just create some Zenhub issues?

Ben: Absolutely that would be fantastic if you can create some Zenhub issues and include me and Patrick. Right now we are relying on my script to make it work in the bundle.

Bryan: That isn’t too far away.

Daniel: So I have one question: I am trying build fv3-bundle, so I need some bundles on Hera but they’re not available. Is someone able to build it on a laptop.

Ben: Yes, you should be following the fv3 container instructions for the laptop. For Hera you should talk to Dan Holdaway. Or Rahoul because I don’t know about that. So, Daniel we are talking to Oak Ridge about doing some GPU related development and once we decide how to move forward I will bring you in.

Result:

Daniel has trouble compiling the fv3-jedi modules

Tasks:

-       Contact Dan Holdaway and Rahoul for instructions on how to compile fv3-jedi on Hera.

-       Create Zenhub issues for pyCRTM

Responsible People:

Bryan Karpowicz, Daniel Abdi

Deadline:

Next technical meeting