Assigning multiple small rooms or one large room

[math]

In some of our lectures the number of attending students exceeds the capacity of our largest rooms. By removing the walls between three of our rooms, we can create one huge lecture hall, which then has sufficient capacity. In FET I'm modeling it in the following way: first I create a regular activity which is assigned to the first of these rooms. Then I create two "dummy" activities, which have no students or teachers, but which are assigned to the second and third room. Finally I add a time constraint, that these three activities have to have the same starting day and time.

This is working perfectly fine. Until now.

Now the situation has changed because a new lecture hall has been inaugurated in our building. This new lecture hall has sufficient capacity even for the largest lectures. However I'm not quite sure how to model large lectures in FET now. Huge lectures can no EITHER use the new lecture hall OR the three old lecture rooms (as we did it until now).

Is there a way to define some kind of "virtual room" consisting of these three lecture rooms, then assigning these to two rooms in "room -> activities -> an activity has a set of preferred rooms" to the activity.

[Liviu Lalescu]

Do you mean: "can now EITHER use"?

I think: create two dummy rooms R1' and R2'. Together with R1, R2, and R3, and R which is the large room, it should work, if I am not mistaking, but you might need to switch manually the rooms real<->dummy in the final timetable.

[math]

Hi!

Thanks for your response, but I'm not quite clear if I understood you correctly.

Up to now we had the rooms R100A, R100B and R100C, each having a capacity for 100 students. It is possible to remove the walls between these three rooms, so that the resulting room can be used for lectures for up to 300 students. For planning such a lecture, I added a regular activity A1 having the constraint "acitivity has a preferred room" R100A. Moreover I added two dummy activities A2 and A3. These two dummy activities do not have a teacher or student group specified, but I specified that A2 shall be in R100B and A3 shall be in R100C (again using the constraint "activity has a preferred room"). I also specified that A1, A2 and A3 shall have the same starting day and time ("time -> activities -> a set of activities has the same starting time").

During schedule generation, the large lecture was planned in a slot where all three rooms R100A, R100B and R100C are available.

Now we have the new room R350, having a capacity for 350 students.

Large lectures can now take place in the new R350 as well as in the connected rooms R100A, R100B, R100C. Using the old connected rooms for large lectures is absolutely fine, so we don't want to use R350 only. We are rather very much focusing on having as much flexibily as possible.

But the question is how to model it in FET.

If I'm doing it the old way, I would specify that A1 may take place in R100A or R350, leaving A2 and A3 as dummies for occupying R100B and R100C as above. This would surely work, but it has the disadvantage that R100B and R100C are always blocked for the lecture, even if it takes place in R350. Since we are very short on rooms, this is a real problem, because R100B and R100C could not be used for other activities during that time (since they are blocked for the lecture, even though the lecture only takes place in the new R350).

I would like to model it in a way that EITHER R350 is allocated for the lecture OR R100A, R100B and R100C.

I'm not quite sure what you mean with dummy rooms. Do you mean "virtual" rooms that are not actually existing? Let's name those rooms "dummy room 1" (DR1) and DR2.
Do you suggest that A1 has preferred rooms R100A and R350, A2 has preferred rooms R100B and DR1, and A3 has preferred rooms R100C and DR2?
I don't think that this would work because FET could generate a result that assigns R100A to A1, DR1 to A2 and DR2 to A3. This is no valid assignment since we need all three rooms R100A, R100B and R100C for having sufficient capacity for the lecture.

From my point of view I need a way to assign more than one room to a single activity. This could work the following way:

In "Data -> Space" there could be a third entry "Virtual Rooms" (beside the existing entries "Buildings" and "Rooms").
In that dialog it could be possible to specify "virtual rooms" by specifying a name and selecting one or more actually existing rooms (that have been entered in "data -> space -> rooms").
In my example I would create a virtual room "VR300", selecting R100A, R100B and R100C as rooms that VR300 exists of.
In all other dialogs of FET, virtual rooms could be treated just like actual rooms. For instance in the constraint "activity has a set of preferred rooms" the list of rooms could be a mix of virtual and regular rooms.
The crucial difference is in the schedule generation. Until now there is a direct relationship between activity and room: for each activity there is at most one room that is assigned to it. With virtual rooms this changes in a way that multiple rooms are assigned to an activity (i.e. all rooms that the virtual room consists of).

Having such functionality I would specify for A1 "activity has a set of preferred rooms": VR300 and R350. If FET schedules A1 to R350, only R350 is allocated. If A2 is scheduled to VR300, the rooms R100A, R100B and R100C are allocated. 


But maybe I'm wrong and it does not need any enhancements to FET. Could you tell me again what you mean with virtual rooms?

[Liviu Lalescu]

Hello,

Sorry, I think I was wrong.

Your suggestion is very good, adding a virtual room to represent 3 real rooms.

I think you cannot represent your situation in FET official as it is now.

In the TODO item #114 (in which many users suggest adding more rooms for an activity) I added your suggestion as well: "Also suggested by math, on the forum: https://lalescu.ro/liviu/fet/forum/index.php?topic=4249.0 (the essence is that he proposes virtual rooms. A virtual room consists of more real rooms and an activity may be allocated to a real room or to a virtual room)."     Please let me know if this is correct or you want other wording here.

[Volker Dirr]

As a current workaround i guess you should try to choose the room manualy.

So choose all activities that you used the 3 old rooms and do it like always (with the 2 dummy activity and same starting times constraint).
Use the new large room "normal", so without dummy activities.

The difficult part is choosing manualy. In best case you check if there is one teacher or student many times in a large room. You should place his activitities always in the same large room (so in 3 old rooms OR the single large new room; but not both) to avoid possible conflicts and simplify the data. So it with an other teacher or students that visit large rooms 2nd most times; just into the other room. I am note sure about the other activities. Place them randomly in a room if you can't see a good rule.

[math]

@liviu: thanks a lot for adding it to the TODO. Wording is perfect, however I think that the concept of virtual rooms is more powerful than just adding multiple rooms to an activity (which can be realized with the current version of FET by adding dummy activities).

@volker: thanks for the suggestions. That's my current workaround, but it's quite time consuming.

[Liviu Lalescu]

So, math, do you suggest I should add a new TODO item alone for your topic here? If that is true, could you suggest the text?

[Liviu Lalescu]

math, I thought about it and your idea is excellent, both for the result and for the ease of implementation. Congratulations! No other users suggesting this, nor me or Volker, thought of this, over a long time in which I thought adding more rooms for an activity is very complicated (I refer to virtual rooms, each one containing more real rooms).

I think of adding a check box for each room, "Virtual", and each virtual room must contain at least 2 non-virtual (real) rooms (so that the user will know what virtual rooms mean). Can two virtual rooms contain common real rooms?

It seems that the implementation will work easy this way. Each activity will be placed in a single room (real or virtual) and if an activity is in a virtual room all the contained real rooms will be empty at that moment. Also, if an activity is in a real room, all virtual rooms containing this real room must be empty at that moment (is this correct?)

Please let me know, if I will be able to do this, will you help me with advice and intensive testing?

Other users, please let us know your opinion!

[Volker Dirr]

Each activity will be placed in a single room (real or virtual) and if an activity is in a virtual room all the contained real rooms will be empty at that moment. Also, if an activity is in a real room, all virtual rooms containing this real room must be empty at that moment (is this correct?)

I think it is depeing on the reason why you need several rooms.
The variant looks perfect for data sets similar to maths data set. Also the printed timetables will look fine.

I am a bit thinking about other data sets. For example i also need sometimes 2 or 3 rooms. But only the 1st room is important, the second one can be (nearly) randomly.
In my situation such a new vitual room constraint will be much to strict/difficult. So at my school there is a constraint useful that automaticly add a second (and maybe also third) dummy activity with same starting time constraint. But the printed tables won't look perfect.
hmmm... I think it is not critical, since all the past years i only added a single room and after the timetable was generated i just was always able to choose easily an other 2nd or 3rd room manualy by using TiTiTo.

So i think overall the suggestion is fine.
i am think about a few maybe needed warings. So it should check if the vitual rooms has got the same building as the included real rooms. (Or is there a trick/feature why that might be usefull if they are different?)

[math]

@liviu: Thanks a lot that you also like the concept of virtual rooms.

As I outlined in my post, I would clearly differentiate between real and virtual rooms, so I would NOT add a "virtual room" checkbox, but create a separate dialog for defining virtual rooms only. I'm thinking of something like "Time -> Activities -> A set of activities has the same starting time -> Modify". Here you have a list of all activities on the left and a list of selected activities on the right.

Something similar could be used when entering virtual rooms. On the left hand side there could be a list of all rooms, on the right hand side a list of selected rooms.

I really DON'T like your idea that a virtual room has to encompass at least two real rooms. It the same thing like "Space -> Activities -> An activity has a preferred room / An activity has a set of preferred rooms". Why does a "set" have to consist of two or more items? I would really like to see those two constraints to one.

So I would not force users to specify a minimum of two rooms for a virtual room, because the concept also works with a single real room. As a matter of fact, there is no point in defining a virtual room containing only one room, but that should be something that the user decides. Maybe it's a situation where a user already defined a virtual room that encompasses two real rooms. He defined that virtual room as preferred room for numerous activities. Now he has to remove his second room from his configuration (e.g. because the room has been assigned to a different department). If FET forces the user to specify a minimum of two rooms, the user would have to remove the virtual room, then changing all preferred room configuration for affected activities. Most likely, the user will try to circumvent the limitation, e.g. by changing the availability of the room to "unavailable" for all slots instead removing it.

From the functional perspective it's perfectly ok to specify a virtual room with only one real room.

Actually, I think that it would be even possible to allow virtual rooms to not only encompass real rooms but also other virtual rooms. When generating a new schedule, the algorithm has to follow the list from virtual room to virtual room, until all real rooms have been determined. It is only required to detect cycles.

If you need me for testing, just let me know. 

@volker: I did not mean that adding virtual rooms would make the multiple-rooms-per-activity todo useless. Actually I have the same problem that you described. So that feature would be highly appreciated. I only commented liviu's comment to subsume virtual rooms under this todo. I just think that the virtual rooms feature is not the same than the multiroom-feature.

[Liviu Lalescu]

@math:

1) The denying of a virtual room to have only a real room was only a thought from me so as to not confuse the users. It would have been only a condition on starting the generation, not something hard-coded which is difficult to change afterwards.

2) My head (and heart    ) hurts thinking of virtual rooms containing virtual rooms. Why?

3) (also @Volker) Hmm, Volker's problem and your multiple rooms for an activity problem are so difficult. I was hoping virtual rooms will solve this. I have an idea: a virtual room has say 5 real rooms and needs to occupy say 3 real rooms out of these. Is this OK for every situation? (but I admit this sounds difficult and I am not sure I can do it efficiently).

4) In my imagination, real and virtual rooms are similar, just you need to click something and the options for a virtual room appear. But this is just interface, this is not the problem.

@Volker: I prefer that each real or virtual room has any building. But this is easily modifiable.

[math]

Hi Liviu!

1) I don't think that it will confuse any user if you allow selecting a single real room for a virtual room. But at the bottom line, this is your decision.

2) I did not mean that "virtual room inheritance" should be implemented in the first shot. Maybe you put it to the todo list for some future version of FET.

3) I really don't like your idea, because it taints the concept of a virtual room. A virtual room should just be a collection of rooms. Its prime beauty is the possibility of assigning different room sets to an activity. Clearly it could be used as a substitution for the multiroom-feature, I don't like it. Primarily because it does not scale. Imagine that you have a large number of multiroom activities, then a separate virtual room for each of these activities would be necessary. Don't you think that this might get confusing?

5) I don't have any experience in the building feature of FET. In our university the building is coded in the room number (i.e. by looking at the room number, you directly know which building on which campus is meant). But I have a new idea about a scenario how the virtual room feature might be used. Other departments in our university provide lectures on multiple campuses simultaneously. Here, the lecture is held in a lecture room which is equipped with a video conferencing system. The lecture is then streamed to lecture rooms on other campuses, where other students are attending. This means that a virtual room here consists of rooms in different buildings (on other campuses). I even think that this is a scenario that would benefit from virtual room inheritance. 

[Liviu Lalescu]

1) It is also the opinion of the users which counts, and your arguments are good.

3) A large number of multiple room activities. Each will get a preferred room: virtual room VR having in total say 10 real rooms, and each virtual room needs to occupy say 3 rooms out of these at a certain time slot. Otherwise, how do you suggest creating multiple room-ed activities? (I mean creating the constraints, not the internal generation algorithm, which looks difficult to me now).

[math]

Hi Liviu!

I thought a little bit about the multiroom feature and created two fake screenshots to illustrate my ideas.

1)
The virtual room feature should be a fixed mapping of one virtual room name to a number of real (and virtual) room names. No "3 of 5 rooms" option, just a fixed mapping. I explained my idea of the mapping algorithm in some posting above.

2)
For the multiroom feature the menu of "Space -> activities" is changed. The first and second entry is deleted and replaced with the entry "An activity has sets of preferred rooms"

3)
In the beginning, there are no room preferences for any activity, so the list "constraints" is empty. For adding a constraint, the "add" button has to be pressed, which automatically opens the edit dialog (second fake screenshot).
In my example, there are already some room preferences defined. Therefore, there are constraints for five activities listed in that window.
I think it's a good idea to show additional information than just "Activity 1", "Activity 2", etc. In the current "Constraints Activity Preferred Room" there is a information field on the top right side ("Current Constraint"). Maybe something like this.
For filtering the list of activities some filters can be applied by using the combo boxes, just like it is already possible in other dialogs of FET.

4)
If a new constraint has been created (by clicking on the "add" button) or an existing constraint has been selected and the "modify" button is clicked, the Edit dialog (depicted in OverviewDialog.png) shows up.

5)
In that edit dialog the leftmost list contains the sets of preferred rooms that have been defined for that activity. In the beginning, there are no room preferences defined for that activity, so the list is empty. For creating a new set, the "Add" button has to be pressed.
By clicking the add button, a new set is generated, where the sets are automatically named "set 1", "set 2", "set 3", etc. The newly generated set is automatically selected (i.e. its entry in the list is selected and appears with blue background color).

6)
For the selected set, the middle list shows the preferred rooms, where regular entries are real rooms and italic entries are virtual rooms. If it is not possible to change the font of list entries, the name of the room could be extended with a "(R)" (real room) or "V" (virtual room).
The list on the right side shows all other rooms that are available in the system.
If an entry in the middle list is double clicked or the ">" button is pressed, the room is deleted in the middle list and added to the right list.
If an entry in the right list is double clicked or the "<" button is pressed, the room is deleted from the right list and added to the middle list.

7)
In the present version of FET, each activity can only have one room. This means, that for each activity there can be only just one set of preferred rooms. Hence, if an old configuration file is opened with a future FET version, this Edit dialog would only just show one set in the left list.
So this modification is backward compatible with old FET configuration files.


In your example you asked me how I would configure an activity that needs 3 of 5 rooms. It would work that I first add "set 1", then clicking "room 1", "room 2", ..., "room 5" from the right list, so that these rooms appear in the middle list.
Then I create a second set. And again, I select the rooms from the right list, so that also "set 2" has
five preferred rooms.
And then I repeat this a third time.
At the end, there are three sets defined, each having preferred rooms "room 1", "room 2", ..., "room 5".

9)
Since I never took a look at the schedule algorithm, this point is pure guessing:
At the moment there has to be some code that tries to allocate one room of the set of preferred rooms of an activity. Maybe its a function that gets a reference to the set of preferred rooms as argument.
This function is now executed multiple times, i.e. one time for each defined set.

I'm sure that item 9) is much more complicated, but I think that you have to solve very similar problems if you add a "3 of 5" property to the virtual room feature.

Anyway, it's just an idea. Hope it helps. If you think that implementing your idea of a virtual room feature for realizing the multiroom feature is much easier and less error prone, please go ahead.

[Liviu Lalescu]

Hello, math,

Thank you for your work! It contains another excellent suggestion, Set1..Set3 of choices for an activity which should take place in 3 rooms. This should solve also Volker's problem, when he says the first room must be fixed and the other two do not matter.

However, I need to keep the fact that each FET activity goes into a single room, real or virtual. Otherwise would be a titanic task. And you reminded me that also nearly all the space constraints would change.

So I propose you that each virtual room has n sets of real rooms, and in the allocation the algorithm will choose a single real room from each set. I am not quite sure if this is acceptably difficult and feasible. I need to think, but maybe the final decision will be made practically.

I think I can try for the beginning to make this as a custom version for you and Volker and, after many tests, this will find its way in the official FET if successful. This is because if I add such a feature in FET and it will not work, it will be a disaster both for impossible files and for the fact that if I remove this feature afterwards the users will lose virtual rooms data and space constraints.

Please let me know if this is acceptable for you.