This section assesses the HCA’s performance with regard to OPEX minimisation and self-consumption enhancement. Indicators such as system energy efficiency, solver accuracy and running time are also considered. The MATLAB solvers intlinprog
are used as benchmarks. Firstly, the HCA’s effectiveness is evaluated in 48 h horizon short-term simulations in winter and summer for a system size of 1 kW HP, 600 l TES and 3 kWp PV. This size is chosen to reproduce a typical household configuration with a large DHW tank to enhance PV self-consumption. The second section restricts the analysis of long-term system operation to cases controlled by the HCA and intlinprog
using the same system sizing applied to short-term simulations in winter and summer. fmincon
are excluded from this case since they could not always find a reasonable local optimum or did not converge at all. Those issues arise as a consequence of the relatively flat search path experienced by NLP solvers when computing the values of the objective function defined in the nonlinear OCP (Section 2.2.3
) throughout the feasible domain determined by the applicable set of constraints. The CPU used for simulations comprises an Intel Core i5-3230 (2.60 GHz) processor with 8 GB RAM on a 64-bits operating system.
3.1. Short-Term Simulations
The evaluation is carried out for a 48 h optimisation period including PV production profiles corresponding with one clear-sky day and one cloudy day. The initial point
of the optimisation using solvers fmincon
was given by the result of intlinprog
. This procedure avoids using a non-optimal initial point
and reduces these solvers’ running times. For the sake of clarity, this section is focused solely on comparing the performance of the different optimisation solvers. The performance of the ICA based on optimal HP energy management signals will be analysed in Section 3.2
displays the main system variables computed by the different optimisation solvers for summers’ simulations. Regarding temperature values, it can be seen that, in all cases, the tank temperature profiles end at the set point of 55 °C.
Analysing the HP power scheduling, we note that fmincon
decides to operate the HP at mid-power levels intermittently over most of the PV production period to enhance the part-load efficiency values, keeping supply temperatures low. This results in the highest
values of all the solvers while the PV self-consumption is increased. Nevertheless, this power profile implies continuous HP switching, which would reduce its lifespan rapidly. For GlobalSearch
, the solver yields a HP behaviour similar to that of fmincon
, except that it runs the HP during some periods at very low power values with
values lower than 1. The reason for both deficiencies relies on the inability of derivative-based NLP solvers to utilize discrete variables. On the one hand, this means that fmincon
only as a continuous decision variable. Hence, although there is a penalty in efficiency, these routines switch the HP on at very low power values as low power ranges are allowed and this inefficient operation incurs no cost in their objective function (Equation (7
)). On the other hand, this limitation makes it difficult to assign a cost to the HP switching and running time, leading to detrimental intermittent HP power profiles.
For the HCA, the solver is able to concentrate all the HP power working at a higher power level compared to the NLP solvers, shaving PV injection peaks more effectively. Despite the fact that working at higher power levels results in lower HP
values, the HCA control strategies provide the best match between HP consumption and PV generation, accomplishing the highest share of PV self-consumption (44%) during summer simulations. Table 3
shows that self-consumption rates for the other solvers stay 5% below the HCA’s result.
The HP scheduling given by intlinprog also follows a similar profile as the HCA’s. However, the definition of a linear with a constant supply temperature has as consequences that the solver considers neither the reduction of values when increasing the tank temperature nor the decrease of when the HP is working at full load due to part-load ratio. All these factors lead to an overestimated profile, which contributes to reducing the HP running periods with respect to those generated by the HCA.
Looking at the
values in Table 3
, it can be seen that the HCA offers the most cost-competitive solution during the summer (1.45 CHF) among MATLAB nonlinear solvers (fmincon
lead to 96% and 69% more expensive optimal control strategies, respectively). These results are only improved by the 33% cheaper intlinprog
operation. In winter, NLP solvers present the same behaviour as for the summer period, achieving the highest
values due to a combination of low supply temperatures and HP operation at optimal part-load efficiency ranges. For this case, they achieve local consumption of almost 100% of the PV generation. Moreover, the HCA and intlinprog
attain the lowest OPEX values since they can run the HP more smoothly than the NLP solvers while promoting the self-consumption of locally generated PV electricity. Note that, despite the fact that intlinprog
provides the cheapest operation strategy for summer and winter short-term simulations, those results are based on overestimated
values. Section 3.2
will present some of the impacts that this
inaccuracy produces in the real-time control of the system.
Studying solver calculation time, values in Table 3
suggest that the implementation of current NLP algorithms cannot provide suitable real-time optimal control due to their large computational burden. This statement depends very much on the hardware and on the efficiency of the implementation of such nonlinear solver. Thus, better implementation of such solvers may draw a different conclusion. However, considering the MATLAB implementation, only the HCA and intlinprog
can effectively deliver control trajectories in a computation time smaller than the simulation time-step, i.e., enabling real-time control. Note that all results gathered in Table 3
are totally deterministic, except running time values, which depend partly on external factors related to computer processing hierarchy, and GlobalSearch output, which may vary according to the set of trial starting points chosen randomly by a scatter search algorithm integrated in this solver [40
]. As a consequence of the first exception, short-term winter and summer simulations were repeated twenty times for the HCA, intlinprog
while they were repeated five times for GlobalSearch
in order to obtain a mean run time value and its uncertainty range shown in Table 3
. Due to the second exception, the GlobalSearch
values produced in the fastest run out of the five executed for winter and summer periods are shown. The GlobalSearch
main variable profiles depicted in Figure 4
correspond to this case.
3.2. Long-Term Simulations
Long-term simulations are performed to optimise the energy balance of the system during a winter (1 to 31 January) and a summer month (1 to 30 June) with the aim of minimising the system’s OPEX values and enhancing self-consumption by using the optimal HP scheduling calculated every 12 h by the HCA and intlinprog. In the case of DHW, low and high monthly consumption profiles are provided to simulations in summer and winter conditions, respectively. These long-term simulations also allow us to check the robustness of the algorithm with respect to the time dependent environmental conditions and demand profiles.
Running simulations for the use case defined in this study, it is observed that intlinprog
records execution times significantly lower than the HCA. As in Section 3.1
, summer and winter long-term simulations are repeated twenty times for both solvers, obtaining for each of them, run time data samples of 1200 and 1240 values that correspond to simulations run during the summer and winter months respectively. Distribution of these data samples is represented through several boxplots shown in Figure 5
. Note that each of these run time values is the time the HCA or intlinprog
spends to calculate an optimal HP management strategy for a 48-h period, which occurs twice per day during the whole simulation month (the ICA running time is not included in these values). The larger PV generation experienced in summer made intlinprog
evaluate an increased number of possibilities to allocate HP power scheduling for self-consumption enhancement. This leads to longer running time values compared to results given for the winter month. Even so, intlinprog
can converge in 75% of all cases below three seconds and one second in summer and winter seasons, respectively.
For the HCA, the third quartile of the running time during the winter month (January) reached a value of 133 s, whereas 54 s was recorded for the summer month (June). This time difference depends on the HCA’s number of decisions. In winter, factors such as low ambient temperatures and high DHW consumption decrease the HP’s
and increase the heat demand, thereby raising the number of times the algorithm needs to operate the HP in order to maintain the tank temperature above the set point (55 °C). Additionally, it is observed that allocating the HP load within the PV generation period also helped the HP to increase its efficiency, reducing the HCA’s number of decisions. This can be explained by the correlation of solar energy availability with higher ambient temperatures. Furthermore, Table 4
highlights that the HCA is able to provide an optimal control strategy that can adjust the HP power to self-consume as much PV electricity as intlinprog
. The self-consumption rate experienced in the winter simulation controlled by the HCA is just 8% lower than is the case when intlinprog
is used. During the summer, although the PV resource increases significantly, this difference reduces to less than 1%.
Thus, these small differences in self-consumption contribute to obtain a tight comparison regarding OPEX values: the HCA could control real-time system performance during the winter at a cost that is 9% higher than intlinprog, whereas for summer this difference is reduced to 4%.
Regarding solver accuracy, Figure 6
shows that considering an LP approach to solve this optimisation problem presents several drawbacks. When tank temperatures are higher/lower than 60 °C, intlinprog
is overestimated/underestimated (yellow area). Even when temperatures remain close to 60 °C, instantaneous
values are frequently lower than those of intlinprog
due to part-load efficiency reasons (blue area). Consequently, according to 3th protection measure (see Section 2.2.7
), the ICA has to react using auxiliary heat pump capacity to provide additional heating when the tank temperature drops unexpectedly below the set point (here on 25 January around 10:30 h (purple area)). Moreover, Figure 7
quantifies the impact of the previous shortcomings over system real-time operation by showing values of the supplementary heat pump energy used by the ICA (additional to the power predicted in the optimisation) as well as the DHW deficit durations (periods when tank temperature is below the set point) for winter and summer months.
It is highlighted that cases managed by the HCA undergo certain periods of DHW deficit (80 h and 0.5 h for winter and summer months, respectively). However, this deficit is a consequence of two external factors: the heavy DHW peaks experienced, especially during the winter, which lead to temperature drops larger than the 10 K desirable temperature band, and the time step difference between the simulation and the optimisation, which causes tank temperatures to sometimes fall below the set point as the ICA experiences unexpected DHW demand peaks during a few minutes that could not be anticipated by the optimisation, which uses forecast input data with a 30-min time resolution. Nevertheless, these unexpected real-time temperature drops make real values higher than values at that time, enabling the HP to deliver a higher thermal energy output than predicted during the next minutes, which helps to restore or sometimes even surpass the optimised temperature value calculated by the HCA at the end of that time step. Thus, although the DHW deficit periods are inevitable, the HCA scheduling remains valid even for the aforementioned time step difference as it avoids the use of any supplementary HP power (, and are 0).
For the case of intlinprog, in addition to the external factors mentioned in the case of the HCA, overestimation leads to a deficit of HP thermal energy provision, which contributes to an increase of DHW deficit duration with respect to the HCA case (108 h and 7 h for winter and summer months, respectively). This forces the ICA to use the supplementary HP power to compensate for this deficit, providing instantaneously around 2 kWh of thermal energy for more than one hour for the winter month, while 4 kWh and two hours are registered for the summer month. This higher activity of the ICA in summer compared to winter can be explained from the fact that the HP operates for less time in summer than in winter, which makes it less probable that the ICA can find any scheduled HP power in the next 15 min when trying to restore unexpected temperature drops, being forced to use more supplementary HP power.
It is worthwhile to note that the optimised HP scheduling used by the ICA is refreshed every 12 h. If a longer refreshing period were chosen, intlinprog inaccuracies would have a greater misleading effect on real-time system operation.