IEEE 1366 metrics do not update according to pole failures

[aivanova5]

Problem description

Running a pole failure analysis with the fault_check and reliability module does not update the SAIDI/CAIDI etc metrics as the failure occurs.

Steps to reproduce

1. Download attached
2. Run gridlabd test_reliability.glm
3. Note, fault check object does NOT detect a fault, pole_status in test_pole.csv does update to FAILED once critical wind threshold is hit, while IEEE 1366 are NOT updated.

System information

• GridLAB-D version: HiPAS GridLAB-D 4.3.8-240319 (develop) Darwin
• Operating system: Darwin PC99458 22.6.0 Darwin Kernel Version 22.6.0: Tue Nov 7 21:48:06 PST 2023; root:xnu-8796.141.3.702.9~2/RELEASE_X86_64 x86_64
  test_reliability.zip

[ftuffner]

Looks like there are a couple things going on here. For the wind speed trigger, it appears to happen two hours later, so it is happening, just not on the right timestamp/timestep. Still poking around on that one.

For the 1366 metrics, that's because the only thing that triggers those are eventgen objects (and possibly indirectly through link_fault_on/link_fault_off in powerflow/link.cpp, but I think that's only for switch-specific objects). Normal outages don't trigger the metrics, hence no update. So "by current design" is basically the cause here, but there could be something added to the fault_check or the pole objects to trigger a metrics update if they fail (or have meters/triplex_meters/"customers" do it if they have zero voltage).

[ftuffner]

One idea for implementing this is to leverage what the switch_object in powerflow does where it uses the add_event call back to the eventgen object - this could potentially reference to the pole object, but have a functions exposed as create_fault and fix_fault (they may not do anything). That should replicate the fault-triggered and restoration behavior link objects have, but apply it to the pole. That should calculates the 1366 metrics.

The other option is to have either the pole or maybe the fault_check object call the get_interrupted_count_secondary and get_interrupted_count functions inside the metrics object (eventgen calls it right now - the _sec function is for momentary outages).

These may be some half-measure implementations, but they would at least leverage the existing code approaches. There's probably some unknowns in here that will cause issues, but these two would be some initial approaches to investigate.