 Welcome to another OptoPlanet example. This time we'll be looking at the meeting scheduling example. So in this example, we have to assign meetings to a room and to a time, a starting time. So for example, we have this meeting about engaging sustainable user experience in the new economy. This green meeting, right? And that meeting we've decided it will be in room 1 and it will start at 8 o'clock. At the same time, we have another meeting about cross-selling, compelling multitasking in action, as you can see here, and that will be held in room 4. Now, the interesting thing about this example is that not all meetings have the same duration. So for example, this particular meeting lasts one hour and actually two hours, as you can see, right? From 8 o'clock until 10 o'clock. But other meetings like this brown one, it is only 15 minutes. Or for example, this yellow one is actually 45 minutes, right? So they are in a different, they all take a different duration. You can see some are actually quite long. They go up to four hours, some of the meetings, while others are much less. Now, so this is a little bit different from the other examples in OptoPlanet because it uses something called the time grain pattern to deal with this. What we basically do is we split the time up into a granularity of 15 minutes. So we have 8 o'clock, 8.15, 8.30. And the meeting can start at any of those grains. So it can start at 8 o'clock at 8.15. Because I will allow a meeting to start at, let's say, 8.012. Then that's not really interesting because humans cannot deal with such a fine accuracy. We can only start meetings at a accuracy of 15 minutes in this case. Maybe for your use case, of course, that might be every 5 minutes. Or if you're dealing actually with machines, you might actually use a much smaller granularity than even minutes. But in this particular use case, 15 minutes is the ideal granularity. So in this case, we do have a number of constraints, of course. Now, the first constraint is quite obvious. You can only hold one meeting in one room at the same time. So you see, for example, that while one degree meeting is held in this room, there's no other meeting being held at the same time. So that means that another meeting cannot just be in the same room at the same time starting at the same time. It actually should not overlap at any point during the same time. So we cannot start a meeting, let's say, this orange meeting. We cannot start it at 8.30 in room 1 because then it will partially overlap with the green meeting. So that's the first thing, room conflicts. Now, the second rule is that we don't want to go in overtime, of course. We have a certain time window, which is a number of days. We're now scheduling up to the 5th of January, but we cannot actually go use more time than that. That's quite obvious. And the next thing is, of course, attendance, right? So we have a number of persons. Let's take a look at the persons here, number of persons. You can see them on the left here, which are want to go to some of these meetings. Now, a person doesn't want to go to all the meetings. Each person wants to go to a number of meetings he considered as required. And he or she also has a number of preferred meetings often. So for example, you can see that this first person here wants to go to the green meeting, right? So that's required, and he can do that. He can go from 8 till 10. There's no problem. He has no other commitments at that time. We can see that this other person, Andre and Lukas, also want to go to that meeting. Now, you can see for Andre, it's a preferred meeting, but he can go. So that's fine. But for Lukas, it's a required meeting. So he can go. So that's not just fine. That's actually required, right? So that is a difference between hard and soft constraints, right? Actually, hard and medium constraints in this case. So all the people who are required to go to a meeting, if they have to attend two required meetings at the same time, then we break a hard constraint. Now, you can see that's not the case because we have zero hard constraints broken. And also, if you actually look through this, you will see that at no time, one person has to go to two meetings that he is required to go to at the same time. Also, of course, we want to make sure that people can go to their preferred meetings too. It's a little bit more difficult because it's actually not possible to go to all preferred meetings in this data set, I believe. But most of the case, this is true. So for example, if you look at that first person, we can see if you look at the required and preferred one, you can see that you can actually visit most meetings up to this particular meeting, actually, where he has to go to two meetings at the same time. Net has to go, wants to go. It's a preferred two preferred meetings. So we lose actually lose some points for that. You can see that we actually have this case 18 times. So in 18 times, we will somebody will have to drop out of their preferred meetings of one of their two preferred meetings, right? Now, so that's the attendance constraint. Then of course, we have something called room capacity. All of the rooms have a certain capacity. And we need to make sure there's enough room for all the people attending that particular meeting, which is scheduled in that room. So we take that into account too. Of course, that's of course hard constraint again, the room capacity. And beyond that, we have one other constraint, which is a soft constraint, which has we want to do all the meetings as soon as possible. So we want to move all the meetings to the front of the schedule. And this is just a number which counts a number of grains that people are beating start later than January 8 o'clock. So this will never be zero, of course, but it does push all the meetings to the front of the schedule, which is nice to have. So when new meetings that we didn't account for actually would be scheduled, it would be added to the end. So let me just show how this works when we start from an empty thing. So we have an empty schedule, no January, no rooms filled in. And we have our meetings over here. So as you can see, cross-selling, privatize, transform, engage, downsize, synergies and all that kind of stuff. Do you want to schedule these meetings? So let's start solving this. Now, if you can see that it's here, we can see the score that we found. It's actually not showing the results in the screen. Why? Because constantly refreshing the screen is actually slows down the application, actually hangs the application. So I've not enabled this here, as you can see in the bottom right. But I'll give it a little bit of time. Now we're getting quite a good schedule after a few seconds. So let's stop this and you can see this is the schedule. And as you can see in this case, there are no hard constraints broken because everybody can go to all the meetings that they are required to go to. And here you can see sometimes they do have to go to two meetings at the same time. They want to go to this is a preferred meeting again. So again, we have some medium constraints broken. If you give it some more time, then we can actually lower this to 18Fs as we've seen. But it works and it's a good, it's a feasible schedule and it's much better than one which would actually figure out by hand. So a little bit more about the time grain pattern before this session. So there are different ways, different design patterns on how to deal with assigning to time in Optoplanar. And the best design, so the interesting design patterns we've documented those. And so what we see in many cases is where the duration of something that needs to be scheduled is fixed. And then you can use time slot pattern which we use in the course scheduling example, right? So for example, the core chemistry lesson takes one hour, but the math all the lessons takes one hour. So we just schedule them to the time slot, right? Well, in this particular case, we're using the time grain pattern where we say, okay, we use a granularity of 15 minutes and we assign the starting time. So the sales meeting starts at zero. The architects meeting started at time grain one, which 15 minutes later if you see on the bottom on the top, right? So that's a different way of designing the domain model. And this allows you to have a much lower, you know, have meetings in different durations. And there's actually a third pattern too, which is a chain through time pattern, which is used in vehicle routing or usually in when tasks need to be assigned. And the nice thing about those is that it works very well when there are no gaps or when the gaps are very deterministic. Like if you work two hours, you want a 15 minutes break. The interesting thing about this is that we're not going to use some sort of granularity. We're just going to start a task when the previous one is done. So when, in this case, the taxes of the Netherlands have been calculated, that's Beth will start her next task doing the Belgium taxes, for example, right? Now, it depends, of course, on your use case. What's the best one to use if you're dealing with time? But it is interesting to know that you have these options available and each of them has their advantages. They're, you know, use the right tool for the right job, use the right design pattern for the right use case. And each of one has, of course, some limitations in design. Now, you probably think, why not just simply say, okay, use a very small time grain like a time grain of one second or even one millisecond or one nanosecond? Now, you can do that and support that, of course. But the problem with that is that you, if you don't need one minute or one millisecond or one nanosecond granularity, you actually need a 15 minute case, for example, when you're scheduling humans, this is usually the case. Then you're going to increase the search space a lot and it's going to be much, much harder to find something. You will need far more CPU power to do that. So, actually, you apply and you will get results that you don't want because there is no point in starting a meeting at 15 nanoseconds after five minutes after nine o'clock, right? Because humans don't show up on a nanosecond accuracy, of course, right? Okay. So, thanks for listening to this example and I hope you enjoyed it. Bye.