Question about calculation of curt_tran_h

[narata2019]

Hi, ReEDS team,

I have a question about the calculation of 'curt_tran_h' in 'C2_marginal_curtailment.py'.
The parameter 'curt_tran_h' is defined as 'Marginal transmission reducing existing curtailment' and the formula is as (line320):
curt_tran_h = curt_trans_reduced / curt_path_source_h (1)

In my opinion, the marginal value should be written as follows because of marginal addition of transmission capacity:
curt_tran_h = curt_trans_reduced / marg_trans (2)

Could you help with the reason of curt_tran_h calculation? Many thanks!

Siming Song

[wesleyjcole]

Thanks for your question here. This is a bit complicated because we are estimating the impacts of a step change and applying it to all possible options. For example, if a region has 100 MW of curtailment before adding marg_trans (which is 1000 MW by default), and then has 0 MW after adding marg_trans, then method (1) will give a curt_tran_h of 100%, while method (2) will give a curt_tran_h of 10%. We would want the 100% value implemented in ReEDS to reflect that building this transmission line would be effective at reducing all of the curtailment. But if adding 1000 MW line reduces curtailment from 100 MW to 90 MW, then we would want curt_tran_h to follow method (2) and show that adding transmission has little effect (method 2 would give 0.01 while method 1 would give 0.1). The closer you are to eliminating all the curtailment, then better method 1 is, while method 2 is better when there is less curtailment reduction.

We could probably create a hybrid approach that switches or blends the methods based on how the calculation turns out. For example:

if curt_trans_reduced / curt_path_source_h > 0.75:
curt_tran_h = curt_trans_reduced / curt_path_source_h
elif curt_trans_reduced / curt_path_source_h > 0.25:
curt_tran_h = ( (curt_trans_reduced / curt_path_source_h) + (curt_trans_reduced / marg_trans) ) /2
else:
curt_tran_h = curt_trans_reduced / marg_trans

This is certainly worth thinking through given that our current treatment is not ideal under all conditions.

[narata2019]

Thank you！I get it now！Can I understand it this way? Both calculation method is good. We can only get an approximation of the marginal value by adding more calculating details, such as selecting a good step value or the judgment statement, but never get the true value due to the soft linking method between ReEDS and Augur.

Another question is about the variable STORGE_IN(i,v,r,h,src,t), which is set as zero when set 'src' is ['wind', 'pv' , 'old'] in intertemporal solve, and comes into effect when 'src' is ['other']. I have no idea what these setting means. Could you give me some more details?

[wesleyjcole]

Your understanding is correct here. We're approximating a value to use in ReEDS, and there are a number of approaches one could take to get a decent value.

The 'src' set defines the source of the storage charging. It can charge from wind curtailment ('wind'), solar pv curtailment ('pv'), "old" curtailment (meaning curtailment from generators built before the current solve year, labled 'old'), or from something else ('other'). We use this set to make sure accounting is appropriate. E.g., you can't charge more from pv curtailment than there is pv curtailment, but when you do it reduces curtailment during the hours when that pv curtailment would occur. The 'other' category ensures that storage can always charge regardless of how much curtailment there is in the model.

We turn off this setting in the intertemporal solve because intertemporal sees all the years simultaneously, so we throw out the representation of existing and marginal curtailment that we use when solving sequentially.

[narata2019]

Thanks for your clear answer! Without 'curt_stor' in intertemporal solve method, as I can see there is no iternation parameters to reflect the ability of STORAGE_NO_CSP to smooth the hourly fluctuations of VRE generation in intertemporal solve method. Will this underestimate the contribution of storage than in sequential method?

[wesleyjcole]

We have not spent a lot of time comparing intertemporal to sequential for many of these parameters. The intertemporal solve creates a very large model that is challenging to solve without turning many features off, so we have mostly relied on the sequential solve method.

[narata2019]

Many thanks!

[maxxb77]

Siming - I have some slides from an INFORMS presentation in 2019 that compared intertemporal and sequential ReEDS, reach out ***@***.***) if you would like them. Best, Max

…

On Tue, Nov 8, 2022 at 8:32 AM narata2019 ***@***.***> wrote: Many thanks! — Reply to this email directly, view it on GitHub <#131 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIHEAOTOAILPGNW4MJYKMRDWHJW7PANCNFSM6AAAAAART57JFQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[narata2019]

Hi, Max

That would very helpful for me. My email is ssm19@mails.tsinghua.edu.cn
Many Thanks~

Siming