<div dir="ltr"><div><div><div><div>Hi Dr. Ben,<br><br></div>Thank you for your suggestion. I will use it later on.<br><br></div>Sorry if my question is not clear. I already understand about the hallfame and fitness as you informed me previously.<br><br></div>It is about the difference between:<br>Jamali-PV: [<b>15.409046732884701, </b>1.7222013518375101, 8.3462172104824983,
<b>15.538314391372536</b>, 10.556889362917959, <b>8.7746846991700274,
</b>13.08950232073305, 8.0203929213724301, 11.047838934170874,
9.2266373469077383, 0, 16.541477118404561, 10.100857070020616,
20.518031615710981, 11.997746175400911, 12.387589958041254,
5.7491295143515693, 18.775730807261123, 7.6424579331404816,
2.0118168520321245, 0, 2.1059111519489067, 0, 10.465303019230809, 0,
1.8352937636816455, 0, 2.3753121109034288, 0, 2.4158953576921229, 0, 0,
0.34389522814178952, 2.9917206278015609, 0, 0, 0, 0, 0, 0, 0, 0]<br><br></div>and<br>polygon <b>1 PV</b> (JAVA:1), <b>4.00 GW </b>supplied 6.087 TWh, CF 17.4%, capcost $3,292,000,000, opcost $94,434,706, LCOE $50<br>polygon 2 PV (JAVA:2), 1.72 GW supplied 2.73 TWh, CF 18.1%, capcost $1,417,371,712, opcost $40,702,818, LCOE $48<br>polygon 3 PV (JAVA:3), 8.35 GW supplied 13.32 TWh, CF 18.2%, capcost $6,868,936,764, opcost $197,289,741, LCOE $48<br>polygon <b>4 PV</b> (JAVA:4), <b>2.00 GW</b> supplied 3.196 TWh, CF 18.2%, capcost $1,646,000,000, opcost $47,278,229, LCOE $48<br>polygon<b> 6 PV</b> (BALI:6), <b>2.00 GW</b> supplied 3.25 TWh, CF 18.6%, surplus 0.0 TWh, capcost $1,646,000,000, opcost $47,300,172, LCOE $47<div><div><div>and also for Hydro, etc</div><div><br></div><div>I put PV limit in the poligons.py as <pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"Courier New";font-size:9pt">pv_limit = [<span style="color:rgb(0,0,128)">None</span>, <span style="color:rgb(0,0,255)">4</span>, <span style="color:rgb(0,0,255)">9</span>, <span style="color:rgb(0,0,255)">9</span>, <span style="color:rgb(0,0,255)">2</span>, <span style="color:rgb(0,0,255)">11</span>, <span style="color:rgb(0,0,255)">2</span>]</pre>then I also use <span style="color:rgb(0,0,0)">self.setters in generators.py in order to limit capacity of other technologies, such as coal, geothermal, hydro, gas, and biomass.<br></span><pre style="background-color:rgb(255,255,255);font-family:"Courier New";font-size:9pt"><span style="color:rgb(0,0,0)">self.setters = [(self.set_capacity, capacity,polygons.coal_limit)] <br><br></span></pre><pre style="background-color:rgb(255,255,255);font-family:"Courier New";font-size:9pt"><span style="color:rgb(0,0,0)">and adding for example for geothermal:</span><br>geothermal_limit = <span style="color:rgb(0,0,255)">10</span><span style="background-color:rgb(0,0,0)"><span style="color:rgb(0,0,0)"><br></span></span><span style="color:rgb(0,0,0)"><br>in polygons.py. <br><br>When I de-activate the self.setters (not for PV) then the results back to normal for the scenario using wildcards or using polygon, I mean same again between <br>the summary of GW and the breakdown below for other gens. However, difference are still there for PV.<br><br><br></span></pre><pre style="background-color:rgb(255,255,255);font-family:"Courier New";font-size:9pt"><span style="color:rgb(0,0,0)">I'm just curious if I ignore this difference then probably it may affect the simulation result.<br></span></pre><pre style="background-color:rgb(255,255,255);font-family:"Courier New";font-size:9pt"><span style="color:rgb(0,0,0)"><br>So I'm now thinking on how to provide build limit for geothermal and hydro as I considered these two gens as fueled type gen.<br><br></span></pre><pre style="background-color:rgb(255,255,255);font-family:"Courier New";font-size:9pt"><span style="color:rgb(0,0,0)">Cheers,<br><br></span></pre><pre style="background-color:rgb(255,255,255);font-family:"Courier New";font-size:9pt"><span style="color:rgb(0,0,0)">Yusak<br></span></pre></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-09-28 12:55 GMT+10:00 Ben Elliston <span dir="ltr"><<a href="mailto:bje@air.net.au" target="_blank">bje@air.net.au</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Yusak<br>
<br>
First, rather than sending huge amounts of output to the list, can you<br>
consider using a web service like <a href="http://pastebin.com" rel="noreferrer" target="_blank">pastebin.com</a> and sending a link<br>
instead? Thanks.<br>
<span class=""><br>
On Thu, Sep 28, 2017 at 09:35:54AM +1000, Yusak Tanoto wrote:<br>
<br>
> I just realized that I have experienced results difference between what is<br>
> listed right after the iteration finished (Jamali-PV = [.........]) and the<br>
> following breakdown after running 100 iterration, although the simulation<br>
> satisfy the reliability constraint (unserved energy 0.002 and LOLP 0.274).<br>
<br>
</span><span class="">> 95 15 51.3926 51.3826<br>
> 96 15 51.3702 51.3702<br>
> 97 15 51.4275 51.3702<br>
> 98 15 51.4273 51.3702<br>
> 99 15 51.6488 51.3702<br>
<br>
</span>If I understand correctly, you are asking why the result for iteration<br>
#99 is higher than the final result. This is because the CMA-ES<br>
algorithm does not guarantee that each generation will always be<br>
better than the previous. It often explores more widely and can<br>
produce a poorer solution than the overall best. That is what the<br>
"hallfame" (Hall of Fame) column shows you -- the all-time best. In<br>
this case, that is $51.3702/MWh.<br>
<br>
Cheers, Ben<br>
</blockquote></div><br></div>