User Constraint not Binding

[Antti-L]

You could use the OFFEPS VEDA attribute (or the $OFFEPS GAMS directive with the SFCmd_T attribute) and then define zero values for the UC_RHS*(...,bd) attributes that you had active. Doing so would remove those constraints (because the UC_RHS* constants would be "nulled" out).  Alternatively, you could use the TS filtering mechanism in VEDA, which I think is even easier to use but it works only for time series attributes (filtering out the whole UC_RHST/RHSTS/RHSRT/RHSRTS time series).

However, if you are additionally wishing to have those constraints still in the model as non-binding ones, then you would need to define some (non-zero) UC_RHS*(...,'N') values as well.

Of course, with a list of UC names defined as a GAMS set, it would be equally easy to do it all within GAMS, with a few assignment statements.

I have also felt the need for an easy way of deactivating UC constraints, and so perhaps it might even be useful to consider implementing some additional mechanism for it in TIMES... ?

[AKanudia]

All good ideas. My preferred way is the first one. One can also use a TFM_INS table (without OFFEPS) with the user constraints listed under uc_n column header to introduce a UC_RHS*(...,'N') value, so that you don't have to deal with multiple periods.

On your last point, how about introducing a new interpolation option that deletes a timeseries? This would be great for deactivating FX attributes too.

[VictorG]

Thank you both for your replies, I managed to make Antti's first suggestion work with my model.

I find it not so intuitive though, a simpler way to turn on/off constraints would be useful. I can see the potential for a user who wants to define in bulk constraints and then only activate subset of these constraints for example with the parametric scenarios feature in veda.

thanks

[Antti-L]

AK> On your last point, how about introducing a new interpolation option that deletes a timeseries? This would be great for deactivating FX attributes too.

Ok, yes, that could be one possible new option.  But it would again only work for time series attributes, and the user would have to define the UC_RHS*(...,'N') parameters if non-binding constraints are desired.  Any suggestion for the option code for this purpose?  Perhaps −3 or −13?

BTW: Would TFM_MIG work for that 'N' purpose (i.e. easy adding UC_RHS*(...,'N') for existing binding constraints)?

[AKanudia]

Great, I would vote for -13.

MIG for converting to 'N' is a great idea too. UC_N col in TFM tables doesn't support wild cards, but we can think about enabling it. FILL tables and sourcescen are always there in the interim. But there is one catch here: Since UCs are processed at the very end, the RHS values are not available during TFM processing in a sync operation where the scenario with the original UC definition is also included. I had used MIG and UPD tables in parscen files but stopped due to this reason.

One option would be to process all the non-parscen UCs before processing parscen. Then one could reliably use MIG/UPD with UC_RHS* in parscen. What do you think?

[Antti-L]

> One option would be to process all the non-parscen UCs before processing parscen. Then one could reliably use MIG/UPD with UC_RHS* in parscen. What do you think?

Well, as I don't use parscen too often, I have not have had much problems with MIG/UPD with UC_RHS* there.  But with other scenarios, yes, I have indeed been facing this problem.  If I understand you correctly, UC_RHS* cannot be reliably updated via TFM_UPD/MIG or fill tables in regular scenarios, and that will continue to be so, because of performance reasons?  Thus far, I have been usually re-importing my QA scenario after other updates, to make sure the TFM_UPD/MIG updates will work. Maybe that is just uninformed of me, and you can suggest a better way?

I highly appreciate maintaining good performance, and so if you consider implementing that parscen change, I hope it wouldn't affect the overall sync performance.

[Antti-L]

@Victor:
> I would like to write a veda table to deactivate a list of user constraints defined in a different regular scenario.
> I think turning lim_type from UP to N for the selected uc_n would work but I did not managed to find the proper declaration in veda.
> I can see the potential for a user who wants to define in bulk constraints and then only activate subset of these constraints for example with the parametric scenarios feature in veda.


I tried to see if a simple mechanism could be added into TIMES for this purpose, and arrived at a tentative implementation, based on using an interpolation option for UC_TIME.  As with bound attributes in general (including UC_RHS*), you would be able to turn off any user constraint by simply defining UC_TIME(uc_n,reg,'0') = −13 (see Amit's suggestion above). However, the constraint would additionally remain generated as a non-binding constraint (lim_type would be turned to 'N').  If the constraints uc_n are by region, they would be deactivated like this, but only those for reg. If the constraints uc_n are summed over regions, one of which is reg, those uc_n will be deactivated whenever the reg specified in UC_TIME(uc_n,reg,'0') = −13 is any one of those summand regions.

I think it would thus be quite easy to deactivate user constraints by scenario using this method. And, if the constraints are deactivated already when they are defined, they can be easily activated again by defining UC_TIME(uc_n,reg,'0') = 0. What do you think: would this mechanism look satisfactory?

[VictorG]

Thanks, the description is clear, I think it provides an answer to the need to disable constraints

[VictorG]

I have a question related to this thread.

I know my model has infeasibilities, but I have not managed to make solver tools like IIS work. I would like to use dummy imports on specific constraints. I have narrowed the constraints to a set of about 20 that are causing trouble.

I would like to know if you have a method to allow for dummy imports of constraints or defining "soft constraints" that allow transgression with a specific cost.

A method that is not completely satisfying would be to allow this with VEDA user options and then deactivate all dummy imports except for my set of constraints.

Thanks

[Antti-L]

Sure, all those methods are possible.

Maybe disabling all but selected dummy flows for UCs would be easiest, one possible way shown below:
     
Here, the first line disables all dummies for UCs by fixing those flows to zero (and possibly even for some other dummies, if you have NRG commodities with names ending at "_" or "-").  The second line then enables a dummy flow for one constraint. I tested it, and as far as I can see it worked well. The only drawback is that if you have UCs in scenarios not selected in the run, this scenario would include FLO_BNDs also for non-existent commodities, and then you would have some domain violations.  But if you use the DATAGDX setting (which is the default), that will not do much harm.

The dummy costs could be selectively increased/decreased (from the default) by defining a flow cost.

[VictorG]

Thanks, I think will go for this one which is easy to implement.

The only drawback I see is that one has to wait a full synchronization to enable dummy imports on user constraints which can take a while for some model. Anyway, I will think about another solution in the future.

[Antti-L]

Well no, if you had NRG dummies originally enabled. Then you only need to re-import those scenarios that have UC constraints. But yes, if you did not have the NRG dummies enabled originally, then it does look like a full reimport is in fact needed. 

It would be nicer if re-importing just the scenarios with UCs would be sufficient even in this case, when toggling the UC dummy option. It is considerably faster to re-import just those scenarios even with the small DemoS_12 model.  And VEDA is updating the Base then anyway, because I can see the dummy commodities added there.  But the IMPNRGZ process and its costs are now missing from Base/SysSettings (when NRG dummies are not enabled).

@Amit: Would it be possible to add them, maybe even always? I mean just adding the IMPNRGZ process (without any TOP_IRE if NRG dummies are not enabled) into Base always, and the costs for it from SysSettings, because these would not take much room in the database?

[VictorG]

Thanks, I tried to turn on UC dummy on selected scenarios, it works.

[Antti-L]

I think this is a bug.

So, when the user selects dummy imports for user constraints only (not for NRG), the IMPNRGZ process is not getting added into the model. Therefore, the dummy imports for user constraints cannot work at all, because the UC dummies are defined to be flows of the IMPNRGZ process. These flows are thus now getting defined for a non-existent process, which won't work.

I think there should be no need for enabling NRG dummies, if one wants to enable dummies for user constraints, neither conceptually nor technically. And in the documentation I cannot find any indication anywhere that such would be required.

In order to get the dummies working, I even tried to alleviate the problem by adding the IMPNRGZ process manually, but VEDA would not seem to accept that: the process did not make it to the DD file, although no error messages were issued.

[Antti-L]

To reiterate, the VEDA bug is about using Create Dummy Imports for User Constraints, as shown below:
      
As stated above, currently this option does not work independently under VEDA, due to the missing dummy process(es). I have now looked at whether the issue could be fixed in TIMES, and it appears that it can be fixed pretty well up to the issue with the missing dummy costs.  Because these costs are also missing from VEDA, TIMES has no way of determining what those costs were meant to be. However, one could look at both of COM_CSTNET and COM_CSTPRD for the costs, and if none are set, then remove the dummy flow.

In this way the option "Create Dummy Imports for User Constraints" could be made to work for users needing this option.  Would this small enhancement seem to be worth implementing in TIMES?