[NEMO-devel] Result difference

[Ben Elliston]

Hi Yusak

> Sorry if my question is not clear. I already understand about the hallfame
> and fitness as you informed me previously.

Ah, sorry, I misunderstood your question.

> It is about the difference between:
> Jamali-PV: [*15.409046732884701, *1.7222013518375101, 8.3462172104824983,
> *15.538314391372536*, 10.556889362917959, *8.7746846991700274,
> *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]
> 
> and
> polygon *1 PV* (JAVA:1), *4.00 GW *supplied 6.087 TWh, CF 17.4%, capcost
> $3,292,000,000, opcost $94,434,706, LCOE $50
  [...]

In this case, the optimiser chose 15.409046 GW as the capacity for
polygon 1 PV.  However the build limit is 4GW.  Things work fine when
the parameter space, from the viewpoint of CMA-ES, is unconstrained.
We just "repair" these parameters in the evaluation function by
clamping the value at the build limit.

Similarly, when you replay a simulation with those parameters, the
build limit will apply and you will get the right result.

Cheers, Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/nemo-devel/attachments/20170928/d3b33fd1/attachment.sig>