Fig 2 Comments

[NidhiVinod]

Refree 1

[NidhiVinod]

Refree 2

[NidhiVinod]

[teixeirak]

This all seems pretty straightforward (something for you to coordinate with @mcgregorian1), but let me know if you run into questions.

[mcgregorian1]

Hi @NidhiVinod when would you like this to be done? I can definitely dedicate time next weekend but if need be I can get to this during the week.

[teixeirak]

@mcgregorian1 , the paper is due back 2/14 (if we don't request an extension), so it doesn't have to happen this week.

[mcgregorian1]

@teixeirak some questions on this:

• Referee 1: what do they mean by "homogenize the units"?
• Referee 2: I want to make sure I'm understanding their intention here; are they saying to make the figure as I had on 20 Feb last year (see here)?

[teixeirak]

• Referee 1: what do they mean by "homogenize the units"?

That's simple-- they're just pointing out that panel (a) has x-axis units in parentheses whereas other panels have brackets.

Ref 1 also asks for homogenization of figure style. I don't think that's super critical, but I mentioned it as something for @NidhiVinod to think about in issue #97.

[teixeirak]

• Referee 2: I want to make sure I'm understanding their intention here; are they saying to make the figure as I had on 20 Feb last year (see here)?

Yes, my interpretation is that the reviewer wants to see units normalized as in this older version of the figure (pasting here for reference):

Also for reference, here's the figure with raw heights on the y-axis (currently used in the paper):

That was our original instinct, and I think it's good in many ways, but I'm concerned that the canopy heights from @m-n-smith's analysis don't seem to match well with what we expect at the tower. That is, some sites (OSBS and HARV) have 3 measurement points above the canopy, and my understanding was that there should just be one or maybe two. We don't necessarily expect perfect alignment of canopy height at the tower with the LiDAR cells, so maybe this is part of the issue? Perhaps Marielle can comment too? In any case, normalization emphasizes that issue, and potentially introduces error that doesn't have to be there. I'd see three options:

1- If we check the work and find a fix that resolves this discrepancy (e.g., if there was some error), we could normalize as in that earlier figure (and as requested by R2). What value from Marielle were you using? Comparing the figure in the paper with the one above, it looks like SCBI is getting normalized to height =20m for the micromet data, whereas Marielle's figure shows it going up to ~45m.

2- Alternatively, and arguably more appropriately (because LiDAR height not identical to tower heights), we could use the vegetation height provided by NEON in this file (DistZaxsCnpy field). But no guarantee that would be any better. At SCBI, for example, the height given is 30. That's matches Marielle's analysis if you define this as the height at which canopy is most dense, but then it goes up to >40m.

3- If we can't get a normalization that seems right, we can just push back on this reviewer comment, e.g., : "We tried normalizing as suggested, but preferred to keep the axes in raw units because (1) it is more straightforward to interpret, and (2) canopy height is not precisely quantified at each tower (rather, the LiDAR analysis covers a broader area), and therefore normalizing would introduce some error."

@NidhiVinod should also give her opinion on this.

[NidhiVinod]

Normalizing to figure 1 here makes sense in terms of what the reviewer is asking, I think, but I also see the problem with the discrepancy between tower and lidar height. If it doesn't work to normalize it, then we could do 3) and show the normalized height figure?

• Referee 1: what do they mean by "homogenize the units"?

That's simple-- they're just pointing out that panel (a) has x-axis units in parentheses whereas other panels have brackets.

Ref 1 also asks for homogenization of figure style. I don't think that's super critical, but I mentioned it as something for @NidhiVinod to think about in issue #97.

I looked at figure guidelines, and I could try to homogenize the style a little but the review guidlines say that the figures will be finalized by a professional illustrator, and the color schemes will be changed to match Tansley Review's style. So even if I tried, I think this will be eventually changed to match their style.

[teixeirak]

I wouldn't worry about the color schemes and such. Just be consistent in putting units in () or [].

[mcgregorian1]

Ok, so the units are now consistent using [].

1- If we check the work and find a fix that resolves this discrepancy (e.g., if there was some error), we could normalize as in that earlier figure (and as requested by R2). What value from Marielle were you using? Comparing the figure in the paper with the one above, it looks like SCBI is getting normalized to height =20m for the micromet data, whereas Marielle's figure shows it going up to ~45m.

I was using the height data from Marielle's lidar data (Rdata file lad_n_light_profs_for_ian_v1). Looking back at that initial figure, I think the SCBI measurement was a calculation error, especially as based on the value we're using for canopy (43m), we now only reach ~0.87 of that value (see the figure below).

2- Alternatively, and arguably more appropriately (because LiDAR height not identical to tower heights), we could use the vegetation height provided by NEON in this file (DistZaxsCnpy field). But no guarantee that would be any better. At SCBI, for example, the height given is 30. That's matches Marielle's analysis if you define this as the height at which canopy is most dense, but then it goes up to >40m.

Right, I'd agree with you there.

3- If we can't get a normalization that seems right, we can just push back on this reviewer comment, e.g., : "We tried normalizing as suggested, but preferred to keep the axes in raw units because (1) it is more straightforward to interpret, and (2) canopy height is not precisely quantified at each tower (rather, the LiDAR analysis covers a broader area), and therefore normalizing would introduce some error."

In redoing the code, there were a couple things I had taken notes on.

• initially we had decided to do delta(var) measurements, where instead of plotting the raw values we did delta(var) = var at height h minus var at minimum height. We decided to change this in Feb 2021 and use only the raw values.
• separately we were doing the normalization. We decided to change this in Feb/March 2021

From all this, here's what the plots look like with raw values and normalized height from Marielle's values. In addition, the units are homogenized and the lines are thicker per the other reviewer comments. Three thoughts:

1. I have not included the horizontal dotted line at y=1 yet. That's easy to add, just wanted to see what our overall thoughts on this were first.
2. I had the y-axis extend to 1.75 primarily due to RH and PAR, but I note that when we first normalized things, we kept the Lidar data (plots ABC) to a separate y-axis limit of 1 because plots A and C converge pretty quickly above 1.
3. The thicker lines almost make this too jumbled to me, but maybe that's just me.

[teixeirak]

Thanks, this looks great! I think the normalized version is nice. A few points:

1- I think the thicker lines are fine, but the thick lines on the error bars make things jumbled. Can you fix that?

2- In some panels (especially apparent in G and H, but also in D and maybe E), the lines for some plots do not connect in order of height, but rather double back (e.g., OSBS in D, H). This is probably because the code is connecting data as ordered in the data matrix, and they are not always in order of height. Fixing this will also help to make things look less jumbled.

3- a dotted line at 1 sounds good.

4- increasing font size on axes (tick labels and axis labels) would help

[mcgregorian1]

2- In some panels (especially apparent in G and H, but also in D and maybe E), the lines for some plots do not connect in order of height, but rather double back (e.g., OSBS in D, H). This is probably because the code is connecting data as ordered in the data matrix, and they are not always in order of height. Fixing this will also help to make things look less jumbled.

Sorry about that - difference between geom_line and geom_path in ggplot.

Here's the updated figure. Only remaining hiccup is the font size - currently the axis titles are 14 while the ticks are 16. Personally I prefer having both be 16 but we'll need to change Plots A and B. Thoughts on abbreviation? I could do "Modelled LAD" for plot A to shorten it, though I'm not sure how you'd like to abbreviate B.

[teixeirak]

Looks fantastic! Thank you, @mcgregorian1.

Let's go with this as is-- don't worry about the slight difference in font size. I expect they'll tweak these anyway.

[teixeirak]

I think we can close this.

[teixeirak]

@mcgregorian1 , reopening this issue because there's one minor change needed here: the y-axis needs to be changed from "Height [m]" to "Height normalized to top of canopy" or just "Normalized height".

[NidhiVinod]

@teixeirak@si.edu @mcgregorian93@gmail.com, adding Marielle's comment below from the word document: The revised figure looks great! My apologies for not pitching in sooner, but I think we should use the x axis title as follows: "Leaf area density", "Estimated proportion of sun leaves", and "Proportion of incident light". Lidar derived metrics are just as measured as the micrometeorological variables (which also involve some level of modelling and proxy measurements), so I think it's best to add a sentence to the legend that just explains that some panels are lidar derived while others come from micromet. data (see what you think of the one I've drafted). It could be worth adding a bit more on how the proportion of sun leaves were calculated (since this is the only lidar-derived variable that is more heavily estimated and has some more assumptions, eg associated with our definition of where sun leaves are likely to be found). Let me know if that sounds good and I can add a sentence on that to the legend.

[teixeirak]

Makes sense to me.

I'm flagging @mcgregorian1 again because I'm not sure if the email addresses work. (Do they? If so, that's new to me. I did get the notification.)

[mcgregorian1]

Yes! Sorry, I haven't responded because I was planning to go over this on the weekend

On Fri, Feb 11, 2022 at 10:20 AM Kristina Anderson-Teixeira < @.***> wrote:

Makes sense to me.

I'm flagging @mcgregorian1 https://github.com/mcgregorian1 again because I'm not sure if the email addresses work. (Do they? If so, that's new to me. I did get the notification.)

— Reply to this email directly, view it on GitHub https://github.com/EcoClimLab/vertical-thermal-review/issues/83#issuecomment-1036324860, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJNRBELCD7W77T3LOGTRF4TU2USL7ANCNFSM5LIKKQWA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

--

Ian McGregor

Ph.D. Candidate | Center for Geospatial Analytics

He/Him/His

College of Natural Resources

Jordan Hall 5111 | Campus Box 7106

North Carolina State University

2800 Faucette Dr.

Raleigh, NC 27695 USA @.*** | geospatial.ncsu.edu

[mcgregorian1]

I've updated the axis labels. For the final thing, Krista, do you prefer the axis label to be "Est. proportion of sun leaves" and then have that be explained in the legend, or to have the font size of all axis titles be slightly smaller?

This is the only one of the plots that has an issue with size currently.

[teixeirak]

Thanks-- looks great! But see the comment from @m-n-smith that Nidhi posted above-- seems we should just drop the word "estimated". That solves the font size issue too.

[teixeirak]

Oops, looking back I see that she recommended "estimated proportion sun leaves". So let's go with "Est. ..."

[mcgregorian1]

Sounds good! Here's what the figure now looks like, and it is updated on GitHub.

[teixeirak]

Looks great; thanks!

[teixeirak]

This can be closed.