I am updating the costs of power generation (ELCC & ELCD) in TIAM model, rendering the resolution infeasible. Apparently, this is due to the lower costs of solar (INVCOSTs have been roughly divided by 2) that make a capacity constraint no longer consistent. Here below is the UC, originally implemented into the model:
~UC_SETS: R_S: AllRegions ~UC_T: LO
UC_N PSET_PN Year LimType UC_NCAP UC_RHSTS UC_RHSTS~0 UC_Desc
A_MinGblPVNewCap ESOPV* 2020 1 50 1 Min New Sol PV Capacity - GLOBAL
2050 60
Running the model with the new costs, the infeasibility is that
LucasD> I do not understand why lower costs interfere and make this capacity constraint unfeasible.
Neither do I. Changing just cost coefficients in a model does not affect its feasibility (unless you also have constraints that are dependent on those cost coefficients, e.g. limits on investments). That is a well-proven fact.
So, I would only suggest you to check your constraints...
But what is this ERROR:
> Number of variables in conflict: 1
> lower: ERROR > 50
(15-12-2020, 07:01 PM)Antti-L Wrote: LucasD> I do not understand why lower costs interfere and make this capacity constraint unfeasible.
Neither do I. Changing just cost coefficients in a model does not affect its feasibility (unless you also have constraints that are dependent on those cost coefficients, e.g. limits on investments). That is a well-proven fact.
So, I would only suggest you to check your constraints...
But what is this ERROR:
> Number of variables in conflict: 1
> lower: ERROR > 50
The only other constraints I have are regional capacity constraints, minimum share of renewable electricity production, and maximum share of intermittent electricity production.
The ERROR thing appeared when I migrated to veda 2.0. Before migration, the error was stated as below
Number of equations in the conflict: 1. fixed: EQE_UCTS(A_MinGblPVNewCap,2020,ANNUAL) = 0 Number of variables in the conflict: 1. lower: VAR_UCTS(A_MinGblPVNewCap,2020,ANNUAL) > 50
So I do not understand the 'fixed' equation... At no time the model is forced not to invest in new ESOPV* capacities in 2020. On the other hand, the second equation makes sense because it merely translates the UC constraint I wrote on my first post.
You are right, the GAMS version is different: I moved from v4.3.2 to v4.5.0. But before I change the costs values, the model ran perfectly on both versions.
I agree the 'fixed' equation is fine but I cannot figure out where is declared this constraint within the model! Although I checked all the constraints related to ESOPV* under the Item Detail module of Veda 2.0. Here attached is the scenario file.
15-12-2020, 11:18 PM (This post was last modified: 15-12-2020, 11:38 PM by Antti-L.)
Very interesting: You even seem to have enabled dummy imports for UCs, and still get an infeasibility for the UC, which I guess should not be possible. Have you perhaps disabled the dummy imports (IMPNRGZ) in some other way? If not, it seems to me that you may have a serious problem somewhere else...
I could not find anything suspicious in the scenario file. One possibility is that the problem would somehow be related to FIXBOH. Is this model run using a previous solution for fixing first periods? If so, until which year?
Seeing the listing file (*.lst, zipped) might also be useful.
No, I have not disabled the dummy imports..
I honestly don't know if the model run using a previous solution (I think not)... The starting year is 2010 and the periods are correctly fixed in the SysSettings file.
What is really weird is that problem only occurs for the solar costs. Other changes on the power sector do not affect the feasibility.
Ok, if you have dummy imports enabled, then I am really very puzzled. The dummy import option should make the constraint always feasible.
Unfortunately, your GAMS listing file stops at the model statistics, which is strange. Did you edit the listing file, removing the part after model generation? It would be useful to see the full listing file... (even better if using the GAMS option OPTION SYSOUT=ON). One very long-shot possibility might be that the solution is actually not infeasible but for some reason unbounded... but then the Cplex report about equations in conflict would seem odd.
(If you feel totally lost with this problem, I offer to investigate the problem, in case you can provide me with the full set of input files (*.DD, *.RUN)).
I really thank for your concern and your proposal. I launch a battery of tests to deeper identify where is the problem and I'll get back to you to keep you informed and ask for your help.
17-12-2020, 09:00 PM (This post was last modified: 17-12-2020, 09:03 PM by Antti-L.)
Ahh... I just looked at the scenario file again, and it does indeed include a suspicious issue:
Although the dummy commodities 'A_MinGblPVNewCap-' and 'A_MinGblPVNewCap_' are defined there, the dummy import process IMPNRGZ is NOT defined to have the import flows for them (the TOP_IRE entries)! All the other constraints in that scenario do have the dummy TOP_IRE entries defined in the DD file.
This does explain why the constraint could have been infeasible even with the dummies included. However,
this may also suggest that these flows may have been already defined elsewhere in your model (or that VEDA2 has a bug here, not quite sure, but I think the TOP_IRE should have been defined in this file regardless).
Nonetheless it doesn't explain why the constraint would be infeasible in the first place.
