Download the latest version of VEDA-FE (45834) and VEDA-BE (492018)

Veda Application Installation guide

Synchronous charging and discharging.
Dear All,

This is my first post ever on this forum, usually I find answers on the issues that I face in the use of TIMES.
Unfortunately the issue that I face this time, seems not to have been discussed before.

How can I avoid Synchronous charging and discharging  of a STG process?

Thank You
Philip Siakkis
I assume you mean simultaneous charging and discharging at the same time?
Usually, that should not occur in the optimal solution, if you have at least:

• Some STG_EFF < 1 defined for the storage operation
• At least some small costs on either the input or output flow

However, if you have such defined but still see simultaneous charging and discharging, then I guess you have some other constraints that become more easily satisfied when simultaneous charging and discharging occurs, and that is the reason for such a storage operation.

In general, the only definite way of preventing simultaneous charging and discharging is to predefine the timeslices that can be used for charging and discharging. If that is reasonable, then you can just bound the corresponding input/output flows to zero when charging / discharging should not occur. But otherwise, if the charging/discharging pattern should be fully optimized, it is not possible to formulate the requirement that (input ≥ 0 AND output = 0) OR (input = 0 AND output ≥ 0), because it is a non-convex, non-linear condition.

Nonetheless, there are various ways to improve the process representation in order to minimize any undesired effects of simultaneous charging and discharging flows, for example:

• By defining availability factors on the output / input flows, or both
• By restricting the output flows to be at most the amount stored at the beginning of the timeslice
• By removing the input / output flows from constraints that become more easily satisfied by simultaneous charging and discharging (e.g. market share constraints)

I think I would be able to suggest some improvement if you would give more information:

• What kind of a storage is in question (timeslice storage / general storage / inter-period storage)?
• What are the input / output commodities and their timeslice levels?
• What are the process parameters (screen capture from Process master → Data)
• Are there any user-constrains directly or indirectly referring to the storage flows, and if so, what is the purpose of these constraints? For example, any user-constraints referring to VAR_COMPRD(com) or VAR_COMNET(com) would indirectly refer to the storage output flows of com.
• Explain why you want to "avoid synchronous charging and discharging" in the first place (i.e. what is the problem)
Dear Anti,
Thank you for your quick reply and the initial comments and guidelines on what information could be helpful. YES I meant simultaneous charging and discharging.
I think it would be helpful to explain the model aim and structure before answering your questions.
The aim of the model is to study how curtailment of Wind and PV electricity can be minimized by adding a utility size Battery. 
At a second step it will be used to investigate the storage requirements in order RES penetration to reach 60 or 70% on annual base.
For system stability reasons the utility is supposed to allow up to 50% Res share at TimeSlice level, which in my model has duration of 1 hour.  However if electricity comes from the Battery, no limit exists apart from what is dictated due to technical minimum of thermal units, modeled with ACT_MINLD.

WIND, PV and THERMAL processes produce ELCWND, ELCSOL and ELCHIG respectively
An Aggregating process has ELCWND and ELCSOL as input and ELCHIG as output
FDEMELC is the single DMD process consuming ELCHIG.

A UC allows up to 50% of ELCHIG coming out of the Aggregating process to be absorbed by the grid, the rest, if any, can be either stored or exported at a very low price. Exports are included for monitoring reasons only.
The “BATTERY” part is consisted of 3 proceses:
The Charger, the BAT (STG) and the discharger.
INVRTR, the charger has ELCWIND and ELCSOL as INPUT and ELC4STG2 as Output,
The Battery named BAT (ELE,STG,STS) has ELC4STG2 as PCG defined as Comm-In and also the Auxiliary ENV commodities AUXBAT_In, AUXBAT_Out further defined by using FLO_FUNC attribute like I saw in your Demand Response example.  Its efficiency is 90% (STG_EFF=0.9).
Finally, the discharger named BAT2GRID, has ELC4STG2 as input and ELCHIG as output.

Several more UCs exists:
1st UC binds the INVRTR output with the BAT Input (by using the auxiliary com AUXBAT_In)
2nd UC binds the BAT Output (by using the auxiliary com AUXBAT_Out) with the Discharger Input
3rd UC is used to safeguard that Charger and discharger capacities are the same.

My Battery in this model has a very small cost of 26000€/MWh by setting: NCAP_COST=250000 and NCAP_AF = 0.003 and Capacity unit to KW. Am I correct?

As you understand Anti, setting charging and discharging TimeSlices is not an option, definition of availability factors is not an option too.
By removing the constraint that indirectly leads to simultaneous charging and discharging, practically I will not have any storage requirement anymore.

The reason I want to avoid simultaneous charging and discharging is that I am afraid that the storage capacity will be overestimated.
Oopps, I now realize that as long as charging and discharging occurs at the same TimeSlice, the net charge load will be taken into account and there won’t be any overestimation…
Perhaps the Charging and discharging processes will be overestimated but I can live with this.

Thank You Anti
Ok, the storage interactions appear to be somewhat complex here. If I understand correctly, the simultaneous charging and discharging is caused by the 50% Res share limit, which can be overridden by the model using the BAT route.

I have only the following suggestions:

1) Check that your cost and availability parameters for the BAT technology are correct. The investment cost of 26000€/MWh is indeed very small, but I am not able to see how 26000€/MWh would correspond to NCAP_COST=250000 and NCAP_AF=0.003 assuming the Capacity unit is KW. For example, assuming that the currency unit is M€ and the flow unit is PJ, and that we use GWh as the unit for the storage capacity of BAT, the following parameters would be correspond to an investment cost of 26000€/MWh:

NCAP_COST(BAT) = 26           !   26 M€ / GWh
PRC_CAPACT(BAT) = 0.0036      !  0.0036 PJ/GWh
NCAP_AF(BAT) = 1              !  allow max. 1 GWh to be stored in a 1 GWh capacity

2) Because you specifically wanted to avoid simultaneous charging and discharging, I suggest bounding the output flow to at most the amount stored in each timeslice. That would be a valid inequality if the input flow would be zero in that timeslice (which is the condition you wanted), but could be easily violated in other cases without the constraint.

3) I would also suggest to bound the VAR_COMNET(ELCHIG) variables to zero, unless you have already ensured that by some other means.

Thus, I would suggest trying the following parameters:
Thank You Anti for the suggestions,

It seems that NCAP_AF(BAT) must be equal to 1/365 to get the correct storage capacity. Is this due to the 8760 TimeSlices and DAYNITE level of the storage process or just due to the DAYNITE nature of my storage process?

PS. The investment cost of 26000€/MWh is just for testing reasons.
PS2. I plan to remove the STG_EFF from the storage process and allocate it to the Charging and the discharging Processes.

Thank you once again
No, I think it certainly should not be 1/365.

If you indeed have 8760 DAYNITE TimeSlices under a single parent timeslice (ANNUAL), then you are departing from the TIMES default assumptions. The default assumption is that each DAYNITE cycle corresponds to a representative day under its parent timeslice, and that in total there are 365 days in a year. Thus, if you indeed have all those 8760 DAYNITE TimeSlices under a single parent timeslice, TIMES assumes by default that in the full year there are 365 days, which are all similar to that single cycle of 8760 timeslices.

But obviously that is not what you want, and therefore you should set G_CYCLE(DAYNITE)=1 to indicate that in your model the single DAYNITE cycle is in fact the full year, and not a representative day. The default value of G_CYCLE(DAYNITE) is 365. Thus, instead of dividing NCAP_AF(BAT) by 365, you should set G_CYCLE(DAYNITE)=1, because otherwise the actual length of your timeslices is not correct: your hourly timeslices would be assumed to last only for 1/365 hours = 9.9 secs. The correct length of the timeslices is important for e.g. ramping contraints, start-up times etc.

Forum Jump:

Users browsing this thread: 1 Guest(s)