Percentage-based Demand Flexibility in REISE

[dongqi-wu]

🚀

• Is your feature request essential for your project?

Describe the workflow you want to enable

Allow demand flexibility amount to be specified in percentage.

Describe your proposed implementation, if applicable

1. add an additional flag parameter on input format MW/PCT
2. in the reading input function, check for this parameter, if PCT, multiply the pct numbers with the corresponding demand from demand.csv
3. remaining can be left unchanged

Additional context

this is for the implementation of DOE demand flexibility data which is specified in percentage values. Using the current version, this data must be first converted to MW before running REISE, which is an inconvenience in the workflow.

[danielolsen]

Are we also hoping to add the capability for LSE-based flexibility profiles at the same time, in addition to bus-based and zone-based?

[dongqi-wu]

Are we also hoping to add the capability for LSE-based flexibility profiles at the same time, in addition to bus-based and zone-based?

I think this should be separate problem after the LSE info is incorporated into powersimdata first? For now modifications suggested in this thread is not dependent on anything else.

[BainanXia]

@danielolsen I believe we will have another issue in REISE.jl to allow the engine read LSE profiles from some local directory rather than uploaded during scenario input preparation, then distribute it onto buses in realtime optimization based on the LSE tag and the bus level base demand.

[BainanXia]

@lanesmith @dongqi-wu Could you remind me why we will need this in the current workflow? Based on our discussion last week, I thought we will have the demand flexibility profile by LSE in PCT somewhere on the server rather than provided by the user during scenario creation and the engine will transform the PCT into MW for each bus according to the LSE tag and bus demand in realtime optimization.

We haven't discussed how to mix the two flexibility workflows though (existing one by @lanesmith and the upcoming one by @dongqi-wu) or whether we would want to do so.

[dongqi-wu]

@lanesmith @dongqi-wu Could you remind me why we will need this in the current workflow? Based on our discussion last week, I thought we will have the demand flexibility profile by LSE in PCT somewhere on the server rather than provided by the user during scenario creation and the engine will transform the PCT into MW for each bus according to the LSE tag and bus demand in realtime optimization.

We haven't discussed how to mix the two flexibility workflows though (existing one by @lanesmith and the upcoming one by @dongqi-wu) or whether we would want to do so.

Even if the LSE profile is on the server they still need to be converted to MW for the optimization, in this case the user can specify the parameter to be either read the default LSE flexibility or provide their own through local files?

[BainanXia]

Even if the LSE profile is on the server they still need to be converted to MW for the optimization

Yes, but so far, we don't have profiles in PCT provided by the user, then why a flag parameter to indicate PCT or MW is needed at this point? Or it is possible to have LSE profile in MW in the future?

in this case the user can specify the parameter to be either read the default LSE flexibility or provide their own through local files?

This is the mixture of the current two flexibility workflows which needs further discussion. I still have questions such as,

• The LSE profiles are theoretic limits, the user should be able to specify the "adoption rate" based on whatever assumptions/algorithms that are carried out during specific studies, right?
• Should we allow the user to use local files in some region + default LSE profile elsewhere at the same time?
• Should we allow the user to use local files on the top of default LSE profiles, i.e. an adoption rate of the theoretic limits + extra flexibility in MW?
• If so, what will be the change table schema to make it happen and how REISE.jl should interpret the mixture during optimization?
• How about the cost?

[dongqi-wu]

Yes, but so far, we don't have profiles in PCT provided by the user, then why a flag parameter to indicate PCT or MW is needed at this point? Or it is possible to have LSE profile in MW in the future?

Currently its expected the user to provide MW based flexibility for bus or areas in the grid. Also I think Lane had some previous area level flexibility data from the electrification future study

This is the mixture of the current two flexibility workflows which needs further discussion. I still have questions such as,

1. right, the simplest way is to directly modify the LSE PCT matrix
2. its also simplest to directly change the LSE matrix..
3. same
4. I guess it depends what do we decide to do with the current flexibility csvs, i.e., remain as a flexibility input or change them to a override input that depends on the default LSE based flexibility
5. the DOE data does not have cost. I don't think there is any as detailed dataset ready to use for the cost of demand flexibility. One possible way is to derive something from the ancillary service procurement record of RTOs, there is such data in ERCOT for example, that tells how much are the responsive load offers submitted to ERCOT (https://www.ercot.com/mktinfo/dam). Similar thing also exist for PJM.

[danielolsen]

Maybe within the Scenario framework, we want to treat LSE profiles similar to the hydro/solar/wind profiles we have currently? As in:

• PreREISE generates 'base' profiles, which we store in blob storage and can be automatically fetched by PowerSimData.
• The user may have custom versions of profiles on their local machine.
• Whichever profiles are selected during Scenario preparation in PowerSimData can be scaled up or down via the change table, and then scaled versions are sent to tmp folder on the server or REISE.jl container.
• REISE.jl ingests the profiles and uses them to build an optimization problem.

Differences would be:

• Instead of scaling the capacity of generators, we use an assumed adoption rate to scale the flexibility within each LSE between zero and the theoretical maximum percentage.
• LSE-based flexibility profiles get applied to many buses within REISE.jl (via a cached mapping of buses to LSE), while VRE profiles are each only applied to a single generator.
• Flexibility is a percentage, rather than megawatts.

I don't think we want to work with large bus-based flexibility profiles if we can avoid it, no matter their format. Switching to LSE-based profiles seems like a higher priority to me than switching to percentage-based profiles.

[BainanXia]

• PreREISE generates 'base' profiles, which we store in blob storage and can be automatically fetched by PowerSimData.
• The user may have custom versions of profiles on their local machine.
• Whichever profiles are selected during Scenario preparation in PowerSimData can be scaled up or down via the change table, and then scaled versions are sent to tmp folder on the server or REISE.jl container.
• REISE.jl ingests the profiles and uses them to build an optimization problem.

That perfectly aligns with the workflow @lanesmith mentioned during our discussion. The only difference is whether to host the LSE profile on the server so that we don't need to upload the profile upon scenario creation, instead, simply passing modifications to the engine which will apply the changes in realtime optimization.

Edit: Another observation on the difference between the LSE profile and other base profiles is it is grid independent and scenario independent (other than scaling).