search

e4st-dev / E4ST.jl

Engineering, Economic, and Environmental Electricity Simulation Tool (E4ST)
GNU General Public License v3.0
7 stars 1 forks source link

Implement Mainline Policies #15

Closed Ethan-Russell closed 1 year ago

sallyrobson commented 1 year ago

We want to improve our current representation of the IRA by including a.      45V: Production credits for clean hydrogen (13204) b.      Power: Accelerated depreciation (13703) c.      Loan authority for energy infrastructure (50144) d.      Power: Transmission financing (50151)

sallyrobson commented 1 year ago
sallyrobson commented 1 year ago

Working on this in e4st-input-processing repo and in the excel sheets in the InputDev L drive folder. The file organization of this will be changed and it won't continue to live in the L drive. More info on this can be found in the issue for this in the e4st-input-processing repo.

sallyrobson commented 1 year ago

State RPS and CES set

Dan mentioned in a call that we could start with a minimum set of policies that aren't extended and modified as we have in the past. We could late develop a set of modified policies which we could use if we think it is relevant to a specific project. So essentially creating two sets of background policies but only doing the minimal one now.

I think that this wouldn't be much more work and would probably save us some time now. The modification I might make would be to smooth out the CES requirements because many of them are just the target value in the target year, so unless we model that exact year we wouldn't see them in the model at all. Other than that I think it would be fine to just use the base values.

Ethan-Russell commented 1 year ago 
example_rps:
    type: "RPS"
    crediting: 
      type: "StandardRPSCrediting"
    gen_filters:
      country: "archenland"
    load_targets:
      stormness_rps:
        filters:
          state: stormness
        targets:
          y2035: 0.9
          y2040: 0.95
Ethan-Russell commented 1 year ago

@sallyrobson the way I implemented it, there is no usage of the name of the target. I.e. in the above example, stormness_rps is not used. Do you think I should make load_targets be a vector of OrderedDicts rather than an OrderedDict of OrderedDicts? It would look like the below:

example_rps:
    type: "RPS"
    crediting: 
      type: "StandardRPSCrediting"
    gen_filters:
      country: "archenland"
    load_targets:
    - filters:
        state: stormness
      targets:
        y2035: 0.9
        y2040: 0.95
    - filters: # If we needed another set of targets and filters
        state: anvard
      targets:
        y2040: 0.5

Thoughts between the two?

sallyrobson commented 1 year ago

@sallyrobson the way I implemented it, there is no usage of the name of the target. I.e. in the above example, stormness_rps is not used. Do you think I should make load_targets be a vector of OrderedDicts rather than an OrderedDict of OrderedDicts? It would look like the below:

example_rps:
    type: "RPS"
    crediting: 
      type: "StandardRPSCrediting"
    gen_filters:
      country: "archenland"
    load_targets:
    - filters:
        state: stormness
      targets:
        y2035: 0.9
        y2040: 0.95
    - filters: # If we needed another set of targets and filters
        state: anvard
      targets:
        y2040: 0.5

Thoughts between the two?

Is there an advantage to it being an array? I think it could go either way but might be better to stick with our general convention of nested OrderedDicts so that there isn't weird confusion with that.

Ethan-Russell commented 1 year ago

Sounds good, thanks! I'll make a note that the name isn't really used at the moment.

sallyrobson commented 1 year ago

@DanShawhan I'm working on the state CESs and need to specify a crediting structure. Currently in matlab E4St, they are set up as an RPS with a few more qualifying technologies including NGCCS. NGCCS gets credits based on emis rate (like a normal CES) with a benchmark rate of 0.6 metric tons/MWh. I have two questions that'd I'd like your input on:

(1) I'd like to set up the state CESs as a normal CES with a set benchmark that any technology could qualify for (except possibly batteries). Can you think of a reason to not do this, or why it was set up as an RPS in the matlab E4ST? Are there any technologies we should generally exclude?

(2) For the benchmark emission rate, do we want to keep using 0.6 metric tons/MWh? I'm not sure where this came from, it's just hard coded into E4ST and doesn't have a source listed so I assume it is something that we chose. I could also look up more state specific benchmarks but we would probably have to make some assumptions about them anyways.

DanShawhan commented 1 year ago

Hi Sally, Good plans and questions.

I think it was set up as an RPS just to save time. The only reasons not to that I can think of are a) states might be setting their CESs up like RPSs (though that doesn't necessarily mean we shouldn't.) b) a possible factor is that CCS could increase criteria pollutants (in which case we might want to give it less credit than it would get based on a normal CES) but I don't think so based on our CCS EJ project c) it might take longer to set it up in E4ST as a normal CES (but you probably have a pretty good idea of whether it would and if so how much) d) Would it be harder to have combined constraints to make CESs and RPSs non-overlapping in the event we need that, e.g. to again represent voluntary green power purchasing with a portion supplyable from anywhere in country? I don't think any of these is likely to be a showstopper unless you see a reason that it makes an RPS-like CES a better choice.

States might exclude CCS from eligibility for their CESs. If we set state CESs up as normal CESs, can we still make a technology like CCS ineligible if we want to match a state's actual policy? I'm guessing yes.

Not certain off the top of my head what is the right choice for storage. But I think we have already effectively decided what is the right choice for it when we talked about how we treat charging load.

0.6 is an in-between benchmark. The nationally proposed ones have varied from 0.4 metric tons to 0.82 metric tons, so 0.6 is in the middle.

CO2e of methane in state policies will play a role too.

sallyrobson commented 1 year ago

I think it would take longer to set up as a modified RPS than it would to just set it up as a CES. And yes we can still make some technology ineligible if we set it up as a normal CES, it's really just the crediting structure that changes.

For now I haven't done any work to reconcile overlapping policies because we decided we didn't need it for now so either choice here wouldn't change how much work it would be to add VGPPs. For now, I think we should leave them out and then add this if we have a project where they would be relevant. I wonder how often they are binding in the model currently?

I think storage should be excluded generally, it isn't currently part of the CESs. Coal CCS isn't included with our current representation either but it might not qualify because of emissions anyways, or would receive a very low credit.

Finally, I think that the current representations use CO2e, do you know if that's a standard thing for all CESs? Or just state policies? It looks like most of the CESs defined in matlab E4ST use CO2e so I think I will make that the default in julia E4ST too.

DanShawhan commented 1 year ago

Thanks, Sally. I think storage might need to be in the CES policy somehow in order for us to have an efficient CES representation, and I think we should have an efficient CES representation. Not certain how storage should be treated, but I think it might be that it should pay for CES credits like other electricity consumers do, but just for its net electricity consumption. e.g. if there is a 50% CES and storage loses 15% of electricity stored and we have an assumption that storage generation plus losses equals electricity stored, then need to buy 0.5*0.15 CES credits for every MWh of electricity purchased. Can you think about this and try to figure out what makes sense? The other possibility I thought about was that maybe storage should pay for CES credits for all electricity stored (e.g. 0.5 credits per MWh stored) and then earn credits for generation. But I don't think that is right because it seems to me like the storage would get .85 credits and pay for 0.5 credits for every MWh it stored, and I'm not seeing why that would be correct.. There is a correct way to treat storage in the CES, and all other ways are incorrect unless they are equivalent to that correct way.

I think Coal CCS should qualify if its emission rate is low enough, unless we learn that states are excluding coal CCS.

There is the question of what CO2e we should use for methane in state policies by default. We could use what states seem to be using. There are at least 4 options: zero, ratio of estimated methane damage over estimated CO2 damage in recent EPA draft social cost of GHGs, 100-year GWP, and 20-year GWP. I think NY is using 20-year GWP. When we have a project that calls for using a different CO2e for methane in the state CESs, we can do so. We should put methane CO2e in our spreadsheet of sim design decisions for each project. Can you do that if it is not already there?

sallyrobson commented 1 year ago

I think that the way you were describing storage representation is what we do. We include the net energy consumption from storage in the load which we apply the CES to. But we don't say that energy storage gets any clean energy credits for discharging to the grid. This is mostly because don't want to double count (if the battery was charged with solar then the solar already got those credits), but also because we don't know the actual emissions from generating that electricity to charge the battery. I think this is the most realistic and intuitive representation but I just wanted to confirm that I'm not missing something.

sallyrobson commented 1 year ago

For Co2e, we should decide a couple other things about it. I already have an issue about this so we might want to move this conversation over to Issue #122. Currently, the CO2e calculation does 3 things (1) it adds methane CO2e for NG, coal, and DAC (2) it adjusts the CO2 emissions from biomass and CHP to be a portion of the actual stack emissions so that it is only the emissions new to the atmosphere and from electricity generations (3) it adds EOR leakage to CCS.

In our new CCS representation, we just directly update CO2 emissions with EOR leakage so that won't happen in our new CO2e calculations. I have mixed feelings about our adjustments to CHP and biomass, I think they are helpful values for many of our results, particularly for welfare and climate impacts. But it just means we need to be careful if we are looking at more local (or location specific) emissions, although I know that our other pollutants usually matter more locally than CO2. I'm thinking of creating a couple different CO2e numbers, one being the current version that adjusts biomass and CHP. And one that is just smokestack, although I don't know exactly when we would use this. I'm also not sure if our methane fuel content numbers include upstream methane leakage or if they are just actual smokestack methane emissions. Maybe we can talk about this at a meeting soon.

sallyrobson commented 1 year ago

Mainline policies to implement

Unsure if we need to or how to

sallyrobson commented 1 year ago

@DanShawhan For the mexico co2 price, we previously used half of the SCC value. I'm debating whether to (1) continue using the numbers we already have which go from about $20 to $37 between 2016 and 2050. (2) use the same method of half the SCC with the updated SCC number which would $72 to $126 between 2016 and 2050 (for reference the canada co2 price goes from $13 to $90) (3) use the same values as canada (4) look for another source entirely

What do you think about these options?

We are planning to go with option (1) because it is likely the correct range that goes up over time.

sallyrobson commented 1 year ago

From Power Modeling lunch 5/9/23

  1. Dallas brought up that VGP is fairly large and has a growing impact on clean energy investments so we should think about including it. Dan brought up that most of the VGPs cost less than just buying electricity from the utility and so there might be less VGP if it was actually binding. And IRA might even make it cheaper.

  2. AB32 free allocation data sheet might be a good source for emissions but they would include allowances for out of state emissions. Might be able to put a border carbon price on it to adjust, or adjust the cap. Or could just represent as a price and that would probably be sufficient.