Veda2.0 Released!


Lst file does not show th equations generating the infeasibility
#1
Hi,
 I am running a TIMES model and VEDA-FE indicates that the model is infeasible. We have already observed that this is due to some user constraints we added, since TIMES returns an optimal solution when we remove these constraints. However, we do not know specifically which equation generated this problem. The weird thing is that the lst file does not show which equations are generating this infeasibility, as it usually does.

I am sending attached the following files:

 - The scenario file with the user constraints that are generating this problem (Scen_PWR.). We have also noted that the problem seems to be in the "ACTIVITY" sheet, since TIMES works if we remove it.

-  The lst file of the case.

Another doubt: there are lines in the lst file in which we can read "0       (OLD LEVEL ****)". They are associated with some user constraints of the case. What do them mean?

Thank you,
 Marcelo Resende


Attached Files
.xlsx   Scen_PWR.xlsx (Size: 75.83 KB / Downloads: 4)
Reply
#2
Tools - User Options - Import Settings - Create Dummy section - check "Variables for UCs"
Reimport the UC scenario after doing this.

The model will be feasible and dummy imports will point you to the problematic UC.
Reply
#3
(20-12-2017, 10:33 PM)AKanudia Wrote: Tools - User Options - Import Settings - Create Dummy section - check "Variables for UCs"
Reimport the UC scenario after doing this.

The model will be feasible and dummy imports will point you to the problematic UC.

I have just tried to do that, but now VEDA indicates "unexpected termination of run" instead of infeasibility. If I remove the file Scen_PWR, it works properly.
Reply
#4
Please send the LST file from this run.

By the way, as you UCs are for single processes, you could specify NCAP_BND and ACT_BND instead, in a ~TFM_INS table. UCs would have been necessary if you wanted to apply these NCAP/ACT bounds on groups of processes... giving the model freedom to choose within those groups.

Are you sure that these processes are not constrained in a conflicting way in another scenario?
Reply
#5
(21-12-2017, 12:11 AM)AKanudia Wrote: Please send the LST file from this run.

By the way, as you UCs are for single processes, you could specify NCAP_BND and ACT_BND instead, in a ~TFM_INS table. UCs would have been necessary if you wanted to apply these NCAP/ACT bounds on groups of processes... giving the model freedom to choose within those groups.

Are you sure that these processes are not constrained in a conflicting way in another scenario?

I am sending the .lst attached. The ideia of using bounds seems a good one, but I believe that it shouldn't modify the results. The other scenarios files we are using do not contain the Processes that are in Scen_PWR, so I dont believe so


Attached Files
.txt   ForumDuda_2.txt (Size: 130.77 KB / Downloads: 4)
Reply
#6
I have discovered the problem: the user constraint's names were too big. Specifically, the problem was with the constraints UC_DIESEL_DIESEL_BX_PWR_XXX_XXXX and UC_PULVERIZEDCOALPP_CARBON_XXX_XXXX. I don't know if a limit for the constraints' names are desirable. It took a lot of unnecessary effort to discover this error.

Thank you!
Reply
#7
Yes, for GAMS the maximum length of labels is 63 characters long, while in VEDA-FE the length apparently may be usually restricted to 32 characters. Unfortunately, I believe that VEDA-FE does not really have a relational database design, which means that increasing the maximum length could have a notable adverse impact on the database sizes and performance.

Therefore, if you would like this to be changed, I would strongly suggest that the max. label length be made user-configurable, such that users who are happy with the current lengths would not have to bear with any performance degradation. In fact, the maximum label length is user-configurable in ANSWER (the competing shell), but it has neither been supporting any more than 32 characters for them.
Reply
#8
Thanks for the input Antti. We will see if we can address your request, but in the meantime, we will start issuing clear messages in SYNC logs if any of the names provided by the user are getting truncated.
Reply
#9
Sorry for using misleading wording:
I am not requesting any change here, but only suggesting that if you should consider pursuing such a change, increasing the maximum label length (up to 63 characters), it should best be made user-configurable.  Shy
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)