Hi PowerM
I pretty much just typed the code into my newsgroup viewer, it’s
probably got some syntax bugs in it which may mean a direct copy and
paste wont work. But it should be pretty close…
The loop issue may be associated with the $onend setting? There are a
couple of ways you can write loops/ifs in GAMS depending on the
settings. The code I wrote assumed that the $onend setting was
enabled. It might be worth checking this out? (search help for $onend
if you are not familiar with it).
If you posted your full code, or the exact errors GAMS is throwing up,
then I may be able to help further.
As mentioned originally, I am not sure this code will be useful for
you. Its main advantage is you dont need the additional Hot/Warm/Cold
variables, you can simply use the U binary. This may speed up the
solve time.
As an alternative formulation, where the focus is on ease rather than
minimising variables, you could track unit commitment UC(i,t), start
ups SU(i,t), shut downs SD(i,t) (these may not be needed, but in
case you have shut down costs), hot starts HS(i,t) and warm starts
WS(i,t). You don’t actually need to track cold starts as not being
hot or warm implies cold.
NOTE: I am typing directly into newsgroup, syntax might be a bit off.
Let STARTUP_COST_COLD(i) = cold start cost.
STARTUP_COST_WARM(i) = warm start cost.
STARTUP_COST_HOT(i) = hot start cost.
HOT_START = number of periods for hotstart
WARM_START = number of periods for warm start
The objective function part related to startup costs would be
something like:
sum((i,t), SU(i,t) * STARTUP_COST_COLD(i)
 WS(i,t) * (STARTUP_COST_WARM(i)  STARTUP_COST_COLD(i))
 HS(i,t) * (STARTUP_COST_HOT(i) 
STARTUP_COST_COLD(i)) )
This says we initially assume that if the unit starts up it is a cold
start, but we remove this cold start cost and replace it with either a
warm or hot start cost if it was actually a warm/hot start.
The constraints would be as follows. I have overdone the constraints,
some are probably unrequired as the solution economics would mean the
model will naturally move to the solution the constraints are
enforcing. But there for completeness. I assume you correctly set UC
somewhere else, eg something like if UC=0 then unit cannot do
something  I dont have that constraint here.
Unit Commitment
** your existing UC constraints somewhere.
Startups / Shutdowns

Force the startup binary variable to 1 if the unit turns on.
SU(i,t) >= UC(i,t)  UC(i,t1)

If the unit is off in t it could not have started up in t, force
the startup binary variable to 0
SU(i,t) = UC(i,t1)  UC(i,t)

If the unit is on it could not have shut down, force the shutdown
binary variable to 0.
SD(i,t) ord(t  HOT_START)) =
yes
HS(i,t) ord(t  WARM_START))
= yes
WS(i,t) = (sum(t_hot(t,t2), UC(i,t2) ) / HOT_START )  (1 
SU(i,t))
The first bit of the RHS is a fraction which will always be 0 if the unit was operating within the last HOT_START
periods. Assuming the unit has started up (which is dealt with
shortly) then if the unit was operating in prior hot start periods
then this part of the RHS is somewhere within (0,1], which forces the
hot start binary to be 1. The last part of the RHS checks the unit
has actually started up. 1  SU(i,t) disappears if the unit started
up in t and leaves just the logic dealing with the unit operating,
described above. Conversely it forces the entire RHS to be â‰¤ 0 if the
unit did not start up, thereby making this whole constraint unbinding.
11. Similarly force the warm start variable to 1 if the unit was
previously operating within the last WARM_START periods AND has
started up.
WS(i,t) >= (sum(t_warm(t,t2), UC(i,t2) ) / WARM_START )  (1 
SU(i,t))
 A unit cannot start up AND shut down in the same period ***
this might help a branch and bound solver ***
SU(i,t) + SD(i,t) wrote:
Hi andy,
somehoe it did not work out. GAMS had some problems with the
c_CostStartup(i,t) ant the whole loop. Thou I had the right syntax.
Anyway, thanks for the help!
\