Normalised objective function behaving weirdly

[jonmaddock]

In GitLab by @kj5248 on May 31, 2023, 14:23

Inconstistent behaviour of (norm_objf) in output file in relation to objective function. For example:

 Normalised objective function                                            (norm_objf)              -1.426E-04  OP 

but

 Net electric power output(MW)                                            (pnetelmw.)                 -12.026  OP 

whereas the normalised objective function in the example considered here should be

    case (17)  !  net electrical output
       fc = sgn * pnetelmw / 500.0d0

where sgn is the sign of minmax:

    !  If sgn is -1 the value of fc will be maximised
    !  If sgn is +1 the value of fc will be minimised

The value should be -(-12)/500 = 0.024, not -1.426E-04.

[jonmaddock]

In GitLab by @mkovari on May 31, 2023, 14:43

The inconsistent behaviour only seems to happen for unconverged outputs (although ideally even these should be self-consistent). For converged outputs the value is correct.

@timothy-nunn If you want to investigate why the output is not consistent for unconverged runs, be my guest - otherwise you might want to close this issue.

[timothy-nunn]

I have tested this using the "path" of the solver on an input file maximising net electric.

I have observed the same behaviour. Where the normalised net electric does not agree with the net electric in the MFILE.

Printing out value of pnetelmw when calling funfom provides a value that can be different from the MFILE:

Printed in funfom	Output in MFILE
394.77803591421662	394.78
0.017754112447730123	-54.325
95.995834335900213	95.996
129.77657285970724	129.78
143.51298186912720	143.51
161.38412390533540	161.38

I believe that the following code in power.py is causing this discrepancy:

#  Scaling to prevent negative heat_transport_variables.pnetelmw
# Do NOT rescale if this is the last run through.
if (
    (heat_transport_variables.pnetelmw < 1.0e0)
    and (cost_variables.ipnet == 0)
    and (not output)
):
    heat_transport_variables.pnetelmw = 1.0e0 / (
        1.0e0 + abs(heat_transport_variables.pnetelmw - 1.0e0)
    )

Removing this catch provides (for the second example above) provides consistency in the MFILE values:

• norm_objf = 1.0865E-01
• pnetelmw. = -5.4325E+01

Removing the and (not output) gives a different (still consistent) result because the kludged value of pnetelmw is also output to the MFILE:

• norm_objf = -3.5508E-05
• pnetelmw. = 1.7754E-02

@mkovari do you have any thoughts? If we are scaling to prevent a negative pnetelmw why aren't we outputting that to the MFILE and are instead outputting the non-scaled value?

[mkovari]

As far as I can see, negative net electric power is OK - it just means that the recirculating power is bigger than the gross electric. It will result in silly results for cost of electricity.

If net electric is negative in a converged solution (which can happen if the net electric constraint is not used) then there should be a warning at the top of the OUT.DAT and on the terminal.

I suggest removing the rescaling of pnetelmw shown above to allow it to become negative at any time.

Any comments @jmorris-uk ? @timothy-nunn ?

[jmorris-uk]

I agree with Michael that negative net electric values are physically meaningful and should be allowed. Similarly agree that it should be accompanied by a clear warning somewhere in the output.

[timothy-nunn]

We already warn about negative net electric as follows:

if heat_transport_variables.pnetelmw < 0:
    po.ocmmnt(
        self.outfile, "WARNING: Calculated net electric power is negative"
    )
    po.ocmmnt(
        self.outfile, "--------------------------------------------------"
    )

Therefore, I will just remove the scaling