Open sylvlecl opened 1 year ago
@annetill @EtienneLt @geofjamg Any opinion about the renaming propositions ? This would promote the concept of "configured bus" from an implementation detail in java to the API level, which seems necessary to me for clarity.
API clarification.
The difference between calculated buses of the bus view and "configured" buses of the bus-breaker view can be confusing to users. In the API, it's not always clear what kind of buses we are referring to.
For example, when you create buses, you actually create "configured" buses, which will not appear when calling
get_buses
, which returns buses from the bus view:Another example, when you create an element, you can specify a "bus_id" to define where it should be connected. Here we expect a "configured" bus, not a bus from the
get_buses
method, which can be confusing:We should clarify where "configured" buses are expected or returned, instead of buses from the bus view.
In order to achieve this, we will need in particular to agree on some wording. Currently, in returned dataframes, we have both
bus_id
andbus_breaker_bus_id
columns.Therefore, we could use "bus_breaker_bus" wherever a configured bus is expected/returned, but:
--> should we use
configured_bus
in those places instead ?create_buses
would becomecreate_configured_buses
, andbus_id
in creation methods would be renamed toconfigured_bus_id
instead. Columns in returned dataframes would remainebus_breaker_bus_id
, because it's more generic thanconfigured_bus_id
, although still ugly.Slightly linked with design issue https://github.com/powsybl/powsybl-core/issues/2168 in powsybl-core, where the "configured bus" does not exist in the API either.