Hi!
FET allows to assign activity tags to activities, e.g. allowing to add the activity tag "lecture" to all lectures. However, if I want to add a rule that lectures may only be schedules between 8:00-14:00, I have to add the constraint
"Time -> Activities -> Preferred Time -> An activity as a set of preferred time slots" to all activities that are describing lectures.
This approach of modeling contraints for these activities has two downsides. Firstly, it is quite time consuming adding dozents of identical contraints to the various lecture activities. Secondly, it's difficult to remain consistency: it's easy to miss one lecture activity, so that this activity ends up without this constraint. Same if a contraint is modified (e.g. setting the time span for lectures from 8:00 to 16:00) it demands ALL contraints related to lectures to be modified.
It would be highly helpful if FET would support contraints related to activity tags.
Basically I'm thinking of something like a button "Time -> Activity Tags" with nearly identical content as "Time -> Acticities", e.g. "Time -> Activity Tags -> Preferred Times -> An activity tag has a set of preferred time slots".
Internally FET could analyze these constraints and translate them in regular activity constaints: for instance, if there is such a "An activity tag has a set of preferred time slots" contraint for activity tag "lecture", it generates a "An activity has a set of preferred time slots" constraint for each activity that has the activity tag "lecture".
Of course there are special cases that need to be handled, e.g. if an activity has multiple activity tags that would cause the generation of multiple contraints of the same type. However I think that this would be manageable with very little effort, particularly without the need of changing the solver in any way.
FET is already a real power horse. Thanks for all the effort you're putting into it. But being able to define constraints based on activity tags would be a huge leap forward (at least for me ;) ).
Best, Matthias
Hello, Matthias,
It is there!!! Activities preferred starting times/time slots :) Sorry for your wasted time until now.
A set of activities has a set of preferred starting times/time slots.
Hi Liviu!
Thanks for your fast response. I have to admit that my example wasn't chosen well, because one of my two problems can be solved the way you described. However, the other problem remains: ensuring consistency in case that constraints are based on the type of an activity.
What I mean are constraints like these:
- regular lectures shall be scheduled between 8:00 and 14:00 (because we made some bad experiences with evening lectures)
- lectures for students in the first and second semester shall be scheduled between 8:00 and 12:00
- activities in our open air lab shall end the students day
- there shall be at least one gap between exercises
- block courses shall be scheduled on Friday afternoon or Saturday
At the moment FET requires adding these constraints to each activity seperately. That means if I'm adding a new activity, I have to identify the required constraints and then adding them in the second step. For instance, if I'm adding a lecture activity of first semester students, I have to add a constraint that the lecture shall be scheduled between 8:00 and 12:00. When adding other activities, it might also be necessary to modify previously defined constraints, e.g. max days between set of activities.
In general, each time I'm adding a new activity, I have to ensure that I'm not only adding all required constraints to this new activity, but also modify existing constraints with the newly created activity. I have to be super attentive to add and modify all constraints correctly, because it is quite easy to miss something.
This situation is due to the fact that constraints are modeled as "properties" of the activity. I know that this description is not overly accurate, but let me just call it this way.
What I'm suggesting is adding some kind of inheriting concept where activities may inherit their time constraints from activity tags. Thus, instead of modeling them as "property" of the activity itself, they might be modeled as "property" of an activity tag. Such a concept already exists for rooms, where I can specify preferred rooms for an activity tag, but not for time.
For instance:
- If there would be a Time -> Tags -> Activities with an activity tag have a set of preferred time slots, I might add such a constraint and define that activity tag LECTURE shall be scheduled Monday to Friday between 8:00 and 14:00.
- When adding a new activity for a lecture, I just add the activity tag LECTURE, not having to define any specific time constraints
- When generating a schedule, FET now has to translate the above time constraint into regular time constraints for the activity. Following the example, FET could create a regular Time -> Activities -> Preferred Times -> An Activity has a set if preferred time slots constraint for each activity with activity tag LECTURE.
From my point of view this modeling concept would have three major advantages:
- The amount of time constraints that need to be defined would reduce significantly (at least in my usage case), since time constraints need to be defined just once for the activity tag and not for each activity seperately.
- The modeling of a new schedule gets less error prone.
- Modifying constraints becomes less time consuming. Let's assume that a schedule cannot be generated with the mentioned time constraint for lectures. So we decide to enhance the duration for lectures until 16:00. Currently I would have to modify all time constraints for all lectures and change 14:00 into 16:00. If there would be a time constraint for an actitiy tag, I would just have to change this single constraint.
And in my naive understanding of FET I assume that implementing these constraints should be pretty simple, because activity tag constraints are just translated into activity constraints, thus the solver does not have to be modified or enhanced in any way.
Besides the mentioned constraint for activity tags, there might be also others:
- Time -> Tags -> Activities with an activity tag have a set of preferred time slots as just described
- Time -> Tags -> Activities with an activity tag have a prefered starting time
- Time -> Tags -> Min days between activities with an activity tag
- Time -> Tags -> Activities with an activity tag begins students day
- Time -> Tags -> Activities with an activity tag ends students day
- Time -> Tags -> Activities with an activity tag ends teachers day
- Time -> Tags -> Activities with an activity tag have same starting time
- Time -> Tags -> Activities with an activity tag occupy min slots
- Time -> Tags -> Activities with an activity tag occupy max slots
- Time -> Tags -> Activities with activity tag A and activity tag B are ordered
- Time -> Tags -> Max hourly span for Activities with an activity tag
- Time -> Tags -> A set of activity tags is not overlapping: this is already existing!
- Time -> Tags -> Min gaps between activities with an activity tag
As a matter of fact there are things that might go wrong or need to be handled. For instance this procedure might generate contradicting time constraints for an activity. This might result in an error during scheduling, so that the user has to modify her configuration. Or the user has already created a constraint for an activity where the same type activity constaint would be generated from actitiy tag. In this case the firstly created constraint could overrule the activity tag based constraint.
Phew, that was a long posting. Thanks for reading it.
Best, Matthias
Hello, Matthias,
For what you need, it is there :) , as I said. Please see the 4 attached screenshots. For min gaps between unordered pair of tags (AT1, AT2), you need to add two ordered pairs (AT1, AT2) and (AT2, AT1).
I will add in the TODO the remaining constraints, but I doubt they are very useful:
Time -> Tags -> Min days between activities with an activity tag
Time -> Tags -> Activities with an activity tag have same starting time
Time -> Tags -> Activities with an activity tag occupy min slots
Time -> Tags -> Activities with an activity tag occupy max slots
Time -> Tags -> Activities with activity tag A and activity tag B are ordered
Time -> Tags -> Max hourly span for Activities with an activity tag
They might be too strong. Maybe they would be useful for students (set)/teacher(s).
FET respects all the constraints; this is in my opinion correct. No exceptions (I refer to your "older constraint wins).