2021-03-22

Agenda Item 1:

Direct Update from Ming

Discussion:

Ben: Why don’t we go around the room. Let’s start with Ming.

Ming: …

Ben: Ming we can hear you now.

Ming: I think Haixia is doing good work. You did some testing already now and see differences?

Nick: Yes, he’s noticing differences, which is what we want. But not the differences we want to see. But at least things are reasonable.

Ben: Ming is having technical issues.

Result:

N/A

Tasks:

N/A

Responsible People:

N/A

Deadline:

N/A

Agenda Item 2:

Update from Yingtao:

Discussion:

Ben: Yingtao, we are looking for the CrIS non-LTE work.

Yingtao: Yes, I am working on getting my code on the repository. I was looking for the coefficient but it is not in the repository.

Ben: Yes, at some point we were told not to use git-lfs.

Just keep it in the CRTM_dev repository in a fix directory.

Yingtao: Yes, I will do that. In the future you will still use LFS?

Ben: Yes, release branches and a tarball will also be updated for non-github users.

Yingtao: If we use LFS approach, can I make a subset of coefficients?

Ben: Yes, it’s possible but I don’t know if it’s possible.

Yingtao: If I just want to do a simple test of the CRTM they don’t want to download all the data. Another question for Haixia, what is the default CrIS coefficients you are using in GSI?

Haixia: Full resolution.

Yingtao: So, I don’t need to generate all of them, just the full resolution.

Ben: Yeah, so we will need a way to generate these coefficients with the NLTE corrections. The priority are the operational coefficients.

Haixia: This will be included in the 2.4.1 release?

Ben: I don’t know yet.

Yingtao: When will you release 2.4.1?

Ben: My current plan is end of April. My goal is to have a final release for AOP2020. That would be new aerosol, and NLTE coefficients, new physics-consistency.

Result:

N/A

Tasks:

N/A

Responsible People:

N/A

Deadline:

N/A

Agenda Item 3:

Update from Nick

Discussion:

Ben: Ok, Nick?

Nick: What I’ve done is creating an updated set of LUTs that utilize merged refractive indices. I’ve used the new set published by Row et al. . They’re for supercooled water. The highest temperature they have is 273K for cloud droplets. All I have done is merging data between 273K and 289K. I tweaked the minimization schemes. We have two different wave slopes and 8 different indices. I have handed them over to Ming Chen, but since they’re so many we want to reduce them. The third one is the Newman data, which was derived from the field in the long wave IR window. Ming has that as well. The Newman data is different from the other datasets. Jim Yung has already begun to look at the transition between temperature dependent and independent regime. These Newman data show a bit more difference. If Jim finds something favorable, we can merge these datasets. The issue is that all we had to merge previously is the temperature dimension, now we have the spectral dimension as well. I don’t want a set of data with a discontinuity in there. The Newman data is used by RTTOV. I asked Stuart Newman what they are doing about the shortwave and they are just doing sort of a ramp-up.

Ben: The index of refraction is what exactly?

Nick: Right, basically the refractive index and the absorption.

Ben: So in simulations you have to account for the surface that is convolved with the optical constants. So what is the

Nick: I think what you are asking is the influence of the wave slopes on the emissivity? That’s just adding these additional dimensions in the emissivity. The refractive index is just applied to flat surfaces. The roughness factor is the same for all of these. I’m using the same wave slope probabilities for all. I like to be aligned with RTTOV but I don’t like to do everything exactly the same. They’re using Cox-Munk and the Newman dataset and they seem to have success with that.

Ben: I’m just thinking about validation.

Ming: Nick, your model, physical model has two dimensions from ocean observations?

Nick: No, no empirical tuning, it’s empirical validation.

Ming: If you have a different downwelling situation, how do you do the validation?

Nick: If you talk about the Merry instruments on ship it’s measuring the upwelling radiation from the ocean and the downwelling radiation. That’s so nice about the CRTM is coming from the same source. The bottom line is, an approximation for the reflectance has to be employed in a fast model because the full BRDF is too much. To calculate your downwelling in this within a fast model doesn’t work. In SARTA they do a Lambertian approximation. In CRTM it’s always been a specular approximation. This emissivity model increases the emissivity a bit to account for this approximation.

Ming: <unintelligible> I think that Mark told me that the results in RTTOV were not better in our current <?> about 5 years ago. Probably there’s some other issue with the GSI. It’s hard. The fundamental thing is that if you believe your science is good then the other part needs to change. Certainly, the real part can be changed but the imaginary absorption part is mostly correct. I think that Patrick also has some experience with KK. When I try to apply to the thermal band I just calculate the absorption from the canopy and then calculate the real part. We apply to the GSI a lot of things we need to consider.

Nick: Obviously it gets more complicated when you add more pieces to the RT puzzle. That’s why it’s always better to … the Wu-Smith model exist because we observed with Merry that the Msudo<?> model didn’t capture the physics. What I have is the next step beyond that to treat the surface emissivity consistently for a fast model. What you said about the optical constants is a limitation right now. I’m working with what I have. We’ve merged some older and more recent data and we had to interpolate. It would be good if we had a new set of optical constants

Ming: Normally since you are working with the canopy.

Ben: That’s what we are doing for fundamental constants in the transmittance. I think something would be better than nothing.

Discussion summary: Nick, Ming and Patrick are discussing about Kramers-Kronig analysis and application to water. Ben mentions the next ITSC meeting.

Bryan: They kind of announced it, but no official announcement.

Ben: Four days ago, there was a feedback on topics for the chairs. The other pieces are how do we know when we do things right. We also need to come up with a plan how to do that. O-minus-B is not bad, but there are a lot of issues that occur beyond this step.

Result:

N/A

Tasks:

N/A

Responsible People:

N/A

Deadline:

N/A

Agenda Item 4:

Discussion of Differences between v2.3 and v2.4

Discussion:

Ben: Haixia, you have been working on identifying the differences you have been seeing between 2.3 and 2.4. So Ming Chen has been helping me with that.

Haixia: Last thing I did was a clearsky test. I got identical simulated brightness temperatures. The differences only happen in the all-sky cases. ATMS has additional problems over snow, maybe from the emissivity model,

Ming: There is something in testing we have to discuss between v2.4 and v2.3. The difference is not important, just should we have this difference or not. Ben can I share the slides?

Ben: Go ahead.

Haixia: I just want to answer Yingtao’s question. There are several different sets of coefficients in the fix directory. Can someone explain to me the difference?

Yingtao: 2031 is the selected channels, selected by Andrew. 399 is not full resolution, it is convolved version. There are two full resolution sets. I don’t know what the current GSI default is.

Haixia: I put in the 2211 version.

Yingtao: That’s the full resolution version. You’re not using all?

Haixia: No. There’s another set called 374.

Yingtao: That’s the first selection by Andrew. It’s old. Now I know which one you are using.

Ben: Let’s focus on FSR with NLTE correction. We’ll have to look at the bands.

Yingtao: Band 2 is water vapor, band 3 is shortwave. Band 1 is longwave. For CrIS we just combine it into a single coefficient file.

Ben: So, it sounds like the problem is related to clouds.

Haixia: It came down to two lines in the CRTM K-matrix module. When the cloud content could be zero or the cloud fraction is zero then I get identical results.

Ben: I think these are important results. I think we have to think about whether the decision to zero out the cloud fraction was good.

Haixia: Right now, I don’t care whether it was good or not. I just try to figure out the differences.

Ben: Thank you.

Ming: Should I talk about the details? Ok, I’m not sure how to show these results.

<shows slides>

I spent the last two weeks testing many designs and in summary let’s have the conclusion first. In the boundary condition lines basically, one should expect this difference between 2.3 and 2.4 and this kind of change, I need to ask Ben who made this change and why. For me it’s very important with the CRTM every change needs to have some reason. I checked the documentation who made this change and what I tried to figure out how this change impacts the cloud cover. I will explain all the details. I want to get confirmation from Ben, who has a reason to make this change?

Ben: Yes, we had a long discussion about this issue. What happens if the cloud fraction goes to zero?

Ming: I didn’t see any trace in the documentation what we can expect with this change. For instance, you need to change some data structures to INOUT, which is not good. If you think this is necessary, we can keep this. The other thing is, it hasn’t been tested with the profile-based OpenMP. I will show for the snow I already have the solution. Mark Liu thought it’s probably the surface model.

Ben: We’re running pretty short on time, do you want to discuss it at the next technical meeting?

Ming: I just want to go over this quickly to discuss physics and fixes in the next meeting. Probably I can send you the slides later. In conclusion, is there anything wrong in the snow module? – No. The surface related code is ok. In OMP parallel region in the cloud validity check, if I remove these lines we can get identical results between 2.3 and 2.4

Haixia: Actually, I tried, only the last two lines matter.

Ming: Actually, no matter which cloud fraction you chose, it’s the same. This part is where we make the change and we need to explain why we make this change. There are three reasons why this part with OpenMP leads to different results. You have a nested loop here. Why will this cause the problem. If the nested loop is not private, then we will randomly assign this value. In any case, this part related to OpenMP with cloud fraction and if you set the effective radius to zero in the LUT, we have no reason to believe that the interpolation will give a reasonable value. These two are from my communication with Haixia. I have experience with cloud cover with Paul at the time. So, I think I had a misconception about nested loops. I thought first it’s shared, but for Fortran it’s private. But in any case, Haixia did a very good job to uncover this cloud cover difference. I designed another experiment this weekend. After we got this experiment done I confirm every assumption. Let me explain why this is very important. This is the water content threshold, not in the cloud fraction. In this case the cloud fraction is zero, the key point is the water content couldn’t be larger than this value. This means that <unintelligible>. The denominator becomes less than in v2.3. So we expect a larger cloud cover in v2.4.

Haixia: I didn’t understand yet.

Ming: Remember two things: One is, can you check when the cloud fraction is near zero, can you see any water content larger than this threshold? You had a lot of these cases. This part will only contribute to the denominator.

Haixia: When the cloud fraction is zero in 2.4, everything will be set to zero.

Ming: In the beginning I already noticed, Ben knows this, I told Paul this is hard. That’s why if you change this part you will have problems. <unintelligible>.

Ben: Here are the issues. People were trying to clear clouds by setting the cloud fraction to zero. The second part was that I talked to Allen Gear about it and he agreed that having a smooth decrease of the cloud fraction to zero should also lead to a smooth decrease of the content. We tested this thoroughly and I convinced myself that this was the right way to go. The OpenMP part, I could have told you that early on. You should include me earlier in this discussion.

Ming: I agree, there’s nothing wrong. I just want to confirm. This one is what Haixia did yesterday. This is total cloud cover. You can see that we have 1.0 cloud cover.

Ben: I can understand where that comes from. In the cases where the cloud cover is modified, is the water content zero? That was part of the solution.

Ming: Even if you have some cloud fraction, you have some water content. I have some thoughts to improve this one.

Ben: Let’s have a more detailed discussion, but thank you for raising this issue.

Ming: The last one is over water we need to expect a higher TB. The cloud normally has a higher temperature than the cloud. The blue line is clear. When we add the water cloud you can see that normally over lower channels the TB becomes larger.

Haixia: All the TBs I plotted is for the surface channels.

Ming: Having larger cloud cover but lower TB is contradictive to the RTSolution. So, I think we need to work through many issues.

Ben: I’ll set up a separate meeting where we can go through the code in detail. I think the main point is to make sure that when the cloud fraction is zero, that removes the cloud contribution from the radiance. In the case where the cloud fraction is zero, we just return the clearsky solution. We can also agree that as the cloud fraction nears zero, the radiances should approach the clearsky solution.

Ming: If you want to work together I think I have experience in GFS.

Ben: Alright, let’s go through it and take some time.

Haixia: Can you include me when you talk about this.

Ben: Yes, Thanks everybody for hanging out so long.

Bryan: Just a quick update, I fixed everything that was wrong with the pyCRTM before, installer, OpenMPI. It makes it possible to install it as a pip meeting.

Haixia: Ben, what’s the status of the antenna correction coefficients?

Ben: I haven’t had time yet because of the management issues. When do you need it?

Haixia: Soon.

Ben: Ok, either I or Patrick will have a look at it.

Result:

N/A

Tasks:

N/A

Responsible People:

N/A

Deadline:

N/A