Veda2.0 Released!


Negative dummy import variable
#1
Hi all,

My model results show some negative dummy import variables related to user constraints. I reviewed the documentation and the forum and could not find any explanation. I appreciate it if anyone let us know more about that. I guess it is a kind of slack variable to make the model feasible. However, it is interestingly classified as a dummy import energy commodity while there is no commodity balance or other data. If there was a right dummy import commodity similar to the Demo models, I wonder whether these constraint-related dummy import variables would be generated or not.

Thanks,
Reply
#2
No, it basically should not be analytically possible that any negative dummy import flows would show up, because all these variables (which are internally VAR_IRE variables) are defined non-negative (they have a zero lower bound).  However, of course it can be possible numerically, within the feasibility tolerances of the solver.  Is that what you are seeing?  Can you show these negative 'variables' you see in the results related to user constraints, so that one could better see what you mean?
Reply
#3
In fact, the name for the commodity is “negative ...” but the value for its’ output is positive. The commodities are generated with a “-” or “_” character following the user constraint name.
Unfortunately, I have no access to the model right now. Sorry, I wanted to reply your comment without delay!
Reply
#4
Ok thanks for the clarification. 
To explain a bit about the dummy import flows: They are a VEDA feature, where VEDA automatically creates import flows of two commodities for each user constraint (if requested), thereby adding a positive and a negative term into the user constraint. They are added as import flows to the IMPNRGZ process (which is also automatically created). Otherwise, the corresponding flow variables are standard TIMES VAR_IRE variables, but they do not have any commodity balances generated, however, because they are only referred to in the user constraints and the EQ_ACTFLO equation of the IMPNRGZ process (and thus no commodity balance is necessary).
Reply
#5
Thank you for the clarification. So, high activity costs that are introduced in the settings file also work for them, and I should review EQ_ACTFLO equation for debugging purposes. I wonder whether it is the most useful way for debugging or not.
Reply
#6
Yes, the high activity costs that are introduced in the settings file also work for them.  If you see positive values reported for any of these flows, the corresponding user constraint is most likely infeasible, and yes, it then probably needs some debugging.  However, reviewing the EQ_ACTFLO equation for that purpose is not helpful at all (there is nothing useful to see there). You should review the user constraint formulation instead.
Reply
#7
Many thanks for your quick replies!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)