Full Version: Could NCAP_AFC be defined on TS set?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Vangelis Wrote:Do you think that it is feasible to have the NCAP_AFC parameter defined on TS set instead of TSLVL set?

An advantage would be that by doing this the NCAP_AFC could be used in the same way that AFS is used and thus it increases the flexibility in modeling as we have a similar functionality with AFS for commodity-specific availability factors.

I am not sure what is the exact motivation of the proposed change. Already now, the availability factors defined via NCAP_AFC are multiplied by the AF/AFS/AFA values (using the standard default value=1, if not specified). That makes it reasonably easy to define timeslice-specific availabilities also when using NCAP_AFC. However, the obvious limitation is that the timeslice-specific multipliers (AF/AFS) are not commodity-specific. Therefore, if you are specifically referring to this limitation, then I do understand the motivation for the proposed change, but it would still be nice to see some real-world examples where you would indeed need a full matrix of timeslice and commodity-specific availabilities, and where the current approach, where the timeslice and commodity-specific vectors are multiplied, thus does not suffice.
Vangelis Wrote:I think that a possible application of such an extension could be considered for storage. For example in normal processes one can specify through AFS operational constraints related to capacity/activity availability across timeslices, which can be translated to capacity/commodity availability as well if the activity is the same as the output commodity flow. In storage processes a similar functionality can be achieved through other approaches, as the activity has a different meaning in them. I think that by having the NCAP_AFC on timeslices set, then the introduction of constraints related to capacity/commodity availability for storage processes can be simplified. 

What do you think?

Ok, I am sure this can be considered. But to get a better picture of the desired functionality, could you also give some more detailed example(s) of the various operational constraints needed for storage processes that would be simplified by the extension?

[EDIT:] Ok, I have now verified that this can be reasonably implemented. I hope to include this generalization in the next version. You would then be able to define timeslice-specific availability factors separately for the storage output flows, the storage input flows, and the storage activity, all at any timeslice. However, lower bound availability factors can still be only specified for the activity, like now. And of course, there is only a single capacity variable for each vintage, and so the assumption is that the charging, discharging and storage capacities are all proportional to the single capacity variable.

Thank you very much Antti. The way you described it meets perfectly the need. This will simplify the modeling of storage demand technologies in models with a large number of timeslices, such as electric vehicles.

TIMES v3.8.3 is now available.

Have a look and see whether or not the generalized NCAP_AFC works as you expected.