Move to new methodology for calculating max amount buildable (replacing MCGLT, not MPCbS)

[robbieorvis]

The current approach with using MCGLT to scale deployment is proving very problematic given data limitations in also in the role it has in determining what gets built in each region.

I would suggest replace the current Allocate Available methodology with a methodology based on the logit function, which is used in other similar models and avoids this issue.

The logit form to determine how much demand to allocate to certain technologies is as follows:

1) Each technology gets a shareweight (we'll call this α) . By default we would use a shareweight of 1 2) We already have the service cost; this is the calculated cost per new unit of output. (we'll call this p) 3) We need a uniform exponent across all technologies, which determines the sensitivity of switching based on the cost. We can partially calibrate this based o historical data. A value of -1 would be very insensitive while a value of -10 would be very sensitive. We would probably want something in the -5 to -7 range. (We'll call this λ) 4) A technology's share factor is calculated as α(p^λ) 5) A technology's share is calculated as its share factor divided by the sum of all (including its own) share factors

So if we have two technologies, one with a cost of 5 (tech 1) and the other with a cost of 10 (tech 2), and use a share-weight of 1 and a lambda of -5, we get the following split: Tech 1 (97%) and Tech 2 (3%). An exponent of -10 would give us 99.9 and ~0. An exponent of -1 would give us 66% vs 33%.

Here, we just need to calibrate the exponent, though we can probably use a single value internationally, and the share-weights.

The share-weights could also be calculated to ensure they never exceed the max potential capacity buildable by source by calculating the share weight as the minimum of 1 OR the maximum additional potential capacity by source in a given year divided by [the amount of new demand in a given year divided by (a technology's capacity factor * 8760)]. In other words, we could limit the share-weight to an equivalent amount of capacity based on the max remaining potential capacity by source. This would prevent the model from building more when we have maxed out a technology class.

I think this structure would greatly simplify parts of the electricity sector, reduce the input data need, and provide us with an easier time adapting the model to new regions.

You can read more on this modified logit approach here: https://jgcri.github.io/gcam-doc/choice.html

[robbieorvis]

One other note: this approach does away with MCGLT's scaling based on cumulatively deployed capacity. For the most part, I think it's the right decision. But if we wanted to maintain this ability, you could do it by calculating the share-weights within Vensim based on the cumulative capacity installed of a tech, how that relates to new build potential, and then how new build potential relates to the total need for new supply.

For example, let's say we wanted to preserve this for offshore wind. I could see starting with a share-weight of say 0.1 for offshore wind. Let's say we wanted to double the amount buildable per every doubling of cumulative capacity. In future time steps, the share weight could just be calculated using a formula that has that relationship, up until we hit a value of 1, which would allow all new demand to be met with offshore wind.

[jrissman]

This looks like a really good idea to me. It would be nice to replace the ALLOCATE AVAILABLE functions in the EPS with something better, due to the problematic need for the area-under-the-curve as an input to ALLOCATE AVAILABLE.

We use ALLOCATE AVAILABLE for three things in the EPS:

• What new power plants to build (in three places - RPS, non-RPS, and peakers)
• What to dispatch
• What vehicle types people buy

Of these, for the first and third, it's difficult to supply the area under the curve.

It's not difficult to supply the area under the curve for what to dispatch, because is simply the potential output of the plants that exist at their bid capacity factors. (It's calculated by Vensim rather than supplied as input data.) So for dispatch, I think it's okay if we stick with ALLOCATE AVAILABLE, but it would be good to move to logit functions for power plant construction and vehicle purchases.

[robbieorvis]

Agreed. I think it may also obviate the need for some of the standard deviation inputs.

---

Robbie Orvis Director of Energy Policy Design Phone: 415-799-2171 98 Battery Street, Suite 202 San Francisco, CA 94111 www.energyinnovation.orghttp://www.energyinnovation.org/ [cid:image001.jpg@01D0D699.20A24470]

---

Check out our new book, Designing Climate Solutions: A Policy Guide for Low-Carbon Energyhttps://www.amazon.com/Designing-Climate-Solutions-Policy-Low-Carbon/dp/1610919564 Available wherever books are sold

[Policy Design book cover]

From: Jeff Rissman notifications@github.com Sent: Wednesday, December 2, 2020 4:21 PM To: Energy-Innovation/eps-us eps-us@noreply.github.com Cc: Robbie Orvis robbie@energyinnovation.org; Author author@noreply.github.com Subject: Re: [Energy-Innovation/eps-us] Move to new methodology for calculating max amount buildable (replacing MCGLT, not MPCbS) (#125)

This looks like a really good idea to me. It would be nice to replace the ALLOCATE AVAILABLE functions in the EPS with something better, due to the problematic need for the area-under-the-curve as an input to ALLOCATE AVAILABLE.

We use ALLOCATE AVAILABLE for three things in the EPS:

• What new power plants to build (in three places - RPS, non-RPS, and peakers)
• What to dispatch
• What vehicle types people buy

Of these, for the first and third, it's difficult to supply the area under the curve.

It's not difficult to supply the area under the curve for what to dispatch, because is simply the potential output of the plants that exist at their bid capacity factors. (It's calculated by Vensim rather than supplied as input data.) So for dispatch, I think it's okay if we stick with ALLOCATE AVAILABLE, but it would be good to move to logit functions for power plant construction and vehicle purchases.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Energy-Innovation/eps-us/issues/125#issuecomment-737502572, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SMVBSNEF44XHEKJUMLSS2VS5ANCNFSM4ULA576A.

[robbieorvis]

@jrissman is there any way we can get this into 3.2? I'm finding this is a growing issue across model regions, and the fix is fairly straightforward. I can take a stab at the edits in a branch I'll call #125.

[robbieorvis]

@jrissman A fully working version of the model that completes these updates is done in branch #125. I replaced the structure for allocation for all the capacity pieces in the power sector (RPS, free allocation, and peak) and for transportation. I deleted extraneous files and structure. Happy to chat some more about what was done. I haven't fully cleaned up and structurally organized everything, because I thought you might want to do that. But all new variables are highlighted in red and you can see them on the Electricity and Transportation Main and BAU pages.

I also caught and fixed a couple of bugs:

1) The variable Change in Process Emissions at BAU Production Level by Pollutant in CO2e separately breaks out the livestock measures policy in the ag sector and was missing the part of the equation that multiplies the potential reductions by the share of reductions from policy. This was causing ag livestock reductions in all years even in the BAU

2) In a previous update, the variable Electricity Sector CO2e Emissions was subscripted to allow for the output graph comparing emissions by power plant type to be created, but that caused the graph of Electricity Sector CO2e Emissions on the Electricity-Main page to stop working. I updated the graph definitions to pull in a a different variable, Output CO2e Emissions by Sector[electricity sector] to show the correct line on the graph.

[jrissman]

I just read the information at the link to GCAM's explanation of its Logit and Modified Logit choice models. That is very helpful. They provide some guidance on the situations in which to use each choice model. Have you decided which to use in each place that uses ALLOCATE AVAILABLE in the EPS?

Even though there is one place where we could keep ALLOCATE AVAILABLE (the choice of what to dispatch), we might be better off replacing it too. When we try to convert the EPS to WebAssembly (WASM), we need to re-implement any Vensim functions we use, and ALLOCATE AVAILABLE is one of the more difficult ones to re-implement. It would be a shame to have to do that re-implementation work for a complicated function we're hardly using, when the alternative is straightforward and would be implemented by us using the normal math operators, and thus present no difficulties during WASM conversion.

The following 10 variables use ALLOCATE AVAILABLE. In all ten of these, the ALLOCATE AVAILABLE equation should be replaced with either a Logit or Modified Logit equations:

BAU Electricity Dispatched by Least Cost in One Vector
BAU New Elec Output Allocated Freely
BAU New Elec Output Allocated Under RPS
BAU New Peaker Capacity Allocated
BAU New Vehicles Allocated by Technology
Electricity Dispatched by Least Cost in One Vector
New Elec Output Allocated Freely
New Elec Output Allocated Under RPS
New Peaker Capacity Allocated
New Vehicles Allocated by Technology

In the case of power plants, we were forced to move subscript elements from the Electricity Source and Power Plant Quality subscripts into a single subscript, because ALLOCATE AVAILABLE did not function correctly when applied to multiple subscripts. Since we will be moving to code that defines the operations using normal arithmetic operators, we no longer have this limitation, so it is important to remove this ugly work-around from the code and operate across subscripts normally. Therefore, we need to delete some of the variables immediately prior to the ALLOCATE AVAILABLE variables whose purpose was to load the two-dimensional values into a one-dimensional vector, and also delete the variables immediately after the ALLOCATE AVAILABLE whose purpose was to move the one-dimensional data back into the two-dimensional array.

Once this is done, we need to eliminate the following subscripts. The first of these was used for the one-dimensional array we won't be using anymore, and the second was used for holding ALLOCATE AVAILABLE properties:

Power Plant Type by Quality (and its sub-ranges - delete the sub-ranges before deleting the enclosing subscript!)
Priority Profile

We also need to eliminate subscript maps inside subscript Electricity Source that referred to sub-ranges of Power Plant Type by Quality that were deleted. But do not delete the map to electricity source within all fuels, which is still needed and has nothing to do with ALLOCATE AVAILABLE.

We need to update the comments in these variables:

BAU Unmet Electricity Demand
Unmet Electricity Demand

You will need to delete input variables that were only used to feed properties to ALLOCATE AVAILABLE, including the areas under the curve and the normalized standard deviations of various things. When you remove one of these variables from Vensim, before you do anything else, please delete that variable's folder from InputData and update the AcronymnKey files, as it is too easy to forget to do this if you do anything else in between deleting the input data variable from Vensim and these follow-up steps. Vensim will not flag it if you accidentally leave the files in InputData, which is why it is important to do this right away, so it is not forgotten.

There will also be some calculated variables to delete in Vensim pertaining to these inputs, I believe.

You will need new input variables for the Logit functions, which contain the parameters mentioned in the GCAM help document (specifically β and γ). Those might be constant or time-varying depending on your needs. You'll need to add folders for these new input variables and add them to the AcronymnKey.

I strongly recommend starting off by switching just one of the ALLOCATE AVAILABLE variables to a Logit or Modified Logit function, make sure the model runs, and ensure it produces sensible results when no policies are enabled (keeping in mind that the BAU case and Policy case won't quite match, and that's okay in this case). Then you can do the BAU version of that variable and run the model again, and it should still produce good results, and the Policy and BAU cases should match. Then you can move on to the next variable. If you do them one at a time and ensure the model runs after each one you work on, and produces sensible results, this will help you catch bugs sooner and more easily, as there will be less code changes to look through, and working on a running model is always easier than working on one that cannot run.

Only once you have replaced all of the Allocate Available pieces should you delete the subscripts, etc.

I hope this outline is helpful.

[jrissman]

I see you already implemented this, though probably not every detail I mentioned in my previous comment. Do you wish to go back and do any further refinements based on what I wrote in that comment?

[robbieorvis]

I’ve done all the updates except for dispatch as it seemed least likely to methodologically need an update, but I can do that too based on your feedback and possibly moving to a new webtool format. For now, I think you should take a look at what I did when you have time. I can revisit and update the dispatch elements next week. The methodology is the same and we can get rid of subscript remapping.

Sent from my iPhone

On Mar 12, 2021, at 3:44 PM, Jeff Rissman @.***> wrote:



I see you already implemented this, though probably not every detail I mentioned in my previous comment. Do you wish to go back and do any further refinements based on what I wrote in that comment?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Energy-Innovation/eps-us/issues/125#issuecomment-797744554, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SPWTBAVUDAFPXBZZR3TDJVLVANCNFSM4ULA576A.

[jrissman]

Okay, I'll take the next pass on branch #125. I'll check through the things I listed in my comment and implement any missing bits and do clean-up. I might move the dispatch to Logit after that, which we need to do before we can delete the subscripts, etc. Thank you for implementing this!

[jrissman]

I've remembered that there likely will be EPS models that won't be updated to 3.2.0 or later for a long time, if ever. The WebAssembly conversion process needs to work on them too. So we might need to implement ALLOCATE AVAILABLE in the WebAssembly converter even if we remove all instances of that function from EPS 3.2.0.

It may still be worth removing all ALLOCATE AVAILABLE function calls in order to remove the need for certain input data, like the normalized standard deviations of certain costs, to remove some ugly subscript mapping and otherwise simplify the code, and to use a consistent methodology in all places where we allocate things. But avoiding the need to implement ALLOCATE AVAILABLE in the WebAssembly converter might not be among the benefits.

[robbieorvis]

Okay, well after you review, let me know. If you want to do it, that’s fine, or I’m happy to do it too.

---

Robbie Orvis Director of Energy Policy Design Phone: 415-799-2171 98 Battery Street, Suite 202 San Francisco, CA 94111 www.energyinnovation.orghttp://www.energyinnovation.org/ @.***D71B0B.71E67D80]

---

Check out our book, Designing Climate Solutions: A Policy Guide for Low-Carbon Energyhttps://www.amazon.com/Designing-Climate-Solutions-Policy-Low-Carbon/dp/1610919564 Available wherever books are sold

[Policy Design book cover]

From: Jeff Rissman @.> Sent: Wednesday, March 17, 2021 12:53 AM To: Energy-Innovation/eps-us @.> Cc: Robbie Orvis @.>; Author @.> Subject: Re: [Energy-Innovation/eps-us] Move to new methodology for calculating max amount buildable (replacing MCGLT, not MPCbS) (#125)

I've remembered that there likely will be EPS models that won't be updated to 3.2.0 or later for a long time, if ever. The WebAssembly conversion process needs to work on them too. So we might need to implement ALLOCATE AVAILABLE in the WebAssembly converter even if we remove all instances of that function from EPS 3.2.0.

It may still be worth removing all ALLOCATE AVAILABLE function calls in order to remove the need for certain input data, like the normalized standard deviations of certain costs, to remove some ugly subscript mapping and otherwise simplify the code, and to use a consistent methodology in all places where we allocate things. But avoiding the need to implement ALLOCATE AVAILABLE in the WebAssembly converter might not be among the benefits.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Energy-Innovation/eps-us/issues/125#issuecomment-800792758, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SNB6GS423CAY3KJFJTTEAYURANCNFSM4ULA576A.

[jrissman]

I'm looking at branch #125 now.

[jrissman]

I cleaned up the code in branch #125.

I decided not to change the ALLOCATE AVAILABLE used for dispatching power plants, because I think that methodology is more defensible for dispatch than it was for choosing what to build (since we get the area under the bell curves from internal Vensim calculations instead of requiring it as input data), and the one normalized standard deviation input variable needed to supply the dispatch calculation is probably not any harder to supply than calibrating the Logit Exponent and Shareweights would have been. Thus, eight of the ten variables that used ALLOCATE AVAILABLE now use Logit functions, and the last two still use ALLOCATE AVAILABLE.

I see that the transportation shareweights in trans/TTS were calibrated based on what we used to have in the (removed) variable trans/MPNVbT. However, the electricity sector shareweights in elect/ETS were not calibrated. All shareweights were set to one and no input data source was supplied. I think that's pretty far off, and elec/ETS needs a data source.

I went ahead and set to zero the shareweights for crude oil power plants and heavy/residual oil power plants, because we don't have those types of power plants in the U.S. model. But I left the others for you all to handle.

Right now, we get some pretty strange results if you compare the allocation results in branch #125 to the allocation results in the "develop" branch. (I merged "develop" into "#125" so that the new allocation methodology is the only difference between the two branches.) Looking at the variable New Allocated Output (which sums the output allocated in the RPS and non-RPS allocation steps, but not peaker allocation), we see that the amount of new output allocated to geothermal plants increased by 179593%, the amount allocated to solar thermal increased by 1489841646%, and the amount allocated to coal plants increased by 2316548874147%. I've attached a spreadsheet here showing the double-check calculations:

2021-03-17 Power Plant Allocation Checks.xlsx

I haven't run any checks on the transportation sector allocations. I only checked the electricity sector ones.

Since there appear to be some problems with the input data, I haven't merged #125 into develop. I think it would be good if you all could get everything looking good by adjusting elec/ETS and elec/ETLE (and if needed, the Transportation equivalents, TTS and TTLE), then it can be merged into "develop". I will assume my own work on issue #125 is done unless I hear otherwise from one of you.

[robbieorvis]

I’ve calibrated a few pieces and am going to merge now. We will do some final calibration in develop once the rest of the data updates are finished, but this is looking good.

Thanks!

---

Robbie Orvis Director of Energy Policy Design Phone: 415-799-2171 98 Battery Street, Suite 202 San Francisco, CA 94111 www.energyinnovation.orghttp://www.energyinnovation.org/ @.***D71C18.38C052C0]

---

Check out our book, Designing Climate Solutions: A Policy Guide for Low-Carbon Energyhttps://www.amazon.com/Designing-Climate-Solutions-Policy-Low-Carbon/dp/1610919564 Available wherever books are sold

[Policy Design book cover]

From: Jeff Rissman @.> Sent: Wednesday, March 17, 2021 9:31 PM To: Energy-Innovation/eps-us @.> Cc: Robbie Orvis @.>; Author @.> Subject: Re: [Energy-Innovation/eps-us] Move to new methodology for calculating max amount buildable (replacing MCGLT, not MPCbS) (#125)

I cleaned up the code in branch #125https://github.com/Energy-Innovation/eps-us/issues/125.

I decided not to change the ALLOCATE AVAILABLE used for dispatching power plants, because I think that methodology is more defensible for dispatch than it was for choosing what to build (since we get the area under the bell curves from internal Vensim calculations instead of requiring it as input data), and the one normalized standard deviation input variable needed to supply the dispatch calculation is probably not any harder to supply than calibrating the Logit Exponent and Shareweights would have been. Thus, eight of the ten variables that used ALLOCATE AVAILABLE now use Logit functions, and the last two still use ALLOCATE AVAILABLE.

I see that the transportation shareweights in trans/TTS were calibrated based on what we used to have in the (removed) variable trans/MPNVbT. However, the electricity sector shareweights in elect/ETS were not calibrated. All shareweights were set to one and no input data source was supplied. I think that's pretty far off, and elec/ETS needs a data source.

I went ahead and set to zero the shareweights for crude oil power plants and heavy/residual oil power plants, because we don't have those types of power plants in the U.S. model. But I left the others for you all to handle.

Right now, we get some pretty strange results if you compare the allocation results in branch #125https://github.com/Energy-Innovation/eps-us/issues/125 to the allocation results in the "develop" branch. (I merged "develop" into "#125https://github.com/Energy-Innovation/eps-us/issues/125" so that the new allocation methodology is the only difference between the two branches.) Looking at the variable New Allocated Output (which sums the output allocated in the RPS and non-RPS allocation steps, but not peaker allocation), we see that the amount of new output allocated to geothermal plants increased by 179593%, the amount allocated to solar thermal increased by 1489841646%, and the amount allocated to coal plants increased by 2316548874147%. I've attached a spreadsheet here showing the double-check calculations:

2021-03-17 Power Plant Allocation Checks.xlsxhttps://github.com/Energy-Innovation/eps-us/files/6160681/2021-03-17.Power.Plant.Allocation.Checks.xlsx

I haven't run any checks on the transportation sector allocations. I only checked the electricity sector ones.

Since there appear to be some problems with the input data, I haven't merged #125https://github.com/Energy-Innovation/eps-us/issues/125 into develop. I think it would be good if you all could get everything looking good by adjusting elec/ETS and elec/ETLE (and if needed, the Transportation equivalents, TTS and TTLE), then it can be merged into "develop". I will assume my own work on issue #125https://github.com/Energy-Innovation/eps-us/issues/125 is done unless I hear otherwise from one of you.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Energy-Innovation/eps-us/issues/125#issuecomment-801549058, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK5N6SPE7PWFQKBNUL7KMX3TEFJV7ANCNFSM4ULA576A.

[robbieorvis]

Done in commit 51386d514d8a202e47eed5019027269457bfcc06