Data question

[mcgregorian1]

Hi @teixeirak

I was asking Valentine about adding in the ring-width figure like in Ryan's paper, and she commented that it seems I'm only using the raw data, not detrended core data from Neil.

I realize what's happened is that in sending back the detrended cores, Neil put them in a folder like in dropbox (Dropbox/Tree Cores/cores_by_canopy_position/canopy_cores/CACO for example). I thought that the rwl file in the top of the CACO folder was itself a detrended and processed file, and I've been using that. I didn't realize that the actual processed files are in the ARSTANcrns folder.

However, the methodology I've been using for getting the resistance value was what was used by Lloret et al 2011, where they specifically used the raw rwl files in order to calculate resistance values / other resilience metrics.

I'm pretty sure what I've been doing is ok, especially as I've been following the same methodology. But I wanted to check with you since I've only now just realized I've never been using the processed ARSTAN files from the start.

[ValentineHerr]

(FYI, I pushed the figure here and the script here, feel free to edit as needed)

[teixeirak]

@mcgregorian1, I'm a bit confused by your comment. We do want raw data. However, the chronologies, which are based off detrended cores, give a good picture of how each species responded.

[teixeirak]

Regarding the figure, a couple things I'd change: 1- Restrict date range to 1959-2009. This will help to focus attention on the study periods 2- switch from dashed lines to shading to indicate droughts (if possible). If not, include a dashed line for each control year. It's currently confusing.

[mcgregorian1]

@mcgregorian1, I'm a bit confused by your comment. We do want raw data. However, the chronologies, which are based off detrended cores, give a good picture of how each species responded.

@teixeirak what I meant to say is that for my analysis, my only inputs are the raw rwl files, which are labeled as chronologies but are not detrended. I haven't used any output from ARSTAN

[teixeirak]

Right. But its the same set of cores, correct?

[mcgregorian1]

It's the same set of cores I originally sent to Neil to be detrended

[teixeirak]

Please remind me how that related to Ryan's full set. It excluded species-canopy position categories with small sample size, correct? Did it also exclude some for which we didn't know canopy position? Now that we're doing an individual-level analysis, it would be preferable to just use Ryan's full set (or at least include the rare species-canopy position combinations, as we previously discussed), if making that change wouldn't throw things off for you.

[mcgregorian1]

It took me longer than I thought to remember the process used for choosing cores, but now I've more fully documented it here. I will say that even with us making sure that the tree_cores repo in ForestGEO-Data would be the master, I still found myself very confused by the the Tree Cores dropbox, and the climate sensitivity cores folder with its data (thankfully I had done some documentation from before).

Following from the updated README linked above, in my actual code we decided to not use cores for frni and caco due to small sample sizes (n<5) in either canopy position. I've already been re-including the subcanopy cores after our discussion, but I can add in the canopy cores.

I think I've addressed your question, but let me know if this still needs clarity.

[mcgregorian1]

Ah, ok I've tried re-running the code and I remember why we took this out. In calculating the pointer years, we determined our own threshold of there needing to be at least 5 cores per species x canopy position in order to not have skewed pointer years.

For resistance metrics, we can get them having only 2 cores, which is what we have for only caco canopy. For the others (frni and cato canopy), there must be more than 1 core for the R function to work and calculate metrics, which means by default we can't use those anyways.

In other words,

• originally missing: caco canopy/subcanopy, frni canopy/subcanopy, cato canopy
• what I can add in: caco canopy/subcanopy, frni subcanopy

[teixeirak]

We already have identified the pointer years. The code identifies those based on the full set of cores included, and therefore is sensitive to which cores are included, but it calculates resistance at an individual level. Thus, you can go ahead and include the singleton cores in with any other set to get their resistance metrics and be able to include them.

[mcgregorian1]

Ah you mean paste the ring width values from frni canopy into the frni subcanopy file to get the resistance values? I remember us discussing that.

Of course, cato canopy will not be included because we have no cato canopy cores.

[teixeirak]

Yes. The canopy / subcanopy groupings are now defunct anyway (since we're using the 4 categories).

[mcgregorian1]

Ah I see what you mean. Yes, you're right, I had just kept things in the code different before binding it all together to do the resistance metric analyses, so I confused myself.

In any case, I've now included that one final frni canopy core for the analysis

[ValentineHerr]

Regarding the figure, a couple things I'd change: 1- Restrict date range to 1959-2009. This will help to focus attention on the study periods 2- switch from dashed lines to shading to indicate droughts (if possible). If not, include a dashed line for each control year. It's currently confusing.

I updated figure by restricting the date range and added shading to indicate 5-year period before drought year. I left a dashed line for the control year. I can remove it easily if you don't like it @teixeirak.

[teixeirak]

That looks fantastic, except: (1) the 1960's drought includes 3 years of drought (1964-66, I believe, even though 1966 was the strongest). @mcgregorian1, please verify. This means we'll need to shade the drought periods as well. (2) @mcgregorian1 and I discussed whether to eliminate FRNI, and I believe we decided we should because its not part of the top 12 most productive species for which we have leaf trait data, but we can go either way. I'll let @mcgregorian1 make the call on that. I'd lean towards excluding it, but either way is fine. This relates to issue #32 (which I just saw).

[mcgregorian1]

Hi @teixeirak the figure was updated by Valentine, can you check if it looks the way you were thinking?

[teixeirak]

Yes, that's good.