FET-5.33 or later - does it still solve your previous files?

[Liviu Lalescu]

Please report here if your file was solved by older versions of FET (until FET-5.32.3), and you tried to generate also with FET-5.33.0 or later. Did it solve also with FET-5.33.0 (good) or not (bad)?

There might be problems only if your file contains constraints teachers/students max hours daily.

In case if your file is not solved with FET-5.33.0 or later (but is solved by FET-5.32.3 or previous versions), please send it to me by email. I will keep it private.

It is very important!

Any results are important - so please report positive or negative results. In case of positive results the input file is not needed, if it is private.

[Benahmed Abdelkrim]

I did a test with this latest version. it's OK

[Liviu Lalescu]

Thank you!

[mercurialuser]

Hi Liviu,
I'm back :-)

I'm again helping a school to create a timetable with FET.  This time I will teach a couple of teachers how to translate the requests from the teacher into constraints.

I'm using max gaps per day and per week. I will report tomorrow if I get valid timetable with the new version. I diffed the source code but was not able to fully understand where the bug was. Is it explained somewhere?

Thanks

[Liviu Lalescu]

Welcome back!

The bug: if the user had max hours daily constraints, along with max gaps constraints, and fixed some activities indirectly. A day, for instance Monday, had activities in the first slot and last slot, and the program did not consider it can replace activities from other days, so it cycled trying to replace only activities from Monday (at level 0). I cannot explain better.

If you are not using max hours daily, everything is the same, no need to report.

[mercurialuser]

I do use max hours per day (usually 5) and max consecutive (usually 4, but some have 3).

After my last changes I was not able to close a timetable... 638 out of 639 placed... just one missing... the activity not placed has also a tag with students maximum daily hours with tag..

I will test tomorrow

Thank you

[mercurialuser]

I did the tests on my server and I got timetables (I run parallel jobs on a server):
At time 0 h 1 m 18 s, FET reached 639 activities placed
At time 0 h 4 m 19 s, FET reached 639 activities placed
At time 0 h 0 m 58 s, FET reached 639 activities placed
At time 0 h 2 m 38 s, FET reached 639 activities placed
At time 0 h 1 m 59 s, FET reached 639 activities placed
At time 0 h 3 m 28 s, FET reached 639 activities placed
At time 0 h 1 m 21 s, FET reached 639 activities placed
At time 0 h 3 m 35 s, FET reached 639 activities placed
At time 0 h 3 m 57 s, FET reached 639 activities placed
At time 0 h 1 m 9 s, FET reached 639 activities placed
At time 0 h 2 m 7 s, FET reached 639 activities placed
At time 0 h 2 m 7 s, FET reached 639 activities placed
At time 0 h 3 m 16 s, FET reached 639 activities placed
At time 0 h 2 m 2 s, FET reached 639 activities placed
At time 0 h 3 m 37 s, FET reached 639 activities placed
At time 0 h 1 m 29 s, FET reached 639 activities placed

I still have to fine tune the constraints, I'm gonna ask some more questions :-)

[Liviu Lalescu]

Thank you for the report! So all these 16 are finished timetables? (I suppose you run by command-line.)

[mercurialuser]

Yes, I have a script that starts 16 fet-cl instances waiting 2 seconds between them to have different random seeds...
Another script tails the max_placed_activities.txt files and also does a diff...

[Volker Dirr]

It would be interesting if you run exactly the same dataset once with the old fet and once with the new fet; maybe 20 times or more. Only if you compare the same dataset with new and old fet we can "prove" that the bugfix is fine.