WIP: XnecProvider accepts paired Dangling Lines

[caioluke]

WORK IN PROGRESS

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce?

Feature

What is the current behavior?

XnecProvider currently accepts only Branches.

What is the new behavior (if this is a feature change)?
XnecProvider will also accept paired DanglingLines.

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

[caioluke]

@OpenSuze @murgeyseb what do you think about this idea? Extending the XnecProvider API to also accept paired DanglingLines.

It is not finished, I will still need to do some work on the PTDF calculations and most likely in other places of the code.

But before doing so, please tell me what you think about this implementation!

Thanks

[sonarqubecloud]

Quality Gate failed

Failed conditions
56.6% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[murgeyseb]

@caioluke I think that this proposal is not a good solution as it clearly opens many potential issues in the usage of the algorithm.
I would prefer a specific implementation on your side of XnecProvider that actually does the conversion. E.G.

public class XnecProviderImpl implements XnecProvider {
    private static final Logger LOGGER = LoggerFactory.getLogger(XnecProviderImpl.class);
    private final String danglingLineId;

    public XnecProviderImpl(String danglingLineId) {
        this.danglingLineId = Objects.requireNonNull(danglingLineId);
    }

    @Override
    public Set<Branch> getNetworkElements(Network network) {
        DanglingLine danglingLine = network.getDanglingLine(danglingLineId);
        if (danglingLine == null) {
            LOGGER.warn("Branch {} was not found in network {}", danglingLineId, network.getId());
            return Collections.emptySet();
        }
        // check if dangling line is duly paired
        if (danglingLine.isPaired()) {
            return Set.of(danglingLine.getTieLine().get());
        } else {
            LOGGER.warn("DanglingLine {} is not paired: will not decompose such flows", danglingLineId);
            return Collections.emptySet();
        }
    }

    @Override
    public Set<Branch> getNetworkElements(String contingencyId, Network network) {
        return Collections.emptySet();
    }

    @Override
    public Map<String, Set<Branch>> getNetworkElementsPerContingency(Network network) {
        return Collections.emptyMap();
    }

    @Override
    public List<Contingency> getContingencies(Network network) {
        return Collections.emptyList();
    }
}

You can also add the same kind of implementation for your observers

[caioluke]

@murgeyseb
Thank you for your reply.
Ok, I could create a XnecProviderByDanglingLineId that provides the TieLine instead.
But what I still don't get it, is how I would get in the end DecomposedFlows for my original DanglingLine...

The observer part is being handled in #171, so the only thing remaining is really the final decomposed flows.

[murgeyseb]

@caioluke You can do something like that :

Network network = Network.read("");
Set<String> danglingLineIds = Set.of("dl1", "dl2");
Map<String, String> tieLineOfDanglingLine = danglingLineIds.stream()
        .collect(Collectors.toMap(
                Function.identity(),
                id -> network.getDanglingLine(id).getTieLine().get().getId()
        ));
XnecProvider xnecProvider = XnecProviderByIds.builder().addNetworkElementsOnBasecase(Set.copyOf(tieLineOfDanglingLine.values())).build();
FlowDecompositionResults results = new FlowDecompositionComputer().run(xnecProvider, network);
Map<String, DecomposedFlow> decomposedFlowByDanglingLine = tieLineOfDanglingLine.entrySet().stream()
        .collect(Collectors.toMap(
                entry -> entry.getKey(),
                entry -> results.getDecomposedFlowMap().get(entry.getValue())
        ));

You can use same type of trick (mapping from dangling line to tie line) in your own Observer implementation

[caioluke]

@murgeyseb
Hmmm, interesting. I'll do some testing on my side and see what I can come up with. Thanks!

[caioluke]

@murgeyseb
After some testing, we will keep your solution. Indeed it makes more sense to have the same flow decomposition for both paired dangling lines.
I'll close this PR and the other one too.
Thanks for the help!