BYU only driver

[abigailsnyder]

Create a way to hijack the driver so that it only collects and runs chunks with 'BYU compliant' in the comments.
Just run these chunks, with the idea that anything upstream of a BYU compliant chunk is itself BYU compliant.

Tests:

• timeshift to just one year (or 2015), per @pralitp suggestion

The first chunk we will be putting the extrapolator into is zchunk_L100.GDP_hist.R, so we will have to make sure the BYU only driver successfully detects, runs, and tests that chunk when ready.

[abigailsnyder]

cool cool cool, github is not letting me update assignees or labels. @bpbond, this one is for you

[abigailsnyder]

Possible test - this is made a little more complicated by the fact that we don't carry units through our chunks, we just add them at the end:
If we want to extrapolate dollar values (such as in zchunk_L100.GDP_hist.R), we have to enforce conversion to 1990USD before any kind of extrapolation. Otherwise the weighting/averaging is wrong.
We could just tell everyone and make sure they know it but that is always a little dangerous.

[abigailsnyder]

Another possible test -
I'm using a comment in the code:

# Perform BYU
# Skeleton - constant extrapolation

to identify where I've added the skeleton. In the same way that the custom driver can scan just for comments #BYUcompliant, we can scan the teams' chunks for the skeleton comment and throw an error if they haven't removed it. At least that way we know that they have actually looked at every piece of code.

[bpbond]

If we want to extrapolate dollar values (such as in zchunk_L100.GDP_hist.R), we have to enforce conversion to 1990USD before any kind of extrapolation. Otherwise the weighting/averaging is wrong.

Jeez there's an issue I hadn't considered.

In the same way that the custom driver can scan just for comments #BYUcompliant, we can scan the teams' chunks for the skeleton comment and throw an error if they haven't removed it.

Nice, yes.

[pkyle]

@abigailsnyder I'm not sure but I think that the dollar conversion extrapolation issue doesn't apply to the GDP data, which is already in real 2005 US dollars. Converting to 1990 USD would just be multiplying every data point by the same factor, so it shouldn't matter whether that multiplication takes place before or after the extrapolation, right?

[abigailsnyder]

@pkyle good point - for this chunk it is actually moot. Guess we should just keep an eye out to make sure it's moot anywhere else it comes up

[abigailsnyder]

Realizing now that oldnew tests will fail automatically once a chunk has been extrapolated - we are literally adding rows. Hence the travis push fail in #1112

It would probably be wise to update the oldnew testing so that we can make sure the original years of extrapolated data sets aren't being updated. But I don't want to go fooling around in the different test scripts without group consensus.

[bpbond]

Ah right. I guess this is one answer to my previous question about changing NA-at-end-of-time-series data? It's a problem because it'll definitely cause oldnew fails.