NCAP_AFCS parameter not recognized

[Sandro_Luh]

Dear experts

I just tried to implement a charging profile for a battery into my model, which defines for each timeslice (hourly) the maximum availability. For this, I tried to apply "NCAP_AFCS" as it is defined in the documentation (see image 1, lower row)

When I synchronize my model, I get an error message that says that the file which includes the NCAP_AFCS data is empty. VEDA gives me the error "VI: Parameter: NCAP_AFCS not recognized; Ignored." (see image 2)

I don't understand why the NCAP_AFCS parameter is not recognized. 
I use the VFE-version 4.5.834 and I realized that NCAP_AFCS can also not be found in the Attributes Master. However, other posts in this forum indicate that NCAP_AFCS is not a novel feature and thus I don't think it has anything to do with my VEDA-version.

Perhaps, I defined something wrong in the input table? In image 3, I provide a screenshot of the first rows of the table

I would appreciate any feedback and am happy to clarify if something remained unclear.

Thanks,
Sandro

[Antti-L]

I think NCAP_AFCS was never supported under VEDA-FE, because it was not needed.  You can use NCAP_AFC for the same purpose; it accepts both timeslice levels and timeslices.

[Sandro_Luh]

Dear Antti

Thanks for your prompt reply. I will try to move forward with using NCAP_AFC for my intended purpose. If any further related issues occur, I will get back to you.

Thanks,
Sandro

[Antti-L]

Ahh, but looking at the screenshot more closely, it seems you are trying to define zero values for NCAP_AFC, is that true?  If you want to disable storage flows in such a way (for certain timeslices), it would be better to define zero STGIN_BND / STGOUT_BND instead, or use PRC_FOFF.

[Sandro_Luh]

Thanks for pointing this out. Indeed, in the screenshot all values were 0. However, this had only the purpose to easily test if the table provides the outcome that is intended. Usually, these values will not be 0 in my model.

[Sandro_Luh]

Dear Antti

I want to get back to you regarding my issue with the NCAP_AFC implementation. I tried already to help myself based on another thread (here), but unfortunately, it didn't succeed in my model yet. Probably I am overlooking an important aspect, so I would highly appreciate your help.

I have a model with electric cars, batteries within such cars, and the respective charging infrastructure to charge these batteries. I distinguish by three different types of charging infrastructure: slow charging at home (HC7kW), commercial public charging (PC22kW), and rapid public charging (PC150kW). In the first attached figure, you find a scheme of the relevant part in my model.

Now, I would like to use NCAP_AFC on an (hourly) timeslice level to control at which times how much electricity can flow from a specific type of charging infrastructure into the battery of the car. For example, I would like to implement a charging profile for home charging infrastructure, which reflects that electricity can only flow at times when the car is standing at home (I have data available for the times when the car stands at home). 
For this, I tried to implement a NCAP_AFC that connects the T-ELC-TC_Bat process with the individual input commodities T-ELC-car_HC7kW, T-ELC-car_PC22kW, and T-ELC-car_PC150kW, respectively. For testing purposes, I have set the values for each timeslice to 0 to see if the model implements the constraint correctly (second screenshot), but once I know that it works, I would not use 0-values anymore. In the third and fourth screenshots, you find the summary for the relevant process and commodity from the Master-overview in VFE, respectively. 
Please ignore the "_BHIO_Sx" in the naming convention when comparing the names to the schematic visualization of figure 1, as I left this part of my naming convention away to keep it more simple.

I also found in the EQ_CAFLAC equation of the .lst file that the defined NCAP_AFC is currently not entering the equation.

I hope this describes my problem well, but I am happy to provide more information if necessary. 
If this might be more efficient for you, I would also be available for a video call with screen-sharing.

I look forward to hearing from you.

Sandro

[Antti-L]

I think I told you already before that defining zero NCAP_AFCs is not recommendend, because there are better ways to disable process flows in certain timeslices, or all.  In fact, as you noted, the EQ_CAFLAC equations cannot be supported for zero NCAP_AFCs, because they would cause a divide by zero.  Instead, EQL_CAPFLO equations are then also generated for NCAP_AFCs, and these can employ the zero value (without any divide by zero).  So, your zero NCAP_AFCs actually result in two sets of equations to be generated:  The EQ_CAFLAC equations (using values of 1 or INF), and the EQL_CAPFLO equations. As you can see, using zero NCAP_AFC is not only inadvisable, but also quite inefficient in terms of modeling. Nonetheless, it does work, do you not agree? (I cannot see from your post any evidence that they would not actually disable the flows.)

I hope that was answering your question?

[Antti-L]

Ah, very sorry, I didn't realize that you are actually defining those NCAP_AFC for the non-PG flows!  That is a bit unusual, but indeed that is also supported.  I can see that your PG is the output, while you seem to be defining NCAP_AFC for the input flows.

Ok, then there will not be any EQ_CAFLAC equations for these availability factors, but only EQL_CAPFLO equations.  And the divide-by-zero issue is not relevant there. 

So, what seems to be the problem then? I think those NCAP_AFC should work as expected. But how do your availability factor parameters for the PG look like?

Anyway, as the process is a standard process, with a given output profile, the charging load curve remains the same regardless of the input shares, correct?

[Antti-L]

> I hope this describes my problem well, but I am happy to provide more information if necessary.

Just to recapitulate, I am so sorry, but I could not really see what the problem is that you are seeing. The only problem I could identify from your description was that the defined NCAP_AFC is not entering the EQ_CAFLAC equation, but that is as expected, because those flows are not in the PG of the process. As mentioned above, they therefore enter the EQL_CAPFLO equation instead.

[Sandro_Luh]

Dear Antti

Thank you for putting so many thoughts into this. Let me try to go through your comments one by one to clarify and add some insights: 

I think I told you already before that defining zero NCAP_AFCs is not recommendend, because there are better ways to disable process flows in certain timeslices, or all.  In fact, as you noted, the EQ_CAFLAC equations cannot be supported for zero NCAP_AFCs, because they would cause a divide by zero.  Instead, EQL_CAPFLO equations are then also generated for NCAP_AFCs, and these can employ the zero value (without any divide by zero).  So, your zero NCAP_AFCs actually result in two sets of equations to be generated:  The EQ_CAFLAC equations (using values of 1 or INF), and the EQL_CAPFLO equations.

This provides some useful insights. For comparison reasons, I did run my model with zero-values and with non-zero-values for the NCAP_AFC on timeslice level (hourly values) and analyzed the equations that my model generates. 
As you wrote in your second post, I can confirm that CAPFLO equations are created but CAFLAC equations are not created. However, the CAPFLO equations in the .lst file do not contain the processes for which I have defined the NCAP_AFC. Thus, I think the defined NCAP_AFC is not entering the CAPFLO equations in my case.

As you can see, using zero NCAP_AFC is not only inadvisable, but also quite inefficient in terms of modeling. Nonetheless, it does work, do you not agree? (I cannot see from your post any evidence that they would not actually disable the flows.)

Unfortunately, I cannot agree - at least this is not what I experience in my model. Probably I was not clear enough in my initial post, but this is exactly the problem: I still see a flow in the results, even though I set the NCAP_AFC values for each timeslice to 0 (like in the attached image 1). To be specific, I still see in the results that the attribute "VAR_Fin" of the process "T-ELC-TC_Bat" for the commodity "T-ELC-car_PC150kW" is not 0, but 1.36.
On a sidenote, I tested to set the NCAP_AFC values to a very low value (0.00001) but received the same results.

Ah, very sorry, I didn't realize that you are actually defining those NCAP_AFC for the non-PG flows!  That is a bit unusual, but indeed that is also supported.  I can see that your PG is the output, while you seem to be defining NCAP_AFC for the input flows.

Ok, then there will not be any EQ_CAFLAC equations for these availability factors, but only EQL_CAPFLO equations.  And the divide-by-zero issue is not relevant there. 

Exactly, I can confirm that I want to define the NCAP_AFC for the input flows. Those input flows are indeed not part of the PCG, which is the output flow. 
Accordingly, I can also confirm that I see in the .lst file for both cases (NCAP_AFC timeslice values as 0 and as non-0) that no CAFLAC equations are created, but CAPFLO equations are created.
However, as outlined above, the CAPFLO equations in the .lst file do not contain the processes for which I have defined the NCAP_AFC. Thus, I think the defined NCAP_AFC is not entering the CAPFLO equations in my case.

So, what seems to be the problem then? I think those NCAP_AFC should work as expected.

As written before, the defined NCAP_AFC does not show any impact on my model. I have also tried to use a simplified model with only one Battery car, which can potentially use the three available charging infrastructure types outlined in the schematic overview of my first post. For each of the 3 flows (T-ELC-car_HC7kW, T-ELC-car_PC22kW, and T-ELC-car_PC150kW) I have set the NCAP_AFC values to 0, expecting that the model becomes infeasible because no electricity can flow to the car anymore and in consequence the car cannot fulfill the demand. However, also in this case the model works, and I see in the results that each of the 3 flows are "active", i.e. they have not 0 but have exactly the same values like when the NCAP_AFC is not defined. I have also tried to use values different from 0 for the NCAP_AFC, but still there is not impact at all on the results

But how do your availability factor parameters for the PG look like?

I am not sure which PG you mean...? Are you referring to the PCG of "T-ELC-TC_Bat", which is its output commodity "T-ELC-car-BatSTGin" (as shown on the previously posted screenshot of the process master)? If yes, this output commodity is not bound with any availability factor. Basically, all the electricity flow that enters the process "T-ELC-TC_Bat" from the 3 input commodities that represent the different types of charging infrastructure (T-ELC-car_HC7kW, T-ELC-car_PC22kW, and T-ELC-car_PC150kW) can immediately move further to the output commodity "T-ELC-car_BatSTGin". The process "T-ELC-TC_Bat" serves rather as an aggregator of the different electricity flows before the electricity can enter the battery of the car.

Anyway, as the process is a standard process, with a given output profile, the charging load curve remains the same regardless of the input shares, correct?

As outlined above, the process "T-ELC-TC_Bat" does not have a defined output profile.

Just to recapitulate, I am so sorry, but I could not really see what the problem is that you are seeing. The only problem I could identify from your description was that the defined NCAP_AFC is not entering the EQ_CAFLAC equation, but that is as expected, because those flows are not in the PG of the process. As mentioned above, they therefore enter the EQL_CAPFLO equation instead.

In essence, for some reason the defined NCAP_AFC values do also not enter the EQL_CAPFLO equation, and they don't show any impact on the results of the model. From your previous answers, I understand that it is rather uncommon to define the NCAP_AFC for the individual input commodities of a process...?
Perhaps, you would recommend an entirely different approach for implementing the NCAP_AFC into my model?

[Antti-L]

> In essence, for some reason the defined NCAP_AFC values do also not enter the EQL_CAPFLO equation, and they don't show any impact on the results of the model.

Ok, now you are more clear about reporting the problem.  Of course, if you get no EQL_CAPFLO equations for NCAP_AFC defined for non-PG flows, then there is no way those NCAP_AFC parameters could have an impact. The only impact is through these equations.  I assume the processes have a capacity variable, which is of course required for these flow-capacity equations to be generated?

But anyway, as I cannot see such a problem in my own tests, when using NCAP_AFC defined for non-PG input flows, I would need to see a reproducible case.  Could you therefore please provide such a case?  I mean the *.DD and *.RUN files for a test model that manifests the problem (no EQL_CAPFLO equations when you define NCAP_AFC for a non-PG flow), so that  I can run that test model myself and investigate the issue.

So, it would be very helpful if you could just make a a small test model reproducing the issue?  Or, if that seems too difficult, provide me with the *.DD and *.RUN files plus the listing file from any model case which you have, and which reproduces the problem.

[Sandro_Luh]

I am glad that the issue is now more clear.

Attached I am providing a minimalistic version of my model that should reproduce the experienced problem. The file "xt_8clu_bat-chargeprofilebevs_0.dd" contains the defined NCAP_AFC values, as you saw in the table of my previous screenshot. The NCAP_AFC is supposed to "block" the electricity flow of the "T-ELC-car_PC150kW_GHIT" commodity, so the electricity can only arrive via "T-ELC-car_PC22kW_GHIT" or "T-ELC-car_HC7kW_GHIT" to the process "T-ELC-TC_Bat_GHIT_S3".
Just let me know if a file might be missing.

I look forward to hearing from you.

Thanks again for your efforts,
Sandro

[Antti-L]

A listing file would have been helpful, to see your version of TIMES and GAMS.

But anyway, running the test model immediately revealed the cause of your problem:  The process T-ELC-TC_Bat_GHIT_S3 does not have any capacity. (The only equations it was participating were the EQ_COMBAL equations and the EQE_ACTEFF equations.)

And therefore, you cannot meaningfully define availability factors, because availability factors define the availability of the capacity, normally for producing the process main output(s), i.e. the activity, but sometimes also for other process flows.  For example, charging power level constraints of storage processes can be defined with NCAP_AFC availability factors, because they can be interpreted as availability factors of the capacity, for the input flow levels of electricity in proportion to the capacity.

I guess this is a notable misunderstanding about availability factors in TIMES: Any availability factors in TIMES always require a capacity, such that the activity / flow levels can be bounded by that capacity.  If there is no capacity, what are you expecting to be binding the flow? 

However, fixed availability factors for the PG actually do implicitly activate capacity variables, because then one does in fact have a well-defined capacity. So, that would be one implicit way of creating capacity variables, but in your case that does not seem to make sense either, due to the nature of your process.

[Sandro_Luh]

Dear Antti

Thanks a lot for sharing your useful observations. The .lst-file must have slipped through when I created the .zip - sorry about that. Your reply gave some clarity and helped me to improve my understanding of the underlying concepts. I've also revisited the CAFLAC equation in the documentation to understand better which parameters influence this equation.

The process  T-ELC-TC_Bat_GHIT_S3 did not have a capacity, as this process was intended to serve simply as an aggregator-process that allows me to easier handle the outputs of the different E-charging infrastructure types and the input into the battery of BEVs. But probably there are better/cleaner ways to implement this in the model and your reply made me rethink how I can solve in my model what I would like to see...

What I intend to implement in my model: 
BEVs can only use home charging when they are indeed at home and only use public charging when they are parking on a public parking lot, for example. For instance, there are in total 100 BEVs from which at 1 o'clock in the morning 90 cars are standing at home and 5% stand at a public parking lot. Then, at 1 AM, a maximum of 90% of the fleet can access the home charging infrastructure, and a maximum of 5% of the fleet can access the public charging infrastructure. So, the idea was that at the 1 AM timeslice a maximum of 90% of the total BEV-capacity can receive electricity from home charging infrastructure, and a maximum of 5% of the total BEV-capacity can receive electricity from public charging infrastructure. This should then provide an hourly pattern of which share of BEVs could be charged at each charging infrastructure type, i.e. which share of BEVs has at each hour access to which charging infrastructure type (based on the location where the cars are at that hour, which comes from exogenous data).

Thoughts for resolving this:
As the T-ELC-TC_Bat_GHIT_S3 process is simply an aggregator process without a "physical" meaning in the real world, I considered now removing this process and making the outputs from the charging infrastructure (D-T-ELC-car_HC7kW, D-T-ELC-car_PC22kW, and D-T-ELC-car_PC150kW) directly the inputs to the battery T-Bat-BeV-STG_S3. The battery process T-Bat-BeV-STG_S3 has a capacity [GW] and when then the NCAP_AFC is applied for this, the capacity of the battery would basically serve as a proxy for the capacity of the BEVs, because the capacity of cars (#cars) and the capacity of batteries (battery size) are linked in my model.

But would this really fulfill my intended purpose...?: 
However, after experimenting with this new approach and trying to understand the details of the created equations, I am not certain if this really fulfills my intended purpose. If I understand the CAFLAC equation and the definition of STG-processes correctly, the RHS of the CAFLAC equation basically gives for each timeslice the (maximum) total activity of the process (Capacity * Availability Factor * CAPACT), which is for an STG process the maximum amount of energy that can be stored in that process. But I don't want to limit how much energy can be stored in a given timeslice, but I aim to limit how much energy can be added to the storage in that timeslice. Thus, I am still not certain about the ideal approach for implementing what I would like to see in the model...
However, perhaps I have also still a misunderstanding of the meanings of this equation...? Or would you perhaps recommend an entirely different modeling approach to fulfill my aim?

I am very curious to hear your thoughts. Thanks again for your help and support!
Sandro

PS: Alternatively, to the new approach outlined above, I could perhaps also keep the T-ELC-TC_Bat_S3 and add a UC that links the capacity of T-ELC-TC_Bat_S3 and the respective BEV-car. Thus, the capacity of both processes would be identical and represent the number of BEV cars. When I apply now the NCAP_AFC in the same way like in the previously provided model files, then the NCAP_AFC would (indirectly) be applied to the capacity of the cars. But also in this case, I am still not sure if the NCAP_AFC would really replicate what I am intending to implement in the model...

[Antti-L]

> If I understand the CAFLAC equation and the definition of STG-processes correctly, the RHS of the CAFLAC equation basically gives for each timeslice the (maximum) total activity of the process (Capacity * Availability Factor * CAPACT), which is for an STG process the maximum amount of energy that can be stored in that process.

No, you have not understood it correctly.  In fact, as described in the documentation (Part II), it is quite the opposite.  For a storage process, it is the standard NCAP_AF parameter (without using any NCAP_AFC), which gives for each timeslice the (maximum) total activity of the process (Capacity * Availability Factor * CAPACT). So, by using NCAP_AF alone you can define the maximum amount of energy that can be stored (≈max. activity level). But if you define NCAP_AFC on the input / output flows, or for the PG commodity type, it will then limit the input / output flow level(s) instead, just like I told in my post above. So, it will be bounding the charge / discharge power level, and not the amount of energy stored. It is obvious also from the equation description for EQ(l)_CAFLAC. And if desired, you can also define those constraints independently for each PG commodity flow if desired, as for non-PG flows (EQL_CAPFLO).

Hence, it seems you did you not read the documentation after all?    See section 4.3.7 Availability factors for storage processes, which describes what I said above, and EQ(l)_CAFLAC, where you can see that VAR_ACT (≈the amount of energy stored) is not referred to at all by that equation.

Anyway, concerning your modelling problem, I am sure you can model what you are intending in TIMES, as long as the relations can be written in terms of linear constraints, operating on the variables you have in your model.  But from your description, I am not able to see what the formulation of those constraints should look like. Therefore, I would suggest that you write them down first. But maybe there are some other Forum members who can help you already on the basis of your description.