crowdAI is shutting down - please read our blog post for more information
Optimizing train schedules
By SBB CFF FFS
over 1 year ago
I wanted to submit a solution produced by a very simple program I came up with. However, I get errors of the following form:
- Exit time 07:57:47 after exit_latest 07:29 (+ max. Bandabweichung PT5M) for Train run sections with route_section_id “20423#295” and Section Marker “ZG_Halt” in service_intention “20423”
- Entry time 07:41:04 after einMax 07:09 (+ max. Bandabweichung PT5M) for Train run sections with route_section_id “20423#142” and Section Marker “TW_Halt” in service_intention “20423”
I don’t understand why this is an error, shouldn’t entry_/exit_latest be a soft constraint and only produce a warning? (Business rule #101)
Thanks for your help
over 1 year ago |
You’re absolutely right, it should be a soft constraint. There is a parameter in the problem instances called “maxBandabweichung”, which translates roughly to “maximum allowed delay”. It seems we actually coded this as a hard rule in the grader. Meaning the grader now warns for delays between 0 and the maximum allowed delay, and throws an error for larger delays.
Will look into it. The easiest solution should be to remove this parameter from the instances. But let me test this first. If it works, I will let you know when the updated instances have been uploaded to the repo
@traintraintrain : Would you mind sending me your solution file to firstname.lastname@example.org? This way I could verify if the fix works.
over 1 year ago |
Thanks, I sent you the files
about 1 year ago |
Hi, I’m testing some solutions and noticed the same problem. Will the problem be solved? Should I ignore these errors and submit anyway? It would be great if this is solved so I can check the solutions value before submitting.
about 1 year ago |
Hi @elTuki .
“Behind the scenes” the business rule 101 is actually implemented with a hard constraint that the delay must not be more than 24 hours for any of the trains. I figured that would be enough delay for everybody. Also, we don’t really handle the case when a train crosses midnight - our data model only handles a time-of-day, not a datetime. For this reason we kind of have to insist that all trains can be delayed, but not so much that they are not scheduled on the same day anymore.
If you still get validation errors, my guess is that at least one train is delayed more than 24 hours. Is this possible?
I supposed there was a time limit of 23:59 for all entry/exit times. Nevertheless, I’m submitting a solution for instance 2 and getting the following errors (only 2 as example):
Exit time 07:01:18 after exit_latest 06:16 (+ max. Bandabweichung PT5M) for Train run sections with route_section_id “16920#40” and Section Marker “FRBS” in service_intention “16920”
Entry time 07:02:14 after einMax 06:41 (+ max. Bandabweichung PT5M) for Train run sections with route_section_id “5059#247” and Section Marker “PF_Halt” in service_intention “5059”
For these cases, it does not appear as a problem with scheduling for the next day. For the first case, exit_latest is set at 6:16 and the solution has exit time at 7:01:18, less than one hour more. Similar for the second case.
It seems that the errors is because of the hard constraint of no more than 5 minutes of delay, and not because of passing to the next day.
@elTuki : Ah, yes, that was indeed the problem traintraintrain reported. We updated the problem instances to allow a max delay of up to 24 hours. Did you pull the repository recently?
Try a pull to get the latest updates and then check the files. You should find the following lines:
probably now it say ‘PT5M’ instead of PT24H.
Perfect, I’ve changed the parameter in the instances and the issue is solved.