Report buses out of realistic voltage range in sub reports #1105
Conversation
src/test/resources/saReport.txt
Outdated
| + Buses have a voltage magnitude out of the configured realistic range | ||
| 1 buses have a voltage magnitude out of the configured realistic range [0.5, 1.5] | ||
| Bus VLHV1_0 has an unrealistic voltage magnitude: 1.5105659472379578 pu |
There was a problem hiding this comment.
wouldn't it be more concise this way ?
| + Buses have a voltage magnitude out of the configured realistic range | |
| 1 buses have a voltage magnitude out of the configured realistic range [0.5, 1.5] | |
| Bus VLHV1_0 has an unrealistic voltage magnitude: 1.5105659472379578 pu | |
| + 1 buses have a voltage magnitude out of the configured realistic range [0.5, 1.5] | |
| Bus VLHV1_0 has an unrealistic voltage magnitude: 1.5105659472379578 pu |
There was a problem hiding this comment.
Actually I agree but the current way of organizing reports is that the report container does not hold the severity. And I want the whole information to be appearing as an error and the detailed information appearing as trace. That's why I did it this way. I agree it makes information redundant but I think it's done like that in several places.
There was a problem hiding this comment.
the report container does not hold the severity
Hi @TheMaskedTurtle
Report containers can have severity.
I pushed a commit with a proposal, let me know if this works for you.
Here in JSON serialization. busesOutOfVoltageRealisticRangeSummary has ERROR severity, and busesOutOfVoltageRealisticRangeDetail-s have TRACE severity.
{
"version" : "2.1",
"dictionaries" : {
"default" : {
"acLfComplete" : "AC load flow completed ${successText} (solverStatus=${solverStatus}, outerloopStatus=${outerloopStatus})",
"angleReferenceBusSelection" : "Angle reference bus: ${referenceBus}",
"lfNetwork" : "Network CC${networkNumCc} SC${networkNumSc}",
"loadFlow" : "Load flow on network '${networkId}'",
"networkBalance" : "Network balance: active generation=${activeGeneration} MW, active load=${activeLoad} MW, reactive generation=${reactiveGeneration} MVar, reactive load=${reactiveLoad} MVar",
"networkInfo" : "Network info",
"networkSize" : "Network has ${busCount} buses and ${branchCount} branches",
"newtonRaphsonBusesOutOfRealisticVoltageRange" : "${busCountOutOfRealisticVoltageRange} buses have a voltage magnitude out of the configured realistic range [${minRealisticVoltage}, ${maxRealisticVoltage}] p.u.",
"newtonRaphsonBusesOutOfRealisticVoltageRangeDetails" : "Bus ${busId} has an unrealistic voltage magnitude: ${voltage} p.u.",
"slackBusSelection" : "Slack bus: ${slackBus}",
"testReport" : "Test Report"
}
},
"reportRoot" : {
"messageKey" : "testReport",
"children" : [ {
"messageKey" : "loadFlow",
"values" : {
"networkId" : {
"value" : "sim1"
}
},
"children" : [ {
"messageKey" : "lfNetwork",
"values" : {
"networkNumCc" : {
"value" : 0
},
"networkNumSc" : {
"value" : 0
}
},
"children" : [ {
"messageKey" : "networkInfo",
"children" : [ {
"messageKey" : "networkSize",
"values" : {
"busCount" : {
"value" : 4
},
"branchCount" : {
"value" : 4
},
"reportSeverity" : {
"value" : "INFO",
"type" : "SEVERITY"
}
}
}, {
"messageKey" : "networkBalance",
"values" : {
"activeGeneration" : {
"value" : 607.0
},
"activeLoad" : {
"value" : 600.0
},
"reactiveGeneration" : {
"value" : 0.0
},
"reactiveLoad" : {
"value" : 200.0
},
"reportSeverity" : {
"value" : "INFO",
"type" : "SEVERITY"
}
}
}, {
"messageKey" : "angleReferenceBusSelection",
"values" : {
"referenceBus" : {
"value" : "VLHV1_0"
},
"reportSeverity" : {
"value" : "INFO",
"type" : "SEVERITY"
}
}
}, {
"messageKey" : "slackBusSelection",
"values" : {
"slackBus" : {
"value" : "VLHV1_0"
},
"reportSeverity" : {
"value" : "INFO",
"type" : "SEVERITY"
}
}
} ]
}, {
"messageKey" : "newtonRaphsonBusesOutOfRealisticVoltageRange",
"values" : {
"busCountOutOfRealisticVoltageRange" : {
"value" : 4
},
"minRealisticVoltage" : {
"value" : 0.99
},
"maxRealisticVoltage" : {
"value" : 1.01
},
"reportSeverity" : {
"value" : "ERROR",
"type" : "SEVERITY"
}
},
"children" : [ {
"messageKey" : "newtonRaphsonBusesOutOfRealisticVoltageRangeDetails",
"values" : {
"busId" : {
"value" : "VLGEN_0"
},
"voltage" : {
"value" : 1.0208333333333333
},
"reportSeverity" : {
"value" : "TRACE",
"type" : "SEVERITY"
}
}
}, {
"messageKey" : "newtonRaphsonBusesOutOfRealisticVoltageRangeDetails",
"values" : {
"busId" : {
"value" : "VLHV1_0"
},
"voltage" : {
"value" : 1.0582636574158686
},
"reportSeverity" : {
"value" : "TRACE",
"type" : "SEVERITY"
}
}
}, {
"messageKey" : "newtonRaphsonBusesOutOfRealisticVoltageRangeDetails",
"values" : {
"busId" : {
"value" : "VLHV2_0"
},
"voltage" : {
"value" : 1.0261840057810543
},
"reportSeverity" : {
"value" : "TRACE",
"type" : "SEVERITY"
}
}
}, {
"messageKey" : "newtonRaphsonBusesOutOfRealisticVoltageRangeDetails",
"values" : {
"busId" : {
"value" : "VLLOAD_0"
},
"voltage" : {
"value" : 0.9838500227734096
},
"reportSeverity" : {
"value" : "TRACE",
"type" : "SEVERITY"
}
}
} ]
}, {
"messageKey" : "acLfComplete",
"values" : {
"successText" : {
"value" : "with error"
},
"solverStatus" : {
"value" : "UNREALISTIC_STATE"
},
"outerloopStatus" : {
"value" : "STABLE"
},
"reportSeverity" : {
"value" : "ERROR",
"type" : "SEVERITY"
}
}
} ]
} ]
} ]
}
}There was a problem hiding this comment.
I mean I know it can have a severity but this is not how it is done in most cases currently. And in GridSuite, this case is not well represented in the frontend. This is due to how new report model was migrated, we kept the same structure as before (with no severity on containers). I agree that your solution makes a better use of the current API but it's not aligned with the rest in terms of API usage. But actually that's an important topic we could discuss about it in next PowSyBl workshop.
For now, I think it would be better to stick with the current logic, what do you think ?
There was a problem hiding this comment.
Oh I see.
From my point of view the issue is on GridSuite side.
Only if this is really important AND if others OLF committers agree (@geofjamg @annetill @vidaldid-rte @obrix) then we could accept a little technical debt here.
@TheMaskedTurtle also please link here the corresponding GitHub issue.
There was a problem hiding this comment.
If this is specific to voltage our of range for groups that control voltage remotely, I suggest that we wait a bit before committing. I have now better understanding why these messages pop an how to solve this issue of irrealistic voltage appearing in remote control. We are working on a plan (I hope to be able to document it in an issue soon) that should make most of this logs disappear and resolve as well many stability issues with remote voltage control.
Signed-off-by: Joris Mancini <[email protected]>
Signed-off-by: Joris Mancini <[email protected]>
TheMaskedTurtle
force-pushed
the
jorism/report-buses-oor
branch
from
9ea5d83
to
1b6b732
Compare
Signed-off-by: Damien Jeandemange <[email protected]>
Signed-off-by: Damien Jeandemange <[email protected]>
Signed-off-by: Damien Jeandemange <[email protected]>
jeandemanged
changed the title
|
Please check if the PR fulfills these requirements
What kind of change does this PR introduce?
Split a report where a message can be really big into smaller sub-reports
What is the current behavior?
We're creating a report with a message based on a map that gathers all the network elements that are in error. This list can be really big and we feel this is not a good practice to do so.
What is the new behavior (if this is a feature change)?
Instead of one report gathering all the detailed information we split it into sub-reports with TRACE level and one summary message with ERROR level
Does this PR introduce a breaking change or deprecate an API?