-
Notifications
You must be signed in to change notification settings - Fork 0
/
Readme.txt
60 lines (46 loc) · 4.74 KB
/
Readme.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
Documentation (basic) for inverter/ battery systems predictive controls
Dinos Gonatas (c)
Dec 2 2013
This package determines the optimal control parameters for inverter throughput and battery state of charge coupled to an intermittent PV system (or any intermittent source of power). The core functions are:
- batfunc1.c … the system cost function
- PV_optim.m … a function that calls the Matlab constrained optimization package, fmincon, and returns the optimal parameters at a single time point together with an error code indicating whether or not a feasible solution exists
- control_script … a sample script that reads in formatted prediction data from march3.xls, then loops through a sequence of time points to determine the optimal control parameters for a series of time data.
Also, utilities include
- plot_battery.m … a script that compares the results of uncontrolled output power to controlled output power, together with the state of charge and inverter throughput
- numerous functions that convert uncontrolled power to controlled power, initialize transfer function matrices.
________________
function [xresult, fval ] = PV_optim(fcast, Price, qmax, qmin, f0, Currentmax, time_horizon, rr_requirement, q_init1, ...
q_init2, x_init, h0, inverter_min, battery_powerscale, battery_meancharge)
Outputs:
results xresult, a (2,time_horizon) array of the optimal control parameters.
xresult(1,:) = inverter throughput
xresult(2,:) = battery state of charge
fval = value of the optimal cost function at an evaluated time point
xflag = error code:
2 Change in x was less than options.TolX and maximum constraint violation was less
than options.TolCon.
1 First-order optimality measure was less than options.TolFun, and maximum constraint violation was less than options.TolCon.
0 Number of iterations exceeded options.MaxIter or number of function evaluations exceeded options.MaxFunEvals.
-1 Stopped by an output function or plot function.
-2 No feasible point was found.
-3 Objective function at current iteration went below options.ObjectiveLimit and
maximum constraint violation was less than options.TolCon.
Inputs:
fcast - the forecast of the uncontrolled power
Price - the power price
qmax - maximum charge for battery (in units of power*time)
qmin - min charge for battery (lowest value = 0)
f0 - nameplate maximum PV power (e.g.. for computing ramp rate requirement)
Currentmax - maximum battery current, in PV power units (e.g. = 30% means max current corresponds to 30% of PV nameplate rating)
time_horizon - # of time points ahead in battery forecast (note these are not necessarily in minutes although they can be)
rr_requirement - ramp rate limit in % of max PV nameplate
q_init1 - initial charge of battery 1st time point
q_init2 - initial charge of battery at 2nd time point
x_init - initial inverter throughput (usually set this = 1)
h0 - roundtrip battery efficiency (including battery inverter)
inverter_min - the lowest permissible of inverter throughput (lowest value = 0, highest value = 1; set = 1 if it’s desired to smooth PV fluctuations with battery alone)
battery_powerscale - a weighting factor to reduce the impact of battery current on the system cost function. This should be < 1 otherwise the system will always try to maximize the power generated by the battery during the limited time horizon of the optimization… and the battery will run out of charge early instead of being useful for balancing PV production fluctuations the system can’t foresee during a limited time horizon
battery_mean_charge - set this to some # around 50 - 80%; other things being equal if nothing is going on that needs battery intervention, the battery will charge to this level of maximum charge so that it will be ready the next time it’s needed. The optimal value of this parameter depends on the PV power production history so should be tested empirically on some sample days to get the best results for ability to mitigate fluctuations.
The script control_script.m calls the this function with a bunch of sample arguments while reading in the excel file with your data formatted in an easy to read way (march3.xls - 1st column is the actual data, each subsequent column is the predicted data x time steps ahead). Note the ‘scale_factor’ variable. This = 2 for the data you sent b/c while each successive forecast is on a minute basis, in each time series there are 2 time points per minute. So lots of things have to be adjusted to compensate, eg. the rr_requirement. Since a 10% ramp limitation per time point actually = 10%/30 seconds = 20%/min
The script plot_battery calculates the controlled power and makes some decent plots so you can figure out what’s going on.
This runs quite quickly per time point so it is feasible to adapt this for real time operation. Good luck!