Closed noahrhodes closed 2 years ago
Merging #60 (5a10c93) into master (f978eed) will decrease coverage by
0.71%
. The diff coverage is89.20%
.
@@ Coverage Diff @@
## master #60 +/- ##
==========================================
- Coverage 90.71% 90.00% -0.72%
==========================================
Files 19 19
Lines 1561 1570 +9
==========================================
- Hits 1416 1413 -3
- Misses 145 157 +12
Impacted Files | Coverage Δ | |
---|---|---|
src/core/constraint_template.jl | 92.10% <ø> (ø) |
|
src/prob/mrsp.jl | 95.83% <ø> (ø) |
|
src/util/restoration_redispatch.jl | 71.15% <ø> (ø) |
|
src/core/data.jl | 80.36% <88.97%> (-3.18%) |
:arrow_down: |
src/core/constraint.jl | 86.81% <100.00%> (ø) |
|
src/core/ref.jl | 100.00% <100.00%> (ø) |
|
src/prob/rop.jl | 94.93% <100.00%> (ø) |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update f978eed...5a10c93. Read the comment docs.
The three terms related to the status of components are 1) active (inactive) 2) damaged 3) repairable
The component status value, e.g. gen["gen_status"]==1
determines if a component is active.
The damaged status is determined by gen["damaged"]==1
A component is repairable if is it active and damaged, gen["gen_status"]==1&&gen["damaged"]==1
.
Why? if a component is not active, it is filtered out of the network by the powermodels functions (build_ref
I believe?). When determining how many repairs can be done, this must be accounted for.
In addition, this allows heuristic problems like RAD to only consider repairing items that are active
, i.e. a component that is damaged but not active is for future restoration, but not in this problem.
The name active/inactive
does conflict with its meaning in these restoration problems. An inactive branch does not participate in restoration, but is reads as "a branch that is not yet repaired".
Do you have a suggestion for a different name than inactive?
The term items
is less specific, I like the use of components
in these function names more.
There are two additional functions with items
in their names. Should these also be changed?
ref_add_damaged_items!
-> ref_add_damaged_components!
constraint_restore_all_items
-> constraint_restore_all_components
Regarding items vs components, it like we are in agreement all can be updated to components.
Looking into the second point.
I am currently thinking the use and definition of active, inactive, damaged, restorable makes sense. But we should probably add the definitions, as you mention here, to the docs. :-)
@ccoffrin Changes are finished, should be ready after you verify the documentation changes!
@ccoffrin a few changes made. should be ready.
Great, tests are passing so merging!
Make support for multinetwork returns explicitly disallowed for
count_repairable_items
,get_repairable_items
,damage_items!
,count_damaged_items
,get_damaged_items
,get_isolated_load
,clear_damage_indicator!
These functions previously allowed multinetworks to be passed in, but the functions do not have a clear return. Does
count_damaged_items
return the total number of damaged items in every single period, or the unique items that are damaged in any period? Instead, these functions should be run for individual networks within a multinetwork.Add
get_inactive_items
,count_inactive_items
,get_active_items
,count_active_items
New data functions necessary for the implementation of restoration heuristics.