2021-03-08

Ben: Hongli do you want to start on the aerosols?

Hongli: I have a few slides, can I present?

Ben: Sure.

Hongli: (shows slides) Recently I calculated CRTM AOD with CMAQ aerosols and the AOD is very low. Mark mentioned that CMAQ was designed for dry mass AOD. Here the first shows the mass extinction coefficient for dust, insoluble and soluble and the three black dots are the modes.

I am introducing the mass coefficient in the reconstruction method. For the sea salt they have another scaling factor from the environmental relative humidity. Here is the same plot again, but with the mass coefficient from the reconstruction method. For the dust the value will be 1000, except for the soil and coarse mode. If we look at the values in the CMAQ LUT it seems that it gives a lot of weight to the G-mode, which makes much sense since it’s close to 500nm.  In the reconstruction method the value is 10000, which is much larger. I will show you the scattering in a minute. For the sea salt it’s a function of the relative humidity and the maximum can be close to ten. In the red curve the maximum can be 20, so this can be a huge difference in the water-soluble cases. In the netCDF file it’s easy to revise the value of the mass extinction coefficient. So, for this value I set the mass extinction value to a constant. So I consider the values as scalar. Here is a PM2.5 example with the current model. It still under-predicts the PM2.5. On the left is the observation and on the right it’s the model simulation. Here is the VIIRS AOD on the left. On the right is the reconstruction mass coefficient AOD. This time the value is 0.0179 and the pattern is closer to observation. In my mind the first reason is that the CMAQ is not designed for the dry mass. The other reason is, even if we use the current coefficients from the reconstruction method we give the same weight to the k-mode. Currently if we give less weight to the k-mode this is reasonable.

Cheng: Thank you Hong Li, what did you mean by k-mode?

Hongli: Ok, because we are currently looking at 500nm AOD, for the k-mode the particle size is much larger than that. For the value for the CMAQ LUT the k-mode is about 550nm, which is much closer to 500, so it gives much weight to the k-mode. For this part the relative weighting for the I,j,k-mode is correct, just the amplitude depends on the relative humidity, does this make sense?

Cheng: So, by giving more weight to the j-mode the aerosols have more mass weight? So, from the CMAQ table the aerosol mass concentration is highest in the k-mode.

Hongli: If we use the reconstruction method it will give the same weight to the three modes but the value is dominated by the k-mode.

Yingtao: Hongli, what are you going to do with the next experiment, are you still going to use the CMAQ-CRTM?

Hongli: At least in the current state it is not suitable for the AOD assimilation. The reconstruction method is my plan B. Cheng is working on NASA-GOES, where relative humidity is also considered. We might prefer that then.

Cheng: I guess you can try the code I sent you earlier.

Yingtao: What about GOCART LUT?

Cheng: Hongli may want to add, but I think it’s still too low.

Hongli: The mass value is about 1.2, so it’s still too low.

When I saw the GSI code there is an additional step to include the particle humidity I haven’t used yet. That might be a reason. But if I need to consider the radius I need to understand the logic. That might be a way to improve that. The NASA table from Cheng is more straightforward.

Yingtao: So, Cheng, you are going to create a new LUT based on NASA GOCART?

Cheng: Technically I didn’t create new LUTs, I just merged them into the existing LUT.

Yingtao: What is that table designed for?

Cheng: It’s used in AOD assimilation.

Hongli: So, Mariusz is using that table for the global AOD assimilation in GOES-CHEM.

Yingtao: That table is also giving parameters?

Cheng: Yes, we can specifiy size, relative humidity etc. .

Yingtao: Once you implement that table in the CRTM you need to modify the CRTM code because it doesn’t include humidity.

Cheng: Yeah, that’s done.

Hongli: Cheng just shared the table this morning and I will keep you updated. Thanks Cheng and Yingtao for your help. That’s all we have today?

Ben: Thanks for covering that. My concern is that we should probably get back to basics with these tables because you can play a lot of games. None of the tables I have seen so far are not that good at simulating AOD. At this end we probably have to go to science teams and check which assumptions they make and see if there are any commonalities in the methods they use. How can we build tables that capture the essential physics but still cover the range of variability that we see.

Hongli: I see your point. We come from a specific project though.

Yingtao: We can probably not get a universal LUT for all cases. Maybe we can get aerosol cases for instruments specifically. Maybe we can treat the aerosols similarly. Each user can develop an aerosol scattering module. We have a special CMAQ table. For other schemes we can create a LUT for that. Creating a universal LUT has been tried for many years and there was no success.

Ben: You might want to have a consistent physical basis.

Yingtao: No, not for sensors. We just treat each aerosol scheme separately.

Ben: We want to have a way to select the things that we need in the DA setting.

Yingtao: We shouldn’t have one universal table, but focus on models, such as GOCART and CMAQ.

Cheng: Yingao, I agree, but are we doing that already?

Yingtao: For GOCART we have 5 categories and CMAQ 8 categories. But if we drop this generality requirement there could be 50 categories for CMAQ.

Cheng: Yes, but aren’t we doing that already? We can create more specific tables for specific tables. But I agree with you there’s no universal table.

Ben: I think Cheng is going to continue on this effort to make sure that we are doing the physics right and that we evaluate this effort on its own to compare apples to apples. This will carry over to AOP2021 to understand the impact of these tables and to make sure we can use these in DA in a way that makes sense. This work is becoming less and less reliant on one table. netCDF is going a long way in helping us do that. That’s the only piece we want to understand. How much time overhead are we adding to the process. Maybe someone wants to comment on that?

Yingtao: You mean the time impact from netCDF?

Ben: Yes.

Yingtao: But these coefficients are read only once, right?

Ben: Not in GSI. It’s loading the CRTM for each instrument, so it’s loaded millions of times. Haixia?

Haixia: I’m using the binary with default settings.

Yingtao: netCDF actually supports parallel I/O?

Ben: Yeah, it wouldn’t help in the case of GSI because of the way the CRTM is called.

Haixia: Ben, can I talk about the comparison between version 2.3 and 2.4? 

Ben: Yes, absolutely.

Haixia: I will show the slides. Can you see my screen? Our current operational is using CRTM v2.3 and Ben has prepared CRTM v2.4 for us to test with O-minus-F. This is an AMSU-A near surface channel in v2.3 and v.2.4. It’s hard to see the difference but the mean is less negative for v2.4.

Ben: Did you keep the number of Obs the same?

Haixia: I didn’t apply any quality control, the data points are the same. The bias correction and QC impact each other. The number is a lot different between v2.3 and v2.4 because the bias correction I use are coming from the operational one using v2.3, so the bias correction is not suitable for v2.4. This is the horizontal map, I will flip back and forth. V2.4 is a little bit colder. This is expected because in v2.3 in the case of cloud fraction e-6 you consider that as overcast, so you get a warmer BT. But in v2.4 we are considering that as clearsky, so the BT is colder. It’s hard to see the difference between the two versions here. The main difference I see is over the ocean if the cloud fraction is smaller than 10^-6. So, I plotted total cloud cover with averaged overlapping method. I just try to match this plot with this one. That was my original idea, but it’s difficult to see so I made this histogram plot to see whether the BT difference is distributed near zero, but it’s not. It’s distributed evenly from zero to one. I tried to explain it but so far, I have no idea.

Ben: One thing I’ve seen from GSI is that sometimes it doesn’t assign a cloud fraction when one is present.

Haixia: No, it provides a cloud fraction profile over ocean. We are only doing allsky over ocean.

Quanhua: Looks like you are seeing only differences over ocean. Do you check both v2.3 and v2.4 with the same FASTEM model?

Haixia: I didn’t change that. It should use the same.

Ming: You probably should check with Emily. She made some changes. I don’t know if this is the same code.

Haixia: This is related to the reflection correction?

Ming: Yes, sometimes it’s in one place and sometimes in other place.

Quanhua: You only have this difference over the ocean so it must come from the surface module.

Hiaxia: Yes, but we are only doing allsky over the ocean.

Quanhua: Ah, ok.

Ming: Let’s assume only clearsky? It’s very easy to check. Every component is the same except cloud fraction. A problem with the regression coefficients is one possible issue.

Haixia: So, I can run clearsky cases. For ATMS you see different things. It’s similar to AMSU-A over ocean, but over snow it shows this large negative difference in this map and this histogram shows large negative values. The median value is actually -100.

Ming: Ben already changed something for v2.4. What they have for ATMS is more of a science code. I think in the CSEM the checking of input quality is unified.

Ben: The only comment I have for Haixia is to check the quality flags.

Haixia: I am not considering any quality flags yet.

Ben: Ming is getting to the point that if the instrument ATMS is missing one of the 5 channels it fails one of the emissivity tests. If you look at the QC flags some channels might be missing.

Ming: Ben, I found that you have 2 versions you have this change for the CRTM-JEDI version it included this kind of check.

Ben: There was a gross check not to include bad channels. In CRTM-JEDI it’s a more comprehensive check.

Ming: Haixia, are you testing directly on Hera. I can probably make some check.

Haixia: Ok, great.

Ben: Haixia, one other thing, can you test turning OMP on?

Haixia: It doesn’t matter whether it’s netCDF or binary?

Ben: For v2.4 can you check OMP first, and then you might want to go to the netCDF from binary. There shouldn’t be a big impact for OMP.

Haixia: Do you have an account on Hera?

Ben: No, but we can have a separate tag-up.

Haixia: Ok, I need to do the homework before we can tag up, how to run the netCDF.

Ben: It’s easy to do.

Haixia: Ok, we can talk about this another time.

Yingtao: Ben, I have a question about the cloud coefficients in v2.4. One of them is Thompson-A, what is that?

Ben: Those are the coefficients from Penn-State. They matched the effective radius with Thompson-Microphysics. They’re experimental.

Yingtao: And GFDL?

Ben: It’s the same, also from Penn State.

Yingtao: There’s also the WMS-6.

Ben: Scott can tell you all about this too. Scott do you have a document on how those tables were created?

Scott: Ah, no.

Ben: Ok.

Yingtao: All three from PSU?

Haixia: Ben can you also explain what I should expect to see in terms of the difference?

Ben: In terms of output?

Haixia: Yes, for all the changes you made.

Ben: Ok, so one would be the reflection correction change in cloudy regions. I don’t believe any changes were made that would impact clearsky. Any change would be in MW. The other thing would be … off the top of my head I can’t give you a full list. Some changes affect the cloud fraction. You might also check the Jacobians, for the surface and clouds in particular.

In my test I don’t see any differences.

Quanhua: Haixia, one question, in the past for v2.3 when the cloud fraction is less than 10^-6 is still treated as cloud or clearsky.

Haixia: In operations there is no cloud fraction, but in v2.4 if the cloud fraction is 0 and it is overcast, the pixel will be clearsky.

Ben: So it behaves like you would expect. That way you can force cloud fraction.

Quanhua: Just trying to understand, in the v2.3 even if the cloud fraction is zero but if you have cloud water content it will be treated as overcast, but in v2.4 it will be clearsky?

Ben, Haixia: Yeah.

Ben: It will only affect a few pixels. There was a bug in v2.3 if the cloud fraction was less than 10^-6 it would set the pixel to one.

Quanhua: In v2.3 the cloud fraction is optional. Is it mandatory input now?

Ben: No, it defaults to one. If you don’t specify cloud fraction it defaults to one for backwards compatibility.

Quanhua: That may cause some differences.

Haixia: Yeah, that was the point of my plot.

Ben: On that scatterplot Haixia, there are two values, one is very small and there are two vertical lines.

Haixia: I saw those two vertical lines, but I don’t understand them.

Ben: Alright, anything else?