Conditions | 2 |
Total Lines | 102 |
Code Lines | 69 |
Lines | 0 |
Ratio | 0 % |
Changes | 0 |
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
1 | # -*- coding: utf-8 -*- |
||
41 | def main(optimize=True): |
||
42 | # create an energy system |
||
43 | idx = pd.date_range("1/1/2023", periods=100, freq="h") |
||
44 | es = solph.EnergySystem(timeindex=idx, infer_last_interval=False) |
||
45 | |||
46 | # power bus |
||
47 | bel = solph.Bus(label="bel") |
||
48 | es.add(bel) |
||
49 | |||
50 | es.add( |
||
51 | solph.components.Source( |
||
52 | label="source_el", |
||
53 | outputs={bel: solph.Flow(nominal_capacity=1, fix=1)}, |
||
54 | ) |
||
55 | ) |
||
56 | |||
57 | es.add( |
||
58 | solph.components.Sink( |
||
59 | label="sink_el", |
||
60 | inputs={ |
||
61 | bel: solph.Flow( |
||
62 | nominal_capacity=1, |
||
63 | variable_costs=1, |
||
64 | ) |
||
65 | }, |
||
66 | ) |
||
67 | ) |
||
68 | |||
69 | # Electric Storage |
||
70 | |||
71 | inflow_capacity = 0.5 |
||
72 | full_charging_limit = 0.4 |
||
73 | storage_capacity = 10 |
||
74 | battery = solph.components.GenericStorage( |
||
75 | label="battery", |
||
76 | nominal_capacity=storage_capacity, |
||
77 | inputs={bel: solph.Flow(nominal_capacity=inflow_capacity)}, |
||
78 | outputs={bel: solph.Flow(variable_costs=2)}, |
||
79 | initial_storage_level=0, |
||
80 | balanced=False, |
||
81 | loss_rate=0.0001, |
||
82 | ) |
||
83 | es.add(battery) |
||
84 | |||
85 | if optimize is False: |
||
86 | return es |
||
87 | |||
88 | # create an optimization problem and solve it |
||
89 | model = solph.Model(es) |
||
90 | |||
91 | def soc_limit_rule(m): |
||
92 | for ts in m.TIMESTEPS: |
||
93 | soc = ( |
||
94 | m.GenericStorageBlock.storage_content[battery, ts + 1] |
||
95 | / storage_capacity |
||
96 | ) |
||
97 | expr = (1 - soc) / (1 - full_charging_limit) >= m.flow[ |
||
98 | bel, battery, ts |
||
99 | ] / inflow_capacity |
||
100 | getattr(m, "soc_limit").add(ts, expr) |
||
101 | |||
102 | setattr( |
||
103 | model, |
||
104 | "soc_limit", |
||
105 | po.Constraint( |
||
106 | model.TIMESTEPS, |
||
107 | noruleinit=True, |
||
108 | ), |
||
109 | ) |
||
110 | setattr( |
||
111 | model, |
||
112 | "soc_limit_build", |
||
113 | po.BuildAction(rule=soc_limit_rule), |
||
114 | ) |
||
115 | |||
116 | # solve model |
||
117 | model.solve(solver="cbc") |
||
118 | |||
119 | # create result object |
||
120 | results = solph.processing.results(model) |
||
121 | |||
122 | plt.plot( |
||
123 | results[(battery, None)]["sequences"]["storage_content"], |
||
124 | "r--", |
||
125 | label="content", |
||
126 | ) |
||
127 | plt.step( |
||
128 | 20 * results[(bel, battery)]["sequences"]["flow"], |
||
129 | "b-", |
||
130 | label="20*inflow", |
||
131 | ) |
||
132 | plt.legend() |
||
133 | plt.grid() |
||
134 | |||
135 | plt.figure() |
||
136 | plt.plot( |
||
137 | results[(battery, None)]["sequences"]["storage_content"][1:], |
||
138 | results[(bel, battery)]["sequences"]["flow"][:-1], |
||
139 | "b-", |
||
140 | ) |
||
141 | plt.grid() |
||
142 | plt.xlabel("Storage content") |
||
143 | plt.ylabel("Charging power") |
||
150 |