Veda2.0 Released!


UC over Regions and TS
#1
HI everyone,


I would like to add an UC for Wind Gen over all my regions - It doesnt matter in which of the regions the Wind energy is beeing produced.  
Since RNW's Availability factors were made in a Daynite timeslice, I would also like to add the constraint over all time-slices. I am not sure which UC_RHS index I should use, since all the available ones, as far as I know, doesn’t consider this option (over regions and Timeslices). 
 
UC_RHSRTS: UC-RHS for each region, year, and TS
UC_RHSS: UC-RHS summed over region and year, for each TS
UC_RHSTS:UC-RHS summed over region, for each year and TS
UC_RHS:UC-RHS summed over Region, year and TS
UC_RHSRT:UC-RHS summed over Region, year and TS
UC_RHSR:UC-RHS summed over TS, for each region and year
UC_RHSRS:UC-RHS summed over year and TS, for each region
UC_RHST:UC-RHS summed over year, for each region and TS

Thanks,

regards,
Raul
Reply
#2
I wonder where you have got those descriptions, which were incorrect?  Would you disclose the source?

The logic is actually very clear in accordance with the postfix of the attribute names: R stands for each region, T stands for each period, and S stands for each timeslice. Hence, corrected descriptions below:

UC_RHS:  UC summed over region, over period, and over TS
UC_RHSR:  UC for each region, summed over period and over TS
UC_RHST:  UC for each period, summed over region and over TS
UC_RHSRT:  UC for each region and each period, summed over TS
UC_RHSTS:  UC summed over region, for each period and each TS
UC_RHSRTS:  UC for each region, each period, and each TS

Consequently, your desired constraint type (over regions and Timeslices) would use UC_RHST (assuming you want them for each period).
Reply
#3
Hi Antti,

thank you, once again, for your response and help. And sorry, when I copied and pasted the UC indexes from the Attributes Mater table in Veda some came wrong, precisely the ones below UC_RHS.

However, UC_RHST is indeed described wrong in the attributes table in Veda-FE, exactly the one I needed. It has the UC_RHSRS description instead.

Regarding the UC I want, I think this is the index I was looking for. But the model remains infeasible when running with the UC, even if a put very low values for the constraint. Please, take a look below. Is it correct?

UC - All Regions/Each Period
~UC_Sets: R_S: AllRegions
~UC_Sets: T_E:
                                                                                         ~UC_T: UC_COMPRD
UC_N      Pset_PN    Pset_CI   Cset_CN    Attribute   Year     LimType       UC_FLO      AllRegions      UC_RHST        UC_RHST~0  UC_Desc
UC_WSH  EWND*     Wind       ELC_HV                   2015        LO                 1             -0.005%              0                  15            Min Wnd 
                EWND*     Wind       ELC_HV                   2028        LO                  1             -0.500%
                EWND*     Wind       ELC_HV                   2043        LO                  1             -0.500%


Thanks!
Reply
#4
Yes, it looks quite correct to me.

I even tested exactly the same kind of constraints in a test model, and it worked well. The model was solved to optimality without any infeasibility.
In the test I imposed a 5% share, and obtained 5% wind power in the total production of ELC.
I also verified the equation in the listing file.

So, my conclusion is that the equation works correctly, as defined in the ~UC_T table.

If you can provide a reproducible test case that produces an infeasibility, it would be easy to see why it is infeasible. Maybe you have some typo in the process/commodity names, or maybe the EWND* technologies are all new technologies, which are not available in 2015, to name just two possibilities...
Reply
#5
Hi Antti,

thanks for your tips. The UC is still not working, but I was trying to find possible shortcomings that could be hindering the wind penetration and was indeed modifying some possible issues. 

Suddenly, without doing any big change, I got an "Unexpected Termination of Run". I have tried to undo any previous modification that might resulted in the problem, but it remains. I can´t run the model even just "checking" the BASE and SysSetting "scenarios".

Please, find enclosed the LST file. 

Any suggestions?

Thank you once again,


Attached Files
.txt   BASE.txt (Size: 224.41 KB / Downloads: 8)
Reply
#6
There is a division by zero when processing G_DRATE (the discount rates).
I just tried to reproduce such an error myself, but did not succeed in that.  Confused
There are also lots of domain violations, apparently for referring to years beyond 2200!

If you give me access to your model, these things would be easy to sort out, but now it just looks messy...

[EDIT]: I can see that there are indeed phantom DATAYEARs in your model (year > 2200).
They cause the domain violations, and I suspect that they are causing many other problems, possibly also the divide by zero.

In the first place, you should get rid of those domain violations. GAMS is not able to handle the invalid phantom elements fully gracefully.
Reply
#7
(24-01-2017, 07:11 PM)Yes, I\ve noticed that warning regarding the discount rate, but I don´t know where it may happened. But it seems it was indeed an issue regarding the definitions of some years. Appeareantly, when I scroll down the years of some AFs, excel auto-filled some lines wrong. For instance, AFs were defined for the years 2010, 2030, 2050; and when a scroll down it, the next line got 2010, 2030, 2051; the next 2052.... until 2300 Wrote: thanks, Antti
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)