Question about spreading subactivities...

Started by mbarsan, September 29, 2009, 10:00:57 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

mbarsan

I have a 5 hours activity splitted 2+1+1+1.

How can I constraint those subactivities to obtain that never the 2 hours component can be placed near a 1 hour subactivity?

Consider that I want, if it isn't possible to place all subactivities in different days, that FET puts two 1 hour subactivities joined in a same day.

Do you know a simple constraint to obtain this result?

Thank you!  :)  


mbarsan

#1
Is the following the best solution that you can think?

We have, say, S1+S2+S3+S4 where S1 is a 2 hours subactivity and S2, S3 and S4 are 1 hour subactivities.

Add three constraints -using a weight of 100%- Min days between a set of activities:
1) S1 and S2
2) S1 and S3
3) S1 and S4

Then use another constraint -using a weight from 95% to 99,99%- Min days between a set of activities: S2 and S3 and S4.

Done. S1 will always be alone. S2, S3 and S4 will be possibly alone, but FET may join two of them if there is no other solution.

Is this the only (or simplest) answer?

Thank you!

Volker Dirr

#2
QuoteI have a 5 hours activity splitted 2+1+1+1.

How can I constraint those subactivities to obtain that never the 2 hours component can be placed near a 1 hour subactivity?

what do you mean with "near"?

If you mean "not at the same day", then you can:

solution a:
add another min 1 day constraint with 100% so s1 and s2.
add another min 1 day constraint with 100% so s1 and s3.
add another min 1 day constraint with 100% so s1 and s4.

or
solution b:
give this activity an activity tag.
add constraint activity tag max 2 hours per day


if you mean "there must be a 'free' day bewteen", then:
solution c:
add another min 2 day constraint with 100% so s1 and s2.
add another min 2 day constraint with 100% so s1 and s3.
add another min 2 day constraint with 100% so s1 and s4.

if you have only a 5 days week, then it also mean s1 can be only monday or friday, so you can also use a constraint preferd time for s1 (that will improve speed).

Liviu Lalescu

#3
QuoteI have a 5 hours activity splitted 2+1+1+1.

How can I constraint those subactivities to obtain that never the 2 hours component can be placed near a 1 hour subactivity?

Consider that I want, if it isn't possible to place all subactivities in different days, that FET puts two 1 hour subactivities joined in a same day.

Do you know a simple constraint to obtain this result?

Thank you!  :)  


A simple solution: add 5 activities: A1, A2, A3, A4, A5, duration 1, and constraint 2 activities grouped, A1, A2. This is not a perfect solution, but it is simple to add and to maintain.

Your solution to add 4 min days is perfect, but difficult to add/maintain.

Oh, yes, there is also Volker's solution with act tag max h daily, but I hate this constraint, because it is not perfect.

mbarsan

Volker, Liviu,
  your suggestions are really nice and simple. Thank's

Liviu, I find that the b Volker's solution is the best in case of several activities to be constrained this way. Don't you think so?

And, please, can you explain which is the difference between a perfect constraint and a not perfect one?

:)  It's a pleasure to read your answers...  


Liviu Lalescu

#5
All constraints are perfectly implemented in FET, with the exception of teacher(s) or students (set) activity tag max hours daily.

From the FAQ:

Question 1/25 September 2009: An observation for constraint teacher(s) or students (set) activity tag max hours daily:

This constraint is implemented correctly and is working good, but it is not perfect, which means that in extreme cases the time needed to generate a timetable might be longer than really necessary. You can give FET a hand in these extreme situations.

Notation: ATS=affected teacher or students set, means teachers or students sets affected by this constraint activity tag max hours daily (the problem does not appear for teachers or students sets which are not affected, which have no constraint activity tag max hours daily for them).

For extreme cases, the timetable generation might be longer or much longer than it should be. These cases refer to situations in which the total duration of the activities with the specified activity tag is high compared to the total number of hours of all activities for the ATS, combined with other conditions you use in the data. If the ratio of duration of activities with this activity tag over the total duration of activities for the ATS is over 0.75 or a normal (reasonable low) value, and you use constraints to control gaps or early for ATS, and the number of hours per day is higher than the possible hours for the ATS, the speed of generation might sometimes be slower or much slower than it should be.

In these cases, you are advised to use constraints teacher(s) or students (set) max hours daily for the ATS (without activity tag), or not available constraints for them in slots which are clearly impossible.

For example, if students S have 20 hours of activities with activity tag AT and another 2 hours of activities without activity tag (they have 22 hours in total, the ratio is 20/22=0.90), and you constrain them to 0 gaps per week and 0 beginnings at second hour and also the number of hours per day is large, say 12. Then adding a constraint students activity tag AT max 4 hours per day - alone - will not be perfect. A better solution will need you to add also a constraint students max 5 hours daily (if possible), to make the late slots not available for the students (it is a way to guide FET to the solution), or find other good ways to compensate the situation.

Conclusion: if, for the ATS, the ratio 'tag duration'/'total duration' is above 0.75 AND you use, for the ATS, contraints for gaps or early AND for the ATS the number of available slots per week is much higher than ATS's working number of hours per week AND if the time to generate a timetable is too long, you may need to address this problem.

Probably, in practice this problem will not appear and you need not to worry. But theoretically it exists.

Edited to add: I updated the description of this problem in the FAQ, for a better understanding.