Closed StefanoUnipd closed 7 months ago
In an OPF in MATPOWER, you are looking at a single snapshot in time, so the objective function is in $/hr.
In MOST, the time dimension is explicitly included, so the objective function units are $.
Dispatchable loads are represented as negative generators that contribute a negative "cost" to the objective function. It is essentially minimizing the cost of the supply minus the value to the demand ... or maximizing the welfare. So that's most likely where the negative objective function value is coming from.
Is there a way to assign each scenario the value of its objective function?
I'm afraid I don't understand this question? Are you using the word "scenario" to refer to different MOST runs, or to the different "scenarios" in a single MOST run of a stochastic case?
I'm using the word "scenario" refering to the different "scenarios" in a single MOST run of a stochastic case. I'll try to explain myself better: in example 7 of the MOST 1.2 manual on page 100, three wind scenarios are defined. I would like to compare them, based on the value of the f objective, to see how much $ I gain or lose. However, MOST does not allow me to do this because I have a single value (and not three different value) of the f objective, and I don't know why. In your opinion, does this type of comparison make sense?
It certainly could be useful information, depending what you are trying to do.
There are many ways that the cost information associated with a MOST solution could be sliced and diced. By time period, by scenario, by generator, etc. Keep in mind that part of the reason everything is optimized together in one big problem is that there are constraints and costs that tie scenarios together (and time periods, etc.).
My guess is that what you probably want to do is write a little function to recompute the costs you are interested in from the solved case. For example, if you want just the total cost of generation for period t, base scenario j, you could do something like ...
f(t, j) = mdo.om.eval_quad_cost(mdo.om.soln.x, 'Cp', {t,j,1})
Actually, we need to keep in mind that these are probability-weighted costs, so you probably want to divide them by the probabilities in order to compare apples to apples.
f(t, j) = f(t, j) / mdo.CostWeightsAdj(1,j,t)
Perfect, yes I was trying to do something like this. I tried to extract the values of the remaining cost types (I am referring to the costs on pages 31-32) but without success. How could I do?
If you look at the output of the opt_model
object (mdo.om
), you can see the names used for the various cost components. Unfortunately, these names are not documented anywhere, but if you search for them in most.m
you should be able to figure out which one is which from the comments in the code. Feel free to ask if you run into trouble.
I noticed that, if I only have the generation costs, the f objective is equal to these costs. I'm analyzing a case with t=18 (t=number of periods), and after adding a contingency: "contingency = [1 0.06 CT_TGEN 1 GEN_STATUS CT_REP 0]; " I tried to calculate the generation costs with the line of code you suggested above, and I expected both an increase in generation costs and an increase in the f objective. In reality, generation costs increase but f objective decreases. So I ask myself: in the case of contingency, is it correct to use the line of code you suggested? And above all, if I have contingencies, what is the meaning of a decreasing f objective ?
The 2 lines of code I suggested should give you the valid cost of generation in each scenario.
When you say the f objective decreases, you mean that the overall objective of the 18-period run is less with the contingency included than without it? The f objective for a MOST run can be thought of as an expected net system cost for the entire horizon, so a decrease from adding a contingency does seem counter-intuitive to me. Is that really what you are seeing?
Exactly. To make you better understand the situation I'm analyzing, I would show you my code, but I can't do that. Here I try to explain the situation better, using most_ex4_dcopf_ss.m I only do the part of the exercise called "Secure DC OPF (w/cont,res,ramp)"(only one period); with contingency, I have: f=-442637.64 [$] generation_costs=-443100 [$]
without contingency, I have: f=-443114.99 generation_costs=-443110 Are these results correct? With f objective taking negative values, I cannot see the impact of contingencies on costs.
In my case study, dispatchable loads are not represented as negative generators, so that f objective can only take positive values. In my case, I suppose that contingencies can increase the value of f, because they are in fact an increase in costs, and in the early periods this happens: period 1: with contingency, f=102.92 [$] without contingency, f=63.68 [$] period 2: with contingency, f=199.67 [$] without contingency, f=127.37 [$] However, the overall objective of the 18-period is: with contingency, f=1581.69 [$] without contingency, f=1716.21 [$]
Instead if I calculate the generation costs in this way: nt=18 for(i = 1:nt) gen_cost(i,1) = mdo.om.eval_quad_cost(mdo.om.soln.x, 'Cp', {i,1,1}); gen_cost(i,1) = gen_cost(i,1)/mdo.CostWeightsAdj(1,1,i);
end with contingency, generation_costs=2738.432 [$] , totally different from f=1581.69 [$] without contingency, generation_costs= 1716.22 [$] and this value is equal tu f objective without contingencies. I assume that the generation costs are correct, but I would like to understand how these contingencies affect the f objective. I hope I explained myself well enough.
In the single period example frommost_ex4_dcopf_ss
adding the contingencies does increase the objective, as I would expect. The dispatchable loads simply add a large negative offset to the objective.
Just for clarification, above when you list the f value for period 1 and period 2, where are you getting that from? MOST does not compute a per-period objective. Or are you just running those periods separately as single-period MOST runs?
For the full 18-period case, when you add contingencies the objective goes from a deterministic cost (all scenarios 100% probability) to an expected cost. However, I would expect that the contingency scenario would be more expensive and it would have the potential to move the base case to a more expensive dispatch as well, so a weighted average of the costs should definitely increase. Depending on the costs you have associated with the contingency reserves, that is yet another cost increase. The only possible explanation I've been able to think of is if there is a significant no-load cost for the outaged generator that is not included in the outage scenario. That would introduce a negative offset to the objective function value for the case with contingencies.
One thing that could potentially be useful to you is to grab the latest master branch of MP-Opt-Model and use it to replace the version included with MATPOWER (in the mp-opt-model
subdirectory. It includes a new method display_soln
that can print out each component of the solution, so you could see the value of each component of the objective function by typing:
mdo.om.display_soln('qdc');
For example, for the most_ex4_dcopf_ss
case, the output looks like ...
>> mdo.om.display_soln('qdc');
===== QUADRATIC COSTS =====
idx description cost = quad linear constant average
------- ---------------------------- -------- -------- -------- -------- --------
1 RampWear(1,1,1)(1) 0 0 0 0 -
2 Cp(1,1,1)(1) -398794 6205.7 -405000 0 -
3 Cpp(1,1,1)(1) 5.56e-15 0 5.56e-15 0 9e-08
4 Cpp(1,1,1)(2) 9e-08 0 9e-08 0 9e-08
5 Cpp(1,1,1)(3) 4.5e-08 0 4.5e-08 0 9e-08
6 Cpp(1,1,1)(4) 1.85e-07 0 1.85e-07 0 9e-08
7 Cpm(1,1,1)(1) 0 0 0 0 9e-08
8 Cpm(1,1,1)(2) 0 0 0 0 9e-08
9 Cpm(1,1,1)(3) 0 0 0 0 9e-08
10 Cpm(1,1,1)(4) 0 0 0 0 9e-08
11 Cp(1,1,2)(1) -26310.1 689.869 -27000 0 -
12 Cpp(1,1,2)(1) 1.9e-15 0 1.9e-15 0 6e-09
13 Cpp(1,1,2)(2) 0 0 -0 0 6e-09
14 Cpp(1,1,2)(3) 1.07e-08 0 1.07e-08 0 6e-09
15 Cpp(1,1,2)(4) 1.24e-08 0 1.24e-08 0 6e-09
16 Cpm(1,1,2)(1) 0 0 0 0 6e-09
17 Cpm(1,1,2)(2) 0 0 -0 0 6e-09
18 Cpm(1,1,2)(3) 0 0 0 0 6e-09
19 Cpm(1,1,2)(4) 0 0 0 0 6e-09
20 Cp(1,1,3)(1) -11848.5 151.529 -12000 0 -
21 Cpp(1,1,3)(1) 2.66e-16 0 2.66e-16 0 4e-09
22 Cpp(1,1,3)(2) 7.48e-16 0 7.48e-16 0 4e-09
23 Cpp(1,1,3)(3) 3.83e-16 0 3.83e-16 0 4e-09
24 Cpp(1,1,3)(4) 1.42e-08 0 1.42e-08 0 4e-09
25 Cpm(1,1,3)(1) 0 0 0 0 4e-09
26 Cpm(1,1,3)(2) 0 0 0 0 4e-09
27 Cpm(1,1,3)(3) 0 0 0 0 4e-09
28 Cpm(1,1,3)(4) 0 0 0 0 4e-09
29 Crpp(1)(1) 0.000176 0 0.000176 0 500
30 Crpp(1)(2) 1e-06 0 1e-06 0 1e-06
31 Crpp(1)(3) 266.775 0 266.775 0 150
32 Crpp(1)(4) 5.26e-06 0 5.26e-06 0 1e-06
33 Crpm(1)(1) 0 0 0 0 1000
34 Crpm(1)(2) 0 0 0 0 2e-06
35 Crpm(1)(3) 0 0 0 0 300
36 Crpm(1)(4) 0 0 0 0 2e-06
------- ---------------------------- -------- -------- -------- -------- --------
Sum of Displayed Costs -436686 7047.1 -443733 0
When I list the f value for period 1 and period 2, I should have written: nt=1 ; nt=2. Thank you, it's very useful the new method "display_soln()"! However I can't understand the cost reduction with contingencies in my case study... I'll show you what I get with "display_soln()" (nt=2):
===== QUADRATIC COSTS =====
idx description cost = quad linear constant average
------- ---------------------------- -------- -------- -------- -------- --------
1 RampWear(1,1,1)(1) 0 0 0 0 0
2 RampWear(2,1,1)(1) 0 0 0 0 0
3 Cp(1,1,1)(1) 96.7989 0 96.7989 0 51.1623
4 Cpp(1,1,1)(1) -4.2e-23 0 -4.2e-23 0 9.4e-08
5 Cpp(1,1,1)(2) 0 0 0 0 9.4e-08
6 Cpp(1,1,1)(3) 0 0 0 0 9.4e-08
7 Cpp(1,1,1)(4) 0 0 0 0 9.4e-08
8 Cpp(1,1,1)(5) 0 0 0 0 9.4e-08
9 Cpp(1,1,1)(6) 0 0 0 0 9.4e-08
10 Cpp(1,1,1)(7) 0 0 0 0 9.4e-08
11 Cpp(1,1,1)(8) 0 0 0 0 9.4e-08
12 Cpp(1,1,1)(9) 0 0 0 0 9.4e-08
13 Cpp(1,1,1)(10) 0 0 0 0 9.4e-08
14 Cpp(1,1,1)(11) 0 0 0 0 9.4e-08
15 Cpm(1,1,1)(1) -4.2e-23 0 -4.2e-23 0 9.4e-08
16 Cpm(1,1,1)(2) 0 0 0 0 9.4e-08
17 Cpm(1,1,1)(3) 0 0 0 0 9.4e-08
18 Cpm(1,1,1)(4) 0 0 0 0 9.4e-08
19 Cpm(1,1,1)(5) 0 0 0 0 9.4e-08
20 Cpm(1,1,1)(6) 0 0 0 0 9.4e-08
21 Cpm(1,1,1)(7) 0 0 0 0 9.4e-08
22 Cpm(1,1,1)(8) 0 0 0 0 9.4e-08
23 Cpm(1,1,1)(9) 0 0 0 0 9.4e-08
24 Cpm(1,1,1)(10) 0 0 0 0 9.4e-08
25 Cpm(1,1,1)(11) 0 0 0 0 9.4e-08
26 Cp(1,1,2)(1) 6.17866 0 6.17866 0 3.26568
27 Cpp(1,1,2)(1) 0 0 0 0 6e-09
28 Cpp(1,1,2)(2) 0 0 0 0 6e-09
29 Cpp(1,1,2)(3) 0 0 0 0 6e-09
30 Cpp(1,1,2)(4) 0 0 0 0 6e-09
31 Cpp(1,1,2)(5) 0 0 0 0 6e-09
32 Cpp(1,1,2)(6) 0 0 0 0 6e-09
33 Cpp(1,1,2)(7) 0 0 0 0 6e-09
34 Cpp(1,1,2)(8) 0 0 0 0 6e-09
35 Cpp(1,1,2)(9) 0 0 0 0 6e-09
36 Cpp(1,1,2)(10) 0 0 0 0 6e-09
37 Cpp(1,1,2)(11) 0 0 0 0 6e-09
38 Cpm(1,1,2)(1) 0 0 0 0 6e-09
39 Cpm(1,1,2)(2) 0 0 0 0 6e-09
40 Cpm(1,1,2)(3) 0 0 0 0 6e-09
41 Cpm(1,1,2)(4) 0 0 0 0 6e-09
42 Cpm(1,1,2)(5) 0 0 0 0 6e-09
43 Cpm(1,1,2)(6) 0 0 0 0 6e-09
44 Cpm(1,1,2)(7) 0 0 0 0 6e-09
45 Cpm(1,1,2)(8) 0 0 0 0 6e-09
46 Cpm(1,1,2)(9) 0 0 0 0 6e-09
47 Cpm(1,1,2)(10) 0 0 0 0 6e-09
48 Cpm(1,1,2)(11) 0 0 0 0 6e-09
49 Crpp(1)(1) -4.4e-22 0 -4.4e-22 0 1e-06
50 Crpp(1)(2) -4.4e-22 0 -4.4e-22 0 1e-06
51 Crpp(1)(3) -4.4e-22 0 -4.4e-22 0 1e-06
52 Crpp(1)(4) -4.4e-22 0 -4.4e-22 0 1e-06
53 Crpp(1)(5) -4.4e-22 0 -4.4e-22 0 1e-06
54 Crpp(1)(6) -4.4e-22 0 -4.4e-22 0 1e-06
55 Crpp(1)(7) -1.1e-22 0 -1.1e-22 0 1e-06
56 Crpp(1)(8) 0 0 0 0 1e-06
57 Crpp(1)(9) 0 0 0 0 1e-06
58 Crpp(1)(10) -8.9e-22 0 -8.9e-22 0 1e-06
59 Crpp(1)(11) -8.9e-22 0 -8.9e-22 0 1e-06
60 Crpm(1)(1) -4.4e-22 0 -4.4e-22 0 1e-06
61 Crpm(1)(2) -4.4e-22 0 -4.4e-22 0 1e-06
62 Crpm(1)(3) -4.4e-22 0 -4.4e-22 0 1e-06
63 Crpm(1)(4) -4.4e-22 0 -4.4e-22 0 1e-06
64 Crpm(1)(5) -4.4e-22 0 -4.4e-22 0 1e-06
65 Crpm(1)(6) -4.4e-22 0 -4.4e-22 0 1e-06
66 Crpm(1)(7) -1.1e-22 0 -1.1e-22 0 1e-06
67 Crpm(1)(8) 0 0 0 0 1e-06
68 Crpm(1)(9) 0 0 0 0 1e-06
69 Crpm(1)(10) -8.9e-22 0 -8.9e-22 0 1e-06
70 Crpm(1)(11) -8.9e-22 0 -8.9e-22 0 1e-06
71 Cp(2,1,1)(1) 94.1342 0 94.1342 0 49.2612
72 Cpp(2,1,1)(1) -3.9e-23 0 -3.9e-23 0 8.84e-08
73 Cpp(2,1,1)(2) 0 0 0 0 8.84e-08
74 Cpp(2,1,1)(3) 0 0 0 0 8.84e-08
75 Cpp(2,1,1)(4) 0 0 0 0 8.84e-08
76 Cpp(2,1,1)(5) 0 0 0 0 8.84e-08
77 Cpp(2,1,1)(6) 0 0 0 0 8.84e-08
78 Cpp(2,1,1)(7) 0 0 0 0 8.84e-08
79 Cpp(2,1,1)(8) 0 0 0 0 8.84e-08
80 Cpp(2,1,1)(9) 0 0 0 0 8.84e-08
81 Cpp(2,1,1)(10) 0 0 0 0 8.84e-08
82 Cpp(2,1,1)(11) 0 0 0 0 8.84e-08
83 Cpm(2,1,1)(1) -3.9e-23 0 -3.9e-23 0 8.84e-08
84 Cpm(2,1,1)(2) 0 0 0 0 8.84e-08
85 Cpm(2,1,1)(3) 0 0 0 0 8.84e-08
86 Cpm(2,1,1)(4) 0 0 0 0 8.84e-08
87 Cpm(2,1,1)(5) 0 0 0 0 8.84e-08
88 Cpm(2,1,1)(6) 0 0 0 0 8.84e-08
89 Cpm(2,1,1)(7) 0 0 0 0 8.84e-08
90 Cpm(2,1,1)(8) 0 0 0 0 8.84e-08
91 Cpm(2,1,1)(9) 0 0 0 0 8.84e-08
92 Cpm(2,1,1)(10) 0 0 0 0 8.84e-08
93 Cpm(2,1,1)(11) 0 0 0 0 8.84e-08
94 Cp(2,1,2)(1) 6.00857 0 6.00857 0 3.14433
95 Cpp(2,1,2)(1) 0 0 0 0 5.64e-09
96 Cpp(2,1,2)(2) 0 0 0 0 5.64e-09
97 Cpp(2,1,2)(3) 0 0 0 0 5.64e-09
98 Cpp(2,1,2)(4) 0 0 0 0 5.64e-09
99 Cpp(2,1,2)(5) 0 0 0 0 5.64e-09
100 Cpp(2,1,2)(6) 0 0 0 0 5.64e-09
101 Cpp(2,1,2)(7) 0 0 0 0 5.64e-09
102 Cpp(2,1,2)(8) 0 0 0 0 5.64e-09
103 Cpp(2,1,2)(9) 0 0 0 0 5.64e-09
104 Cpp(2,1,2)(10) 0 0 0 0 5.64e-09
105 Cpp(2,1,2)(11) 0 0 0 0 5.64e-09
106 Cpm(2,1,2)(1) 0 0 0 0 5.64e-09
107 Cpm(2,1,2)(2) 0 0 0 0 5.64e-09
108 Cpm(2,1,2)(3) 0 0 0 0 5.64e-09
109 Cpm(2,1,2)(4) 0 0 0 0 5.64e-09
110 Cpm(2,1,2)(5) 0 0 0 0 5.64e-09
111 Cpm(2,1,2)(6) 0 0 0 0 5.64e-09
112 Cpm(2,1,2)(7) 0 0 0 0 5.64e-09
113 Cpm(2,1,2)(8) 0 0 0 0 5.64e-09
114 Cpm(2,1,2)(9) 0 0 0 0 5.64e-09
115 Cpm(2,1,2)(10) 0 0 0 0 5.64e-09
116 Cpm(2,1,2)(11) 0 0 0 0 5.64e-09
117 Crpp(2)(1) -4.2e-22 0 -4.2e-22 0 9.4e-07
118 Crpp(2)(2) -4.2e-22 0 -4.2e-22 0 9.4e-07
119 Crpp(2)(3) -4.2e-22 0 -4.2e-22 0 9.4e-07
120 Crpp(2)(4) -4.2e-22 0 -4.2e-22 0 9.4e-07
121 Crpp(2)(5) -4.2e-22 0 -4.2e-22 0 9.4e-07
122 Crpp(2)(6) -4.2e-22 0 -4.2e-22 0 9.4e-07
123 Crpp(2)(7) -1e-22 0 -1e-22 0 9.4e-07
124 Crpp(2)(8) 0 0 0 0 9.4e-07
125 Crpp(2)(9) 0 0 0 0 9.4e-07
126 Crpp(2)(10) -8.3e-22 0 -8.3e-22 0 9.4e-07
127 Crpp(2)(11) -8.3e-22 0 -8.3e-22 0 9.4e-07
128 Crpm(2)(1) -4.2e-22 0 -4.2e-22 0 9.4e-07
129 Crpm(2)(2) -4.2e-22 0 -4.2e-22 0 9.4e-07
130 Crpm(2)(3) -4.2e-22 0 -4.2e-22 0 9.4e-07
131 Crpm(2)(4) -4.2e-22 0 -4.2e-22 0 9.4e-07
132 Crpm(2)(5) -4.2e-22 0 -4.2e-22 0 9.4e-07
133 Crpm(2)(6) -4.2e-22 0 -4.2e-22 0 9.4e-07
134 Crpm(2)(7) -1e-22 0 -1e-22 0 9.4e-07
135 Crpm(2)(8) 0 0 0 0 9.4e-07
136 Crpm(2)(9) 0 0 0 0 9.4e-07
137 Crpm(2)(10) -8.3e-22 0 -8.3e-22 0 9.4e-07
138 Crpm(2)(11) -8.3e-22 0 -8.3e-22 0 9.4e-07
139 Crrp(1)(1) 0 0 0 0 9.4e-05
140 Crrp(1)(2) 1.59e-06 0 1.59e-06 0 9.4e-05
141 Crrp(1)(3) 0 0 0 0 9.4e-05
142 Crrp(1)(4) 0 0 0 0 9.4e-05
143 Crrp(1)(5) 1.85e-07 0 1.85e-07 0 9.4e-05
144 Crrp(1)(6) 0 0 0 0 9.4e-05
145 Crrp(1)(7) 0 0 0 0 9.4e-05
146 Crrp(1)(8) 0 0 0 0 9.4e-05
147 Crrp(1)(9) 0 0 0 0 9.4e-05
148 Crrp(1)(10) 0 0 0 0 9.4e-05
149 Crrp(1)(11) 0 0 0 0 9.4e-05
150 Crrm(1)(1) 0 0 0 0 9.4e-05
151 Crrm(1)(2) 0 0 0 0 9.4e-05
152 Crrm(1)(3) 0 0 0 0 9.4e-05
153 Crrm(1)(4) 0 0 0 0 9.4e-05
154 Crrm(1)(5) 0 0 0 0 9.4e-05
155 Crrm(1)(6) 0 0 0 0 9.4e-05
156 Crrm(1)(7) 0 0 0 0 9.4e-05
157 Crrm(1)(8) 0 0 0 0 9.4e-05
158 Crrm(1)(9) 0 0 0 0 9.4e-05
159 Crrm(1)(10) 0 0 0 0 9.4e-05
160 Crrm(1)(11) 0 0 0 0 9.4e-05
161 c00(1)(1) 0 0 0 0 0
162 c00(1)(2) 0 0 0 0 0
163 c00(1)(3) 0 0 0 0 0
164 c00(1)(4) 0 0 0 0 0
165 c00(1)(5) 0 0 0 0 0
166 c00(1)(6) 0 0 0 0 0
167 c00(1)(7) 0 0 0 0 0
168 c00(1)(8) 0 0 0 0 0
169 c00(1)(9) 0 0 0 0 0
170 c00(1)(10) 0 0 0 0 0
171 c00(1)(11) 0 0 0 0 0
172 startup(1)(1) 0 0 0 0 0
173 startup(1)(2) 0 0 0 0 0
174 startup(1)(3) 0 0 0 0 0
175 startup(1)(4) 0 0 0 0 0
176 startup(1)(5) 0 0 0 0 0
177 startup(1)(6) 0 0 0 0 0
178 startup(1)(7) 0 0 0 0 0
179 startup(1)(8) 0 0 0 0 0
180 startup(1)(9) 0 0 0 0 0
181 startup(1)(10) 0 0 0 0 0
182 startup(1)(11) 0 0 0 0 0
183 shutdown(1)(1) 0 0 0 0 0
184 shutdown(1)(2) 0 0 0 0 0
185 shutdown(1)(3) 0 0 0 0 0
186 shutdown(1)(4) 0 0 0 0 0
187 shutdown(1)(5) 0 0 0 0 0
188 shutdown(1)(6) 0 0 0 0 0
189 shutdown(1)(7) 0 0 0 0 0
190 shutdown(1)(8) 0 0 0 0 0
191 shutdown(1)(9) 0 0 0 0 0
192 shutdown(1)(10) 0 0 0 0 0
193 shutdown(1)(11) 0 0 0 0 0
194 c00(2)(1) 0 0 0 0 0
195 c00(2)(2) 0 0 0 0 0
196 c00(2)(3) 0 0 0 0 0
197 c00(2)(4) 0 0 0 0 0
198 c00(2)(5) 0 0 0 0 0
199 c00(2)(6) 0 0 0 0 0
200 c00(2)(7) 0 0 0 0 0
201 c00(2)(8) 0 0 0 0 0
202 c00(2)(9) 0 0 0 0 0
203 c00(2)(10) 0 0 0 0 0
204 c00(2)(11) 0 0 0 0 0
205 startup(2)(1) 0 0 0 0 0
206 startup(2)(2) 0 0 0 0 0
207 startup(2)(3) 0 0 0 0 0
208 startup(2)(4) 0 0 0 0 0
209 startup(2)(5) 0 0 0 0 0
210 startup(2)(6) 0 0 0 0 0
211 startup(2)(7) 0 0 0 0 0
212 startup(2)(8) 0 0 0 0 0
213 startup(2)(9) 0 0 0 0 0
214 startup(2)(10) 0 0 0 0 0
215 startup(2)(11) 0 0 0 0 0
216 shutdown(2)(1) 0 0 0 0 0
217 shutdown(2)(2) 0 0 0 0 0
218 shutdown(2)(3) 0 0 0 0 0
219 shutdown(2)(4) 0 0 0 0 0
220 shutdown(2)(5) 0 0 0 0 0
221 shutdown(2)(6) 0 0 0 0 0
222 shutdown(2)(7) 0 0 0 0 0
223 shutdown(2)(8) 0 0 0 0 0
224 shutdown(2)(9) 0 0 0 0 0
225 shutdown(2)(10) 0 0 0 0 0
226 shutdown(2)(11) 0 0 0 0 0
------- ---------------------------- -------- -------- -------- -------- --------
Sum of Displayed Costs 203.12 0 203.12 0
Generation_cost =
102.9776
106.5349
And unfortunately the sum of displayed costs is different from the sum of generation costs.
The cost terms displayed by display_soln()
should be the generator cost times the scenario probability. So the base case cost terms Cp(t, 1, 1)
are around 97 and 94, while the contingency cost terms Cp(t, 1, 2)
are around 6.
You should be able to match the total by summing the generator cost times the scenario probability for each of the 4 scenarios. It's not clear to me what the two values of Generator cost
is that you are displaying ... the sum for each period?
The two values of Generator cost
are the output of this:
for(i = 1:nt)
gen_cost(i,1) = mdo.om.eval_quad_cost(mdo.om.soln.x, 'Cp', {i,1,1});
gen_cost(i,1) = gen_cost(i,1)/mdo.CostWeightsAdj(1,1,i);
end
Generation_cost = gen_cost(:,1)
When I don't have contingencies, the sum of the values in Generation_cost
are equal to f objective
, that is they are equal to Sum of Displayed Costs
.
When I have contingencies, this doesn't happen, and I also get a lower f objective
.
This is what I can't understand: with contingencies I get higher generation costs (which is correct) but my f objective
is lower (which I don't think makes sense) compared to the case without contingencies.
I hope I explained myself better
The objective function is a simple sum of the the cost terms you are evaluating with eval_quad_cost()
. Without contingencies, the CostWeightsAdj
(the scenario probabilities) are all equal to 1, so they add up to the objective f in your case.
If you do the following for the case with contingencies, you should get the value of the objective function ...
f = 0;
for t = 1:nt
for c = 1:nc+1 % number of contingencies + 1 for the base case
f = mdo.om.eval_quad_cost(mdo.om.soln.x, 'Cp', {t,1,c});
end
end
You only divide by the scenario probability if you want to know what the actual generator cost would be in that scenario. The objective f is the expected cost.
Thank you for everything Professor Zimmerman, you were very kind.
My goal is to compare, using MOST, the total costs (objective function) between some scenarios; however MOST only displays a value of that function. Is there a way to assign each scenario the value of its objective function? Also, is this "f objective" expressed as in Matpower in $/hr? And what is the meaning of a negative "f objective"? I asked myself these questions while I was analyzing the most_ex7_suc.m file.