Loading
Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more

crowdAI is shutting down - please read our blog post for more information

Train Schedule Optimisation Challenge

Optimizing train schedules


Completed
209
Submissions
444
Participants
29671
Views

Locking of resource by the same service intention and release time

Posted by iquadrat about 1 year ago

On certain train routes, the same resource is needed twice, usually just with releasing it for a single section inbetween. It seems to me it should be possible to hold the resource for the full period of time instead of releasing and re-acquiring it. However, it seems the validation script forces that the resource is release in-between and the release time is respected. So, I get errors like

  • Occupancy conflict (Blocking resource) Release time[s] 20, Resource: “SBG-LITT_420”, service_intentions: “20437” / “20437”, route_sections: “20437#90217” / “20437#90210”, Times entry-exit: 10:52:39-10:53:24 / 10:52:17-10:52:27

As you see, it is the same service intention (20437) for entry-exit. Is it really not possible to hold the resource the hole time instead of releasing it?

Posted by jordiju  about 1 year ago |  Quote

Hi @iquadrat : Is this for instance 09?

Looks also a bit weird to me also. It probably is a train that changes direction on the route_section in between. I have to ask the guy that came up with it. Will get back to you.

Posted by jordiju  about 1 year ago |  Quote

@iquadrat : I assume this was in instance 09. That was indeed an error. Thanks for the acute observation!

I have deleted the complete route_path from the route for all odd-numbered 204xx trains and pushed the update for instance 09. Please pull the update.

It is possible you might run into similar problems with different service intentions. If so, please let me know.

Posted by iquadrat  about 1 year ago |  Quote

Yes, it was for instance 09. It also happens for other instances, e.g., for instance 02 with 20423 and HGO_73. But for all cases except in instance 09, the minimum running time of the section between release and re-acquire is larger than the minimum release time, so it does not really matter.

It still happens with the updated instance 09: For trains 2621, 2625, 2629, 2633, 2637,2641,2645 and BAA_72 (also BAAN_1, BAA_92, BAA_82 but there it is never an issue for the reason stated above.)

Just re-read the business rules, they say “Let S1 and S2 be two train_run_sections belonging to distinct service_intentions T1, T2 and such that the associated route_sections occupy at least one common resource.”

It says the resource occupation rule applies for distinct service_intentions only. Please fix.

Posted by jordiju  about 1 year ago |  Quote

Yes, it was for instance 09. It also happens for other instances, e.g., for instance 02 with 20423 and HGO_73. But for all cases except in instance 09, the minimum running time of the section between release and re-acquire is larger than the minimum release time, so it does not really matter.

Great, thanks! I will fix the remaining occurrences in 09 tomorrow.

Regarding the business rule, if we catch all occurrences where a conflict might result while respecting all other rules, it is probably better to leave it unchanged - seeing as people have now worked under this premise for a long time. If anything, we should probably change the evaluator.

Posted by jordiju  about 1 year ago |  Quote

By the way, very curious to see a solution for 09. We have never seen one ;)