Closed ColinAE closed 8 years ago
It was mostly for de-bugging. I say we get rid of this. This wouldn't scale to other heatwave definitions-- many of them wouldn't use thresholds in quite the same way.
You know what, this is working now, so let's leave it in until we get all of our data. It wouldn't hurt to have these threshold files. Then we'll probably take it out for the final package we publish.
Was It supposed to write the threshold temperatures for each ensemble or each model? It looks like I wrote the function with the intention of writing threshold temperatures for the r1i1p1 ensemble of each model, but the code that calls the function does not reflect this.
I think it was for each model, and then we were planning to use the same model-specific threshold for all ensemble members in the model. However, if it's currently doing a separate threshold for each ensemble member, that's fine-- they should be very similar across ensemble members in the same model, so our results should not be particularly sensitive to whether we choose to do model-specific or ensemble-specific thresholds.
Based on Dr. Barnes' suggestion, I changed the code to pull the first ensemble member each time. See this commit: https://github.com/geanders/futureheatwaves/commit/59de8ccd4908c3c62cebb2123e75d3d936ed62ba
I've got this running so it grabs the thresholds from the first ensemble member in the directory within the relevant thresholdBoundaries
date bounds, as specified by the user.
We are getting this information in the heatwave datasets as one of the columns, so we don't need to write this out anymore. Let's take this out.
Dr. Anderson,
Some time ago you instructed me to make the program output some of the thresholds for either each model or each ensemble. I believe this was for debugging purposes. Do you remember what this was about?
This question pertains to the writeThresholds function in IO.R. It is not implemented properly and I am not sure how it should be implemented.