[LDES-coremodel] Fwd: CEC LDES Grant: RESOLVE Coordination
Sarah Kurtz
skurtz at ucmerced.edu
Sat Dec 12 16:06:38 PST 2020
FYI - I’m thinking that we should wait until January to schedule a follow up meeting with them.
Begin forwarded message:
From: Mengyao Yuan <mengyao.yuan at ethree.com<mailto:mengyao.yuan at ethree.com>>
Subject: RE: CEC LDES Grant: RESOLVE Coordination
Date: December 11, 2020 at 6:48:46 PM PST
To: Sarah Kurtz <skurtz at ucmerced.edu<mailto:skurtz at ucmerced.edu>>, Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>>
Cc: Nick Schlag <Nick at ethree.com<mailto:Nick at ethree.com>>, Arne Olson <arne at ethree.com<mailto:arne at ethree.com>>, Amber Mahone <amber at ethree.com<mailto:amber at ethree.com>>, "Sunquist, Jeffrey at Energy" <jeffrey.sunquist at energy.ca.gov<mailto:jeffrey.sunquist at energy.ca.gov>>, Pedro Andres Sanchez Perez <psanchez30 at ucmerced.edu<mailto:psanchez30 at ucmerced.edu>>
Hi Sarah,
Nice meeting you virtually!
Please find our answers (formatted like this) to your questions below. Please let us know if you’d like to discuss more. Thursday 10am works for Roderick and me, and we can discuss these questions then if you prefer.
* We read that the locations for the candidate technologies were selected according to the transmission zones - but we don’t completely follow this procedure - could you explain how the locations for the candidate resources were assigned?
* RESOLVE takes transmission zone information, including availability of capacity on the existing transmission system and the cost of upgrades to the transmission system, and uses that information in conjunction with resource cost and quality (capacity factor) to determine the least-cost portfolio of resources. CAISO provides transmission availability and cost in a number of areas, and RESOLVE can choose how much to build in each location.
* Do you have a table of latitude and longitude for your candidate profiles (especially for the wind resources)? You indicate that you average the data within each area - that seems to work well for solar, but what about for wind?
* Wind resources are made sure to be limited to smaller areas where there is good resource quality. We normalize the wind profiles to multiyear averages of capacity factors to ensure that the output is benchmarked to historical data.
* Did you test the accuracy of the simulations for solar and wind for the legacy plants?
* We took historical capacity factors for wind and solar and normalized the profiles to those. By doing so, we made sure the existing wind and solar resources generate at capacity factors consistent with historical levels.
* How did you decide on the greenhouse gas emissions targets for the RSP?
* The CPUC selected 46 MMT when they adopted the RSP.
In addition, we’d like to point you to the IRP inputs and assumptions documentation<ftp://ftp.cpuc.ca.gov/energy/modeling/Inputs%20%20Assumptions%202019-2020%20CPUC%20IRP%202020-02-27.pdf>, and the general IRP landing page<https://www.cpuc.ca.gov/General.aspx?id=6442459770> as useful resources.
Hope you have a nice weekend!
Best,
Mengyao
Mengyao Yuan, Ph.D., Consultant
Energy and Environmental Economics, Inc. (E3)
44 Montgomery Street, Suite 1500 | San Francisco, CA 94104
415-391-5100 | mengyao.yuan at ethree.com<mailto:mengyao.yuan at ethree.com>
From: Sarah Kurtz <skurtz at ucmerced.edu<mailto:skurtz at ucmerced.edu>>
Sent: Tuesday, December 8, 2020 11:00 PM
To: Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>>
Cc: Mengyao Yuan <mengyao.yuan at ethree.com<mailto:mengyao.yuan at ethree.com>>; Nick Schlag <Nick at ethree.com<mailto:Nick at ethree.com>>; Arne Olson <arne at ethree.com<mailto:arne at ethree.com>>; Amber Mahone <amber at ethree.com<mailto:amber at ethree.com>>; Sunquist, Jeffrey at Energy <jeffrey.sunquist at energy.ca.gov<mailto:jeffrey.sunquist at energy.ca.gov>>; Pedro Andres Sanchez Perez <psanchez30 at ucmerced.edu<mailto:psanchez30 at ucmerced.edu>>
Subject: Re: CEC LDES Grant: RESOLVE Coordination
Hi, Roderick,
See answers below.
On Dec 8, 2020, at 5:54 PM, Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>> wrote:
Hi Sarah,
I'm adding Mengyao Yuan to our conversation, who will help us answer some of your questions. We had a few clarification questions as we pull together responses:
* We read that the locations for the candidate technologies were selected according to the transmission zones - but we don’t completely follow this procedure - could you explain how the locations for the candidate resources were assigned?
* Can you clarify which "candidate technologies" you're describing? We think you're talking about the different tranches of renewables, is that correct?
Yes. These are typically the ones that are allowed to be built. Specifically, the list in the RSP includes:
Carrizo_Solar
Carrizo_Wind
Central_Valley_North_Los_Banos_Solar
Central_Valley_North_Los_Banos_Wind
Distributed_Solar
Mountain_Pass_El_Dorado_Solar
Greater_Imperial_Solar
Greater_Imperial_Wind
Greater_Kramer_Wind
Humboldt_Wind
Inyokern_North_Kramer_Solar
Kern_Greater_Carrizo_Solar
Kern_Greater_Carrizo_Wind
Kramer_Inyokern_Ex_Solar
Kramer_Inyokern_Ex_Wind
North_Victor_Solar
Northern_California_Ex_Solar
Northern_California_Ex_Wind
NW_Ext_Tx_Wind
Riverside_Palm_Springs_Solar
Sacramento_River_Solar
SCADSNV_Solar
SCADSNV_Wind
Solano_Solar
Solano_subzone_Solar
Solano_subzone_Wind
Solano_Wind
Southern_California_Desert_Ex_Solar
Southern_California_Desert_Ex_Wind
Southern_Nevada_Solar
Southern_Nevada_Wind
SW_Ext_Tx_Wind
Tehachapi_Ex_Solar
Tehachapi_Solar
Tehachapi_Wind
Westlands_Ex_Solar
Westlands_Solar
Arizona_Solar
Baja_California_Wind
New_Mexico_Wind
Wyoming_Wind
* Did you test the accuracy of the simulations for solar and wind for the legacy plants?
* Are you asking whether the existing renewable resource profiles were benchmarked to actual data for the corresponding resources?
Yes. For example, if you look at the output for
CAISO_Solar_for_CAISO
and used your algorithm for the shapes file, how close do you come to the actual performance. I realize that this isn’t a trivial task, but it should be doable.
* Was the usage of the DC output from PVWAtts intentional? How did you derive the data for the shapes.tab file for CAISO_Solar_for_CAISO resource and how did you verify that it accurately represents the generation for solar resources in the CAISO zone? Or, I assume that your use of the DC output from PV Watts instead of the AC output was an oversight, or did you have a reason for making that selection?
* Can you provide an example of the phenomenon you're seeing in the data?
We’ll work on putting this together in a way that’s clear - We had some graphs a couple of months ago, but need to find them or recreate them. We can discuss the rest without this one.
Thanks!
Sarah
Once we have a better understanding of your questions, we can determine whether Thursday at 10am works for us. Is that okay?
Thanks,
Roderick
________________________________
From: Sarah Kurtz <skurtz at ucmerced.edu<mailto:skurtz at ucmerced.edu>>
Sent: Monday, December 7, 2020 8:05 PM
To: Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>>
Cc: Nick Schlag <Nick at ethree.com<mailto:Nick at ethree.com>>; Arne Olson <arne at ethree.com<mailto:arne at ethree.com>>; Amber Mahone <amber at ethree.com<mailto:amber at ethree.com>>; Sunquist, Jeffrey at Energy <jeffrey.sunquist at energy.ca.gov<mailto:jeffrey.sunquist at energy.ca.gov>>; Pedro Andres Sanchez Perez <psanchez30 at ucmerced.edu<mailto:psanchez30 at ucmerced.edu>>
Subject: Re: CEC LDES Grant: RESOLVE Coordination
Hi, Roderick,
Any chance that 10 on Thursday Dec. 17th would work?
Sarah
On Dec 7, 2020, at 5:09 PM, Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>> wrote:
Hi Sarah,
Thanks for sending over these questions. In general, the second Friday of each month works for us; however, we have a conflict for this month (and probably need more time to collect responses to your questions). We could do next Friday 9am if that works for you.
Thanks again,
Roderick
________________________________
From: Sarah Kurtz <skurtz at ucmerced.edu<mailto:skurtz at ucmerced.edu>>
Sent: Monday, December 7, 2020 12:00 AM
To: Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>>
Cc: Nick Schlag <Nick at ethree.com<mailto:Nick at ethree.com>>; Arne Olson <arne at ethree.com<mailto:arne at ethree.com>>; Amber Mahone <amber at ethree.com<mailto:amber at ethree.com>>; Sunquist, Jeffrey at Energy <jeffrey.sunquist at energy.ca.gov<mailto:jeffrey.sunquist at energy.ca.gov>>; Pedro Andres Sanchez Perez <psanchez30 at ucmerced.edu<mailto:psanchez30 at ucmerced.edu>>
Subject: Re: CEC LDES Grant: RESOLVE Coordination
Hi, Roderick,
I apologize for being slow in getting back to you - I thought I had sent this last week, but just realized that it’s still in my drafts.
Here is a list of questions:
* We read that the locations for the candidate technologies were selected according to the transmission zones - but we don’t completely follow this procedure - could you explain how the locations for the candidate resources were assigned?
* Do you have a table of latitude and longitude for your candidate profiles (especially for the wind resources)? You indicate that you average the data within each area - that seems to work well for solar, but what about for wind?
* Did you test the accuracy of the simulations for solar and wind for the legacy plants?
* Was the usage of the DC output from PVWAtts intentional?
*
* How did you decide on the greenhouse gas house emissions targets for the RSP?
It would be great to be able to discuss these! When would be a convenient time for you? We have a standing meeting on Fridays at 9 am - would you like to join us for the second Friday of each month? Or, please suggest a time that would work better for you… Thanks!
Sarah
On Dec 2, 2020, at 9:17 AM, Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>> wrote:
Hi Sarah,
Thanks for the updates. Let's just keep the line of communication open as your team's thinking related to RESOLVE evolves.
As for support, I think it's easiest to coordinate with our project team rather than through Ren and Arne. We'd be happy to set up a few calls over the next few months (maybe once a month, or some other cadence that works for you) to answer any questions. Do you have more questions beyond your question about the CAISO Solar? If so, we could have a first collaborative call to get those answered.
Thanks again,
Roderick
________________________________
From: Sarah Kurtz <skurtz at ucmerced.edu<mailto:skurtz at ucmerced.edu>>
Sent: Tuesday, December 1, 2020 1:15 AM
To: Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>>
Cc: Nick Schlag <Nick at ethree.com<mailto:Nick at ethree.com>>; Arne Olson <arne at ethree.com<mailto:arne at ethree.com>>; Amber Mahone <amber at ethree.com<mailto:amber at ethree.com>>; Sunquist, Jeffrey at Energy <jeffrey.sunquist at energy.ca.gov<mailto:jeffrey.sunquist at energy.ca.gov>>; Pedro Andres Sanchez Perez <psanchez30 at ucmerced.edu<mailto:psanchez30 at ucmerced.edu>>
Subject: Re: CEC LDES Grant: RESOLVE Coordination
Hi, Roderick,
Yes, my thinking has evolved some (and is likely to evolve further). Thank you for your patience and for your follow up!
As I noted in a previous email, we are exploring various options. While there is still some chance that we would use the updated RESOLVE in the next few months, I’m currently thinking that we are better off focusing first on SWITCH and other calculations and foregoing the intermediate RESOLVE version. While I had first been thinking that we should initially focus on RESOLVE, so thought that having as many of the improvements as could be available should be a priority, I’m currently thinking that it would be more work for you and more of a distraction than of significant value for us until the flexible timeframe revisions are made.
In the meantime, I’m curious to understand the level of support that you are willing to provide for the version you have already made publicly available. We would find it very useful to talk with you about things like: how did you derive the data for the shapes.tab file for CAISO_Solar_for_CAISO resource and how did you verify that it accurately represents the generation for solar resources in the CAISO zone? Or, I assume that your use of the DC output from PV Watts instead of the AC output was an oversight, or did you have a reason for making that selection?
We have not wanted to be a nuisance to you, but I think that discussions of this sort could be useful (potentially to both teams). If you’re willing to provide such support, would it be best to contact Ren Orans, Arne Olson (as listed on your website), or work directly with you?
Thanks, again, for your follow up!
Sarah
On Nov 30, 2020, at 12:30 PM, Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>> wrote:
Hi Sarah,
I just wanted to follow up on this discussion about RESOLVE. Has your team's thinking evolved at all since our last email exchange?
Where we are heading is if we want to move forward with using this modified version of RESOLVE that has some of the functionality that you want but not the important functionality for seasonal and multi-day energy dispatch, we would like to have you sign a license saying we would give you the current version without substantial support from our team. That license would only apply to this temporary version, and we could share the new version that we are developing through this grant when that is ready outside of that license.
Thanks,
Roderick
________________________________
From: Sarah Kurtz <skurtz at ucmerced.edu<mailto:skurtz at ucmerced.edu>>
Sent: Sunday, November 8, 2020 2:44 PM
To: Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>>
Cc: Nick Schlag <Nick at ethree.com<mailto:Nick at ethree.com>>; Arne Olson <arne at ethree.com<mailto:arne at ethree.com>>; Amber Mahone <amber at ethree.com<mailto:amber at ethree.com>>; Sunquist, Jeffrey at Energy <jeffrey.sunquist at energy.ca.gov<mailto:jeffrey.sunquist at energy.ca.gov>>; Pedro Andres Sanchez Perez <psanchez30 at ucmerced.edu<mailto:psanchez30 at ucmerced.edu>>
Subject: Re: CEC LDES Grant: RESOLVE Coordination
Hi, Roderick,
It’s great to hear from you. I have been thinking about contacting you to set up a meeting to discuss these matters, so this is very timely.
I would like to discuss these points with my team, but have some preliminary responses - see comments embedded below to make it easier to follow. I’ve identified the one change that I see as most important to us in the near term.
I can understand that you don’t want to spend substantial time supporting our adoption of multiple versions of RESOLVE. However, I wonder if you would be willing to share the code without documentation and without support. I expect that you have the current version of files in a repository from which one of us could easily download the files without a substantial investment of your time. On the other hand, if you haven’t implemented the changes we are most interested in yet, it might make sense to wait until those are done.
It would be great to schedule a time in a couple of weeks to talk through the details a little more. We can then focus our efforts on things that will complement what you are doing. If there is anything that we are developing that could be useful to you, we could also make plans to share that so as to reduce your work load, as well…
Thanks for your careful work on this and for taking the time to share this so clearly! It’s very helpful.
Sarah
On Nov 8, 2020, at 12:25 PM, Roderick Go <roderick at ethree.com<mailto:roderick at ethree.com>> wrote:
Hi Sarah,
I just wanted to follow-up on our conversation about using RESOLVE. As we discussed we (1) have an internal version of RESOLVE that has some notable updates relative to the publicly available IRP version; however, we are (2) planning to make significant modifications to the code & data structure to facilitate our final scenario analysis. While we understand that the internal version has some of the updates you are looking for (hybrid resources, asymmetric charge/discharge), upon more consideration, we think it would be more prudent if we only needed to provide training & support for one version of the model over the course of this project, and we would prefer that support to be for the newer version of the model that we are planning now to support the final scenario analysis.
Here’s the plan I would suggest for the next ~6 months:
* We are happy to coordinate on the publicly available IRP version of RESOLVE, which is also the version that our team is using for the preliminary analysis.
* Based on your schedule, it looks like you would like to demonstrate multiday dispatch for the next public workshop. I think you should proceed with your original plan to make the minimal modifications (e.g., “changing the 24s to 48s” in the code)
After further evaluation (and our conversation with you), I concluded that it would be best for us to use the 37-day formulation in the IRP for any near-term deliverables. I’d be pleased to talk about why this is - see below. Studying week-long or even month-long weather data could make an interesting study, but I now believe will be a distraction from where we need to head in the end. We could still return to that approach, but I’d prefer to focus on full-year data sets. I would far prefer to define the baseline with the modified software (for a full year of data), but I’m thinking that it won’t be possible to move to full-year data analysis in the near term.
*
* I think we can reasonably aim to share an “alpha” version of the new model that incorporates the basic framework updates (see longer description below) by March-April. At this point, we will be in a much better position to support your team, and we expect the model will be much better suited for both of our needs. We would be happy to collaborate, support, and incorporate findings from your team from this point forward.
We very much appreciate your willingness to share an “alpha” version. It may be that we can focus our work more on SWITCH and on the Technology Evaluation parts of the project between now and then, but my instinct is that it would be helpful to begin to use RESOLVE sooner than that.
*
To provide a bit more detail on our plans, we are still planning on getting a “beta+” version of the model by mid-year (June-July) that we think is ready to be used on client projects. This will entail:
* Significant revamp of how RESOLVE handles timeseries data to simplify the input process. At this time, we still do not have a firm design for this, but what I can say is that this will likely have three aspects:
* Removing the hard-coded definition of days and timepoints:
* Contiguous dispatch intervals of greater than 1 day (e.g., 3 days, 1 week, etc.).
According to my analysis - as you indicate above - this is a fairly easy “patch” though the correct way to do it will replace the terminology “day” with a different term, which requires a slightly bigger change. But, as I note above, making this change by itself does not allow us to get to full-year data analysis, though, it could still be possible to do some work on shorter time periods.
*
* Flexibly define timepoints as fractions or multiples of hours. For example, we may find that we can sample and compress an overnight period of 6 hours into one timepoint and assign that timepoint a “weight” of 6x a single hour, or conversely we may want to capture some subhourly dispatch and would give that timepoint a fractional weight.
This is the change that I now view as highest priority. Given that we are studying long-duration storage, I’m focused on the “multiple-hour” timepoints rather than “fractions of hours” timepoints. My quick assessment of this is that it will require introducing one more variable throughout to correctly derive the energy from the power to correctly calculate the variable costs, GHG emissions, etc. I’m guessing that this will require changing several hundred lines of code and is a task that I’d prefer not to duplicate effort on. Generating the “shapes.tab”, “reserve_timepoint_requirements.tab”, “zone_timpoint_params.tab”, and other “timepoints" input files for variable timepoint lengths will also require some code development, but I view those as a necessary part of the research and something we will do anyway (would our code for that be helpful to you?). I wonder if there’s any chance that you would be able to prioritize this particular task.
*
* A new seasonal energy balance input, sort of as an “additional layer” of timeseries inputs in addition to timepoints, days, and years. We hope will become clearer as our preliminary analysis progresses. This would be an extension of the limited inter-day energy shifting capability that RESOLVE already has for hydro resources.
I agree that this is critical. I have been thinking that it may be possible for us to handle this using the existing code and changing the inputs and calculating some metrics from the results. But, doing what you’re suggesting is the more correct way to do it (though I’m not clear on exactly what you’re planning) and once we begin implementing this, I may change my mind about the best approach. The evaluations I’ve been doing have convinced me that how we handle the seasonal storage may drive the overall conclusions of the project. This might be something that we should pursue independently in order to compare independent conclusions, since it is one of the parts of the work for which the best strategy is not obvious, so we may come to different conclusions.
*
* Separating timeseries data from other non-timeseries data inputs in scenario definition, allowing (for example) resource portfolio configurations to be mixed-and-matched with different timeseries samples
Yes, the scenario tool you have created is super helpful, but I envision that it would be better to create the “shapes.tab” file, for example, using Python rather than Excel. I’m appreciative of being able to leverage your work on this, but am less concerned about the time line and if we develop this capability, we’d be pleased to share it with you.
*
* Unification of resource representation to reduce input complexity, particularly to represent “unique” resources like hybrids or resources with varying storage capabilities that may have a wide range of operating constraints. While we have some of these capabilities in our internal version of RESOLVE right now, these need more testing.
* Further generalization of resource adequacy treatment, particularly for storage resources
* Expansion of “custom constraint” functionality to allow greater user control of resource portfolio
* Better documentation of modeling capabilities
All of these will be very useful, but are not needed for us to take our first steps.
*
If you’d like to discuss any of this, I’d be happy to set up a call for us.
Thanks,
Roderick
–––––
Roderick Go, Senior Consultant & Technical Manager
Energy and Environmental Economics, Inc. (E3)
44 Montgomery Street, Suite 1500 | San Francisco, CA 94104
(415) 391-5100 ext. 359 | (415) 692-7160 (direct) | roderick at ethree.com<mailto:roderick at ethree.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ucmerced.edu/pipermail/ldes-coremodel/attachments/20201213/bc55113a/attachment-0001.html>
More information about the LDES-coremodel
mailing list