railjson_generator: unterminated block at end of route when using a link btw track sections

ed-rhilbert commented 1 year ago

What happened?

    station0 (2 tracks)                        station1 (2 tracks)

           ┎S0                                      S4┐
    (T0)-----D0-                                  --D4---------(T4)-->
                \   S2┐                    ┎S3  /
               CVG>-D2-----(T2)--+--(T3)----D3-<DVG
           ┎S1   /                              \   S5┐
    (T1)-----D1-                                  --D5---------(T5)-->

    All tracks are 500m long
    Train 0 starts from T0 at t=0 and arrives at T4
    Train 1 starts from T1 at t=100 and arrives at T5

When run with the CLI API of OSRD Core (java -jar .../osrd-all.jar ...), the infra above , generated with the attached python script, gives the warnings

[15:07:17,786] [DEBUG]          [BlockBuilder] unterminated block at end of route rt.D0->D2
[15:07:17,790] [DEBUG]          [BlockBuilder] unterminated block at end of route rt.D1->D2
[15:07:17,792] [DEBUG]          [BlockBuilder] no signal at non buffer stop
[15:07:17,794] [DEBUG]          [BlockBuilder] no signal at non buffer stop
[15:07:17,795] [DEBUG]          [BlockBuilder] no signal at non buffer stop
[15:07:17,797] [DEBUG]          [BlockBuilder] no signal at non buffer stop
[15:07:17,799] [DEBUG]          [BlockBuilder] unterminated block at end of route rt.D4->D3
[15:07:17,801] [DEBUG]          [BlockBuilder] unterminated block at end of route rt.D5->D3

and the error

[14:45:08,129] [INFO]  [StandaloneSimulationCommand] Running simulation for schedule group: group.4
Exception in thread "main" fr.sncf.osrd.api.pathfinding.response.NoPathFoundError: No path could be found
    at fr.sncf.osrd.api.pathfinding.PathfindingRoutesEndpoint.computePaths(PathfindingRoutesEndpoint.java:167)
    at fr.sncf.osrd.api.pathfinding.PathfindingRoutesEndpoint.runPathfinding(PathfindingRoutesEndpoint.java:118)
    at fr.sncf.osrd.cli.StandaloneSimulationCommand.run(StandaloneSimulationCommand.java:94)
    at fr.sncf.osrd.App.main(App.java:44)

cvg_dvg_bug.py.txt infra.json.txt simulation.json.txt

What did you expect to happen?

The same infra without a link between track sections runs ok !

    station0 (2 tracks)                        station1 (2 tracks)

           ┎S0                                      S3┐
    (T0)-----D0-                                  --D3---------(T3)-->
                \   S2┐                   ┎S2a  /
               CVG>-D2-----(T2)------------D2a-<DVG
           ┎S1   /                              \   S4┐
    (T1)-----D1-                                  --D4---------(T4)-->

    All tracks are 500m long
    Train 0 starts from T0 at t=0 and arrives at T3
    Train 1 starts from T1 at t=100 and arrives at T4

cvg_dvg.py.txt infra.json.txt results.json.txt simulation.json.txt

How can we reproduce it (as minimally and precisely as possible)?

Run standalone simulations with the given infra.json and simulation.json

What operating system, browser and environment are you using?

OS: Windows 10
Env: WSL/ Ubuntu
railjson_generator: version 0.1.1

OSRD version (top right corner `Account` button > `Informations`)

92ae674180f49cf9c29ceb6f07adc5aba591f320

multun commented 1 year ago

Thanks for reporting the issue! The issue you're experiencing is due to incorrect detectors being linked to your signals:

At this point, you assume detectors[i] yields detector D{i}:

    signals = [
        T[i].add_signal(
            detectors[i].position-20,
            Direction.START_TO_STOP,
            linked_detector=detectors[i],
            label=f"S{i}"
        )
        for i in [0, 1, 3]
    ]

However, when created, detectors are added to the array out of order:

    detectors = [
        T[i].add_detector(label=f"D{i}", position=450)
        for i in [0, 1, 3]
    ]
    detectors += [
        T[i].add_detector(label=f"D{i}", position=50)
        for i in [2, 4, 5]
    ]

This issue can be fixed by appending detectors in order:

    detectors = [
        T[i].add_detector(label=f"D{i}", position=(450 if i in (0, 1, 3) else 50))
        for i in range(0, 6)
    ]

A consequence of this mixup is that the detector associated with S2 is D3, and the detector associated with S3 is D2. This is invalid, as linked detectors should always be in downstream of signals. The route generator does not detect this edge case, and happily proceed to generate routes which stop at the associated detectors:

2023-07-19_11-07-1689759360

This invalid setup should definitely have been detected. I've opened an issue on the matter: #4613

We noticed a few additional issues with the route generator, which we'll fix as soon as we can:

the algorithm used to generate routes by railjson_generator does not take signal type into account #4603 (not the issue you reported)
extra track links are added alongside switches #4612 (should not make a difference)

multun commented 1 year ago

@ed-rhilbert I just made a few changes to the railjson generator, some of which would have helped with your issue :

detectors are associated automatically
when adding a signal, you now need to specify whether it's a route delimiter
you can now add routes manually if you want to

Please get in touch if you need any help. (I'll be on holidays next week)

If you managed to sort things out, you can close the issue

ed-rhilbert commented 1 year ago

Hi @multun,

Back from holidays, I will test this new version. Sounds promising... I will let you know if everything is ok.

Anyway, thanks for considering my issues and your detailed answers 🙂

ed-rhilbert commented 1 year ago

@multun , I confirm everythins is ok. Thanks again !

OpenRailAssociation / osrd