Variable costs should not be assigned to virtual storage charge/discharge

[wilson-ricks]

In develop, lines 62-74 in storage_all.jl assign costs to 'virtual' charge and discharge for storage. These costs should not exist as virtual operations are theoretical, not actual, and they lead to absurd outcomes in certain edge cases. For example: if hydrogen storage receiving the 45V production tax credit is modeled as having a negative variable charging cost, the model can still gain this subsidy through virtual charging, which requires no actual power consumption and only the presence of sufficient capacity, which can be achieved by building cheap combustion turbines that never run. This results in an infinitely negative objective as the model builds unlimited electrolyzers and combustion turbines.

[sambuddhac]

In PR I eliminated the lines corresponding to VOM being assigned to virtual charging and discharging when considering CRM. But, with hind-sight, I realized, I should've once clarified, if there are any other costs involved with or without CRM being considered. Please let me know. Otherwise, merging the PR should be good to addressing this issue.

[gmantegna]

@wilson-ricks this was intentional to prevent wild cycling of the virtual discharge for no reason (especially when crossover is off). We intentionally used the VOM cost for storage because this is generally set to a small and positive number to prevent similar unnecessary cycling in the real discharge. I understand this presents an issue for when you want to model a storage device with negative variable costs. One solution would be to have a separate "virtual charge and discharge penalty". What do you think?

[wilson-ricks]

Ok, I thought that might have been the reason. I wonder if rather than adding extra columns to the input files that don't represent a real cost, we could just hard code a very small cost for virtual charge/discharge to prevent this behavior. I don't anticipate it being something that would ever need to be changed.

…

On Fri, Jan 12, 2024, 9:55 AM Gabe Mantegna ***@***.***> wrote: @wilson-ricks <https://github.com/wilson-ricks> this was intentional to prevent wild cycling of the virtual discharge for no reason (especially when crossover is off). We intentionally used the VOM cost for storage because this is generally set to a small and positive number to prevent similar unnecessary cycling in the real discharge. I understand this presents an issue for when you want to model a storage device with negative variable costs. One solution would be to have a separate "virtual charge and discharge penalty". What do you think? — Reply to this email directly, view it on GitHub <#604 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AP7LSXLWXRYJNRKTUOENV73YOF2KBAVCNFSM6AAAAABBMANXOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBZG4ZDKMRXHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cfe316]

Rather than hard-coding it, it would be nicer to keep it as a Setting with a default value. Users don't need to specify all settings.

[gmantegna]

I agree with Jacob. This would be a very simple fix if someone wants to update the associated PR here. cc @lbonaldo @sambuddhac

[sambuddhac]

I will update. Thanks guys !!!

[JesseJenkins]

Will be addressed by #608

[sambuddhac]

This is now fixed on develop