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

Veda Application Installation guide


Long run times w/ DSCINV, infeasible without
#1
Hello.
This model was working recently until I refined the initial condition using forced production in MIN processes in the VT_REG_PRI_REG file. Now the model taking an incredibly long time to solve - it's stuck at resolving conflicts in GAMS.  I'm using semi-discrete intervals.

If I disable discrete investment and remove DSCINV files, the model is infeasible even with dummy import processes enabled, and even upon relaxing the demand, and/or relaxing/removing the CO2 constraint. 

Could you please assist me in understanding what's going on?

Thanks
Reply
#2
Running the Cplex infeasibility finder immediately points out that your cumulative upper bounds for OLDPVS17, MINWND17, and MINNUC17 are all severely inconsistent with the ANNUAL lower bounds on activity for the same processes.

So, why have you defined these inconsistent bounds, and thus formulate an infeasible model?
Reply
#3
(12-12-2019, 03:37 PM)Antti-L Wrote: Running the Cplex infeasibility finder immediately points out that your cumulative upper bounds for OLDPVS17, MINWND17, and MINNUC17 are all severely inconsistent with the ANNUAL lower bounds on activity for the same processes.

So, why have you defined these inconsistent bounds, and thus formulate an infeasible model?


Thanks! Sorry for the late response. 

1. Can I run just the Cplex infeasibility finder by itself? I tried a few things but it didn't work.

2. I am trying to use CUM, STOCK and ACT_BND to prevent disappearance of the processes you mentioned. When I check VarFOUT and ELC, I notice that existing nuclear, wind and solar occasionally disappear, say at 2030, then reappear at 2035 at full capacity. So I was trying to create a reserve (CUM) for their typical lifetimes, and to enforce the production of a certain amount of these quantities (ACT_BND), additionally restricting their conversion to ELC using STOCK and retiring them gradually to get smooth transitions instead of abrupt appearance/disappearance of nuclear etc. However, this hasn't been successful in the past, and now it seems to be causing infeasibilities. Is my approach wrong? Could you please suggest a better way?

Thanks again.
Reply
#4
1. I am not sure what you mean by running it by itself. But if you have an infeasible model, you can run it automatically after Cplex identifies the model as infeasible by setting the option in the cplex options file.  See the Cplex user manual for details.

2. You can define almost any kinds of constraints on the process activity levels in TIMES, as long as they are linear in nature. If you want smooth transitions in the activity levels, it is up to you to formulate the constraints you want.  You can use activity bounds, availability factors, cumulative bounds, dynamic growth/decay constraints etc. and almost any kind of user-defined constraints involving any of the main variables.  But the solver expects that the constraints are mutually consistent so that the model is feasible.

Earlier, you seemed to be happy with using NCAP_AFA(LO) for existing nuclear (see this thread), but I can see you are no longer using that.

However, the infeasibilities I mentioned are not related to power plant technologies, but to energy supply (mining) processes. For example, when you defined an annual lower bound of 4800 for MINWND17 from 2017 onwards, and a cumulative upper bound of 129995.5 for it (ACT_CUM for the full model horizon), you should understand that you are simply violating the rules of logic (4800 × 84 = 403200 >> 129995).
Reply
#5
(09-02-2020, 09:02 PM)Antti-L Wrote: 1. I am not sure what you mean by running it by itself. But if you have an infeasible model, you can run it automatically after Cplex identifies the model as infeasible by setting the option in the cplex options file.  See the Cplex user manual for details.

2. You can define almost any kinds of constraints on the process activity levels in TIMES, as long as they are linear in nature. If you want smooth transitions in the activity levels, it is up to you to formulate the constraints you want.  You can use activity bounds, availability factors, cumulative bounds, dynamic growth/decay constraints etc. and almost any kind of user-defined constraints involving any of the main variables.  But the solver expects that the constraints are mutually consistent so that the model is feasible.

Earlier, you seemed to be happy with using NCAP_AFA(LO) for existing nuclear (see this thread), but I can see you are no longer using that.

However, the infeasibilities I mentioned are not related to power plant technologies, but to energy supply (mining) processes. For example, when you defined an annual lower bound of 4800 for MINWND17 from 2017 onwards, and a cumulative upper bound of 129995.5 for it (ACT_CUM for the full model horizon), you should understand that you are simply violating the rules of logic (4800 × 84 = 403200 >> 129995).


Thanks! I'll look into this, it should be extremely helpful.

I tried setting NCAP_AFA to realistic values but since it's basically the availability factor, all it did was change the output/activity levels. It did nothing to prevent the appearance/disappearance of nuclear from my VarFOut/ELC data. I've tried growth/decay rates, activity bounds, availability factors and cumulative bounds on the MIN processes. The problem still persists. That is, the STOCK/Capacity will retire gradually but output as seen in VarFout/ELC has random appearance/disappearance of wind, nuclear and solar. 

Am I missing something? Is it because the system is being asked to reduce emissions by 80%, which is resulting in odd solutions which involve shutting down nuclear all at once for 10 years then starting it up again for 3?

I see. When I did that, what I had in mind was that initial wind processes, for example, should have enough reserves for 25-26 years (their approx lifetime, not the full 84 y), and then have the old wind processes retire and be replaced by newer onshore (MINWON) or offshore (MINWOF) processes. But I guess that's not permitted - and the reserves must be enough for the entire time horizon?
Reply
#6
I don't quite understand your statements about appearance/disappearance of nuclear/wind/solar from your VarFOut/ELC data.

For example, if you set NCAP_AFA(LO) = 0.5, the output of the process simply cannot appear/disappear randomly.  It will be forced to be at least 50% of the annual full load production, in proportion to the capacity.  And so, if your capacity is smoothly decreasing (retiring) as you have said, the output will also be forced to be decreasing rather smoothly (it will be always between 50% and 100% of the remaining full load output).  I don't see how the output could ever be disappearing if you use NCAP_AFA(LO), unless your capacity goes to zero. Can you explain how that would be possible, if you set a minimum utilization factor of e.g. 50%?

Perhaps you have been using just AFA, which means NCAP_AFA(UP), and not NCAP_AFA(LO)?
Reply
#7
Ahh... I just discovered that the model you posted above is three years old.  All the *.DD files and the *.RUN file have been generated in January 2017! And of course that's the model I tested, finding out that your model is infeasible.

However, all the discussions on this Forum about your models (e.g. this thread) have been after that time.  In fact, your first post on this Forum is from 2018, but your model is even older than that.  I think it is therefore also obvious that you cannot have tried anything in this model based on the Forum discussions, because the model is such an old version from 2017.

I can also see that there are no NCAP_AFA(LO) parameters at all in this model, and there are no dynamic constraints at all, and specifically, there are no growth/decay constraints.  So, although you say that you have tried all these, there is no trace of any of that in your model...   I am rather baffled.  Confused
Reply
#8
(11-02-2020, 04:20 PM)Antti-L Wrote: Ahh... I just discovered that the model you posted above is three years old.  All the *.DD files and the *.RUN file have been generated in January 2017! And of course that's the model I tested, finding out that your model is infeasible.

However, all the discussions on this Forum about your models (e.g. this thread) have been after that time.  In fact, your first post on this Forum is from 2018, but your model is even older than that.  I think it is therefore also obvious that you cannot have tried anything in this model based on the Forum discussions, because the model is such an old version from 2017.

I can also see that there are no NCAP_AFA(LO) parameters at all in this model, and there are no dynamic constraints at all, and specifically, there are no growth/decay constraints.  So, although you say that you have tried all these, there is no trace of any of that in your model...   I am rather baffled.  Confused


Thanks. I think as you said in the previous post, perhaps AFA(UP) was implemented or NCAP_AFA(LO) wasn't implemented properly.  I'm sorry about my oversight, it's quite embarrassing.

I've been away from this project for a while and multiple people have worked on this model so I am having some trouble retracing my and their steps. And I may have shared/been working with the wrong model, or my model may have been changed in my absence.

As for the time and date, I am not sure, perhaps someone was unintentionally using a computer with the wrong time, we've had that issue with some old desktops. I'll follow up with the correct model when I can resolve some other problems I am having with running VEDA-FE. Thanks again.
Reply
#9
For future readers' reference: AFA(LO) fixed my problems, it was defined incorrectly in a different model's TFM~INS table.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)