Roosteropties (Opties | Roosteren)

1230 views 1 28 oktober 2017 Updated on 19 August 2025 petervanhirtum[print-me printstyle="pom-small-grey" tag="span" target=".title-content-print"]

Roosteropties (Opties | Roosteren)

In deze sectie worden de opties besproken die bepalen wat er wel en niet in aanmerking genomen wordt bij het uitvoeren van de MBE. Het gaat hierbij om volgende aspecten:

  • Extra opdrachten die niet in een expliciete selectie (via uitgebreid zoeken) opgenomen werden, maar toch meegenomen worden naar de MBE.
  • Leerkrachtwensen al dan niet meenemen.
  • Optimalisatieopdrachten al dan niet meenemen.
  • Op algemeen niveau bepaalde beperkingstypes wel of niet meenemen.
  • Op algemeen niveau bepaalde resourcetypes wel of niet meenemen.
  • Details over hoe de MBE moet omgaan met Bloklinks en ZR-links.

De opties worden hier getoond zoals ze standaard gezet worden (“Standaardopties”). Merk op dat men de standaardopties kan terugzetten door op de knop “Standaardopties” te drukken en dan te kiezen voor ofwel “Engine en Roosteren” ofwel voor “Manueel roosteren”. Andere optietabbladen worden hierdoor niet geraakt.

De opties in dit tabblad:

  • zijn enkel bedoeld voor het roosteren uitgevoerd door de MBE
  • worden gerespecteerd bij “Valideer Rooster met opties”
  • hebben géén invloed op manuele roosteractiviteiten (op geen enkele manier)
  • hebben géén invloed op “Valideer Rooster”
  • hebben géén invloed op “Conflicten” en conflicten oplossen

Inhoud

Bijkomende opdrachtselectie (Voor Plan Selectie en Analyseer Opdrachten)

Deze opties hebben enkel nut bij de acties “Plan Selectie” of “Analyseer Opdrachten”. Merk op dat “Analyseer Opdrachten” in een andere sectie behandeld wordt. Via deze opties worden extra opdrachten meegenomen in de planning.

Elk van deze opties heeft een bijkomende optie “Toon”. Het enige wat “Toon” doet, is de opdrachten ook laten zien in het opdrachtentabblad wanneer men “uitgebreid zoeken” gebruikt. De “Toon” optie kan los gebruikt worden van het feit of de overeenkomstige opdrachten naar de MBE gestuurd worden of niet.

Opties:

  • Vastgezette opdrachten meeroosteren: deze optie selecteert de opdrachten waarvoor “Vast” aangevinkt werd in het opdrachtentabblad. Omdat deze vastgezette opdrachten geen keuze meer zijn, is het verstandig om deze altijd mee te nemen wanneer men een deelverzameling van de opdrachten wenst te plannen.
  • Opdrachten met een vast uur en zonder keuzeresources meeroosteren: deze optie selecteert opdrachten die maar op één uur geplaatst kunnen worden en die ook géén keuzeresources hebben. Er is dus geen keuze in de tijd. Deze uurbeperking kan er gekomen zijn door een expliciete uurlijst en/of door de beperkingen opgelegd door de elementen die deel uitmaken van de opdracht.
  • Opdrachten met een vast uur en met keuzeresources meeroosteren: deze optie selecteert opdrachten die maar op één uur geplaatst kunnen worden, maar die wél keuzeresources hebben. Er is dus geen keuze in de tijd, wel in resources. Deze uurbeperking kan er gekomen zijn door een expliciete uurlijst en/of door de beperkingen opgelegd door de elementen die deel uitmaken van de opdracht.
  • Opdrachten gelinkt via ZR-Link meeroosteren: deze optie selecteert opdrachten die via een ZR-Link gelinkt zijn aan opdrachten die expliciet in de selectie van de gebruiker zitten. Wanneer bijvoorbeeld 2 of meer opdrachten via een ZR-Link gekoppeld zijn, maar via uitgebreid zoeken er maar één geselecteerd werd, worden via deze optie de andere opdrachten die in de ZR-Link zitten, er toch bij betrokken.
  • Opdrachten gelinkt via ZKL-Link meeroosteren: deze optie selecteert opdrachten die via een ZKL-Link gelinkt zijn aan opdrachten die expliciet in de selectie van de gebruiker zitten. Wanneer bijvoorbeeld 2 of meer opdrachten via een ZKL-Link gekoppeld zijn, maar via uitgebreid zoeken er maar één geselecteerd werd, worden via deze optie de andere opdrachten die in de ZKL-Link zitten, er toch bij betrokken.
  • Opdrachten gelinkt via ZKV-Link meeroosteren: deze optie selecteert opdrachten die via een ZKV-Link gelinkt zijn aan opdrachten die expliciet in de selectie van de gebruiker zitten. Wanneer bijvoorbeeld 2 of meer opdrachten via een ZKV-Link gekoppeld zijn, maar via uitgebreid zoeken er maar één geselecteerd werd, worden via deze optie de andere opdrachten die in de ZKV-Link zitten, er toch bij betrokken.
  • Opdrachten gelinkt via Bloklink meeroosteren: deze optie selecteert opdrachten die via een Bloklink gelinkt zijn aan opdrachten die expliciet in de selectie van de gebruiker zitten. Wanneer bijvoorbeeld 2 opdrachten via een Bloklink gekoppeld zijn, maar via uitgebreid zoeken er maar één geselecteerd werd, wordt via deze optie de andere opdracht die in de Bloklink zit, er toch bij betrokken.
  • Opdrachten gelinkt via waardespreidingen meeroosteren: opdrachten kunnen onderhevig zijn aan één of meerdere waardespreidingen. Via deze optie kan men, vertrekkende van de door de gebruiker expliciet geselecteerde opdrachten, extra opdrachten selecteren die gekoppeld zijn aan de geselecteerde opdrachten via waardespreidingen.
  • Opdrachten gelinkt via volgordespreidingen meeroosteren: opdrachten kunnen onderhevig zijn aan één of meerdere volgordespreidingen. Via deze optie kan men, vertrekkende van de door de gebruiker expliciet geselecteerde opdrachten, extra opdrachten selecteren die gekoppeld zijn aan de geselecteerde opdrachten via volgordespreidingen.

Opmerking over de laatste 4 “link” opties: de links vertrekken steeds van de expliciet geselecteerde opdrachten. Een opdracht die niet expliciet geselecteerd werd door de gebruiker (enkel via uitgebreid zoeken dus) zal nooit het vertrekpunt zijn voor het bijkomend selecteren van opdrachten via deze “link” opties. Ook de opdrachten die er via de eerste 3 opties extra bijgekomen zijn, zullen geen vertrekpunt zijn voor het bijkomend selecteren van opdrachten via de 4 “link” opties.

Opmerking over het ontbreken van links via minimumspreiding: een minimumspreiding heeft steeds betrekking op één specifieke resource. Als die resource in de selectie zit, dan zitten meteen alle opdrachten van die resource in de selectie en dat zijn dan meteen ook de enige opdrachten die voor die resource in de minimumspreiding kunnen participeren. Vandaar dat die optie “Opdrachten gelinkt via minimumspreiding meeroosteren” niet bestaat.

Bijkomende leerkrachtspecifieke opdrachtselectie

Enkel via deze opties kan men wensopdrachten en optimalisatieopdrachten (beide enkel van toepassing op leerkrachten) selecteren om mee met de andere geselecteerde opdrachten naar de MBE te sturen. Deze opties zijn algemeen toepasbaar en zijn dus van toepassing voor zowel “Plan”, “Plan Selectie” als voor “Analyseer Opdrachten”.

De uitgegrijsde opties hebben te maken met optimalisatieopdrachten. Deze opties worden pas toepasbaar indien men in “Opties | Andere | Geavanceerd” die optie “Optimalisatie” heeft aangevinkt. Door deze optie aan te vinken komt het tabblad “Opdrachten | Optimalisatie” tevoorschijn en kan de gebruiker optimalisatieopdrachten aanmaken. Van zodra men actieve optimalisatieopdrachten heeft, zijn de, nu uitgegrijsde, optimalisatieopties van belang. Merk op dat “Optimalisatie” van leerkrachtroosters in een andere sectie behandeld wordt. Het opnemen van optimalisatieopdrachten vereist bepaalde technieken die daar uitgelegd worden.

Opties:

  • Wensen meeroosteren: enkel via deze optie kan men leerkrachtwensen, die gedefinieerd zijn in “Opdrachten | Wensen”, mee opnemen in de set van opdrachten die naar de MBE gestuurd worden. Indien men deze optie uitvinkt, zal tijdens de planning geen rekening gehouden worden met de wensen. Dit kan nuttig zijn om uit te zoeken of de wensen problemen geven in de roosterbaarheid van de normale opdrachten.
  • Wensen per geselecteerde leerkracht (Analyse): enkel voor Analysedoeleinden (“Analyseer opdrachten”) kan men ervoor kiezen om enkel de wensen mee te nemen van de expliciet geselecteerde leerkrachten en dit per combinatie die naar de MBE gestuurd wordt om de analyse te doen. Op deze manier vermijdt men dan de wensen van niet geselecteerde leerkrachten invloed zouden hebben op de analyse van een specifieke combinatie. Deze optie kan men enkel aanvinken indien “Wensen meeroosteren” aangevinkt is. Laat men de optie uitgevinkt dan worden ook bij de analyse steeds alle wensen van alle leerkrachten meegenomen. De optie heeft geen impact op “Plan” of “Plan selectie”.
  • Optimalisatieopdrachten meeroosteren: enkel via deze optie kan men de optimalisatieopdrachten voor leerkrachten opnemen in de set van opdrachten die naar de MBE gestuurd worden. Optimalisatieopdrachten die door de gebruiker voorzien worden, kan men vinden in het tabblad “Opdrachten | Optimalisatie”. Dit tabblad is enkel zichtbaar indien de optie “Opties | Andere | Optimalisatie” aangevinkt is. Het is ook enkel indien deze optie aangevinkt is dat de optie “Optimalisatieopdrachten meeroosteren” beschikbaar wordt. Via technieken, waarop we hier niet verder ingaan, wordt eerst een oplossing gezocht voor het rooster met wensen en pas daarna wordt het rooster verder geoptimaliseerd via stappen die deze optie gebruikt.
  • Negeer niet-geplaatste normale opdrachten: indien men technieken gebruikt om leerkrachtroosters te optimaliseren, via o.a. de optie “Optimalisatieopdrachten meeroosteren”, dan kan de optie “Negeer niet-geplaatste normale opdrachten” nuttig zijn. Men stuurt dan enkel de (geselecteerde) normale lesopdrachten en wensen naar de MBE die al geplaatst zijn en additioneel de optimalisatieopdrachten om de leerkrachtroosters te verbeteren. De normale lesopdrachten en wensen die eventueel wel geselecteerd zijn maar niet geplaatst, worden via deze optie genegeerd en dus niet mee naar de MBE gestuurd. Dit kan nuttig zijn indien men een deel van het rooster wenst te plannen en voor dit deel dan ook de optimalisatie van de leerkrachtroosters wenst uit te voeren. Dit kan een nuttige test zijn. Merk op dat deze optie ook enkel actief gemaakt kan worden indien “Opties | Andere | Optimalisatie” aangevinkt is en dat ze ook zonder “Optimalisatieopdrachten meeroosteren” gebruikt kan worden. Mondriaan kan nl. ook zonder optimalisatieopdrachten, gedefinieerd door de gebruiker, leerkrachtroosters optimaliseren. Ook dan kan het nuttig zijn om de niet geplaatste opdrachten niet mee te nemen naar de MBE.

Tip: De opties “Optimalisatieopdrachten meeroosteren” en “Negeer niet-geplaatste normale opdrachten” zijn pas beschikbaar (niet meer grijs) wanneer de optie “Opties | Andere | Optimalisatie” aangevinkt is. Het is ook via “Opties | Andere | Optimalisatie” dat het tabblad “Opdrachten | Optimalisatie” beschikbaar wordt.

Meer informatie over optimaliseren van leerkrachtroosters kan men vinden op pagina “Optimaliseren van Leerkrachtroosters“.

Algemene beperkingen

Ook deze opties zijn altijd van toepassing op “Plan”, “Plan Selectie” en “Analyseer Opdrachten”. Het gaat hier om het aan- of afzetten van algemene beperkingen. Normaal staan deze opties aangevinkt, maar om problemen te analyseren kan het nuttig zijn beperkingen per type in hun algemeenheid uit te schakelen.

Merk op dat deze opties NIET van toepassing zijn op manuele roosteractiviteiten.

Opties:

  • Locaties meeroosteren: locaties zijn een optionele eigenschap van lokalen. Locaties worden meestal geassocieerd met gebouwen bv. voor gebouwen die te ver uit elkaar liggen om zich tussen elke 2 lesuren van het ene naar het andere gebouw te verplaatsen. Locaties kunnen gebruikt worden in waardespreidingen om bepaalde verplaatsingen, op bepaalde momenten, niet toe te laten. Door de optie “Locaties meeroosteren” uit te vinken, zullen de spreidingsregels die gebruik maken van locaties niet langer effect hebben. Het uitvinken heeft dus als gevolg dat de locaties niet meer actief zijn en dat er geen rekening meer mee gehouden wordt.
  • Vensters meeroosteren: dit gaat over de vaste vensters in opdrachten. Men kan deze vaste vensters uitschakelen tijdens het roosteren. Het gevolg is dat er geen enkele opdracht nog rekening zal houden met deze vaste vensters en er dus ook niet door gehinderd kan worden. Merk op dat deze optie géén effect heeft op technische vensters. Technische vensters zijn vensters die Mondriaan zelf aanmaakt achter de schermen om bepaalde constructies op te zetten in de MBE (Zie verder bij ZR-Link en Bloklink constructies).
  • Keuzevensters meeroosteren: opdrachten kunnen ook keuzevensters gebruiken waarbij ze een venster uit een groep van mogelijke vensters kiezen. Door deze optie uit te vinken gaat men de opdrachten roosteren zonder keuzevensters. Dit heeft enkel effect op de keuzegroep in de opdracht, niet op de vensters zelf die in de groep zitten.
  • Opdrachtspreidingen meeroosteren: de opdrachtspreidingen, die in het opdrachten tabblad lokaal bij de opdracht gedefinieerd worden, kunnen via deze optie algemeen uitgeschakeld worden. Er wordt geen enkele opdrachtspreiding meer afgedwongen tijdens het roosteren. Het effect is vergelijkbaar met het schrappen van elke opdrachtspreiding in het opdrachten tabblad.
  • Waardespreidingen meeroosteren: Waardespreidingen kunnen via deze optie algemeen uitgeschakeld worden. Zet men ze uit, dan wordt tijdens het roosteren geen rekening gehouden met deze spreidingen. Het effect is vergelijkbaar met het inactief maken van elke waardespreiding.
  • Volgordespreidingen meeroosteren: volgordespreidingen kunnen via deze optie algemeen uitgeschakeld worden. Zet men ze uit, dan wordt tijdens het roosteren geen rekening gehouden met deze spreidingen. Het effect is vergelijkbaar met het inactief maken van elke volgordespreiding. Merk op dat deze optie géén effect heeft op technische volgordespreidingen. Technische volgordespreidingen zijn spreidingen die Mondriaan zelf aanmaakt achter de schermen om bepaalde constructies op te zetten in de MBE (Zie verder bij ZR-Link en Bloklink constructies).
  • Minimumspreidingen meeroosteren: minimumspreidingen kunnen via deze optie algemeen uitgeschakeld worden. Zet men ze uit, dan wordt tijdens het roosteren geen rekening gehouden met deze spreidingen. Het effect is vergelijkbaar met het inactief maken van elke minimumspreiding.

Opdrachtelementen al dan niet mee te nemen tijdens het roosteren

Ook deze opties zijn altijd van toepassing op “Plan”, “Plan Selectie” en “Analyseer Opdrachten”. Het gaat hier om het aan- of uitschakelen van types resources. Normaal staan deze opties aangevinkt, maar om problemen te analyseren kan het nuttig zijn resources per type in hun algemeenheid uit te schakelen.

Merk op dat deze opties NIET van toepassing zijn op manuele roosteractiviteiten.

Opties:

  • Klassen meeroosteren: dit gaat over vaste klassen in opdrachten. Men kan deze vaste klassen uitschakelen tijdens het roosteren. Het gevolg is dat geen enkele opdracht nog rekening zal houden met deze vaste klassen en er dus ook niet door gehinderd kan worden.
  • Keuzeklassen meeroosteren: opdrachten kunnen ook keuzeklassen gebruiken waarbij ze een klas uit een groep van mogelijke klassen kiezen. Door deze optie uit te vinken gaat men de opdrachten roosteren zonder keuzeklassen. Dit heeft enkel effect op de keuzegroep in de opdracht, niet op de klassen zelf die in de groep zitten.
  • Leerkrachten meeroosteren: dit gaat over vaste leerkrachten in opdrachten. Men kan deze vaste leerkrachten uitschakelen tijdens het roosteren. Het gevolg is dat geen enkele opdracht nog rekening zal houden met deze vaste leerkrachten en er dus ook niet door gehinderd kan worden.
  • Keuzeleerkrachten meeroosteren: Opdrachten kunnen ook keuzeleerkrachten gebruiken waarbij ze een leerkracht uit een groep van mogelijke leerkrachten kiezen. Door deze optie uit te vinken gaat men de opdrachten roosteren zonder keuzeleerkrachten. Dit heeft enkel effect op de keuzegroep in de opdracht, niet op de leerkrachten zelf die in de groep zitten.
  • Lokalen meeroosteren: dit gaat over vaste lokalen in opdrachten. Men kan deze vaste lokalen uitschakelen tijdens het roosteren. Het gevolg is dat geen enkele opdracht nog rekening zal houden met deze vaste lokalen en er dus ook niet door gehinderd kan worden.
  • Keuzelokalen meeroosteren: opdrachten kunnen ook keuzelokalen gebruiken waarbij ze een lokaal uit een groep van mogelijke lokalen kiezen. Door deze optie uit te vinken gaat men de opdrachten roosteren zonder keuzelokalen. Dit heeft enkel effect op de keuzegroep in de opdracht, niet op de lokalen zelf die in de groep zitten.
  • Varia meeroosteren: dit gaat over vaste varia in opdrachten. Men kan deze vaste varia uitschakelen tijdens het roosteren. Het gevolg is dat geen enkele opdracht nog rekening zal houden met deze vaste varia en er dus ook niet door gehinderd kan worden.
  • Keuzevaria meeroosteren: opdrachten kunnen ook keuzevaria gebruiken waarbij ze een varia uit een groep van mogelijke varia kiezen. Door deze optie uit te vinken gaat men de opdrachten roosteren zonder keuzevaria. Dit heeft enkel effect op de keuzegroep in de opdracht, niet op de varia zelf die in de groep zitten.
  • Essentiële lokalen meeroosteren: In het Opdrachtentabblad hebben we een vlagje “Essentiële lokalen”. Voor opdrachten waarvoor dit aangevinkt is willen we zeggen dat ze lokalen hebben die best steeds mee geroosterd worden, ook al hebben we lokalen en keuzelokalen als roosteroptie uitgeschakeld. De optie “Essentiële lokalen meeroosteren” kan men dan bijvoorbeeld aanvinken terwijl “Lokalen meeroosteren” en “Keuzelokelen meeroosteren” uitegvinkt staan. Op die manier nemen voor de geselecteerde opdrachten toch de lokalen mee idien ze essentieel zijn. Dit wordt ook vooral gebruikt bij het analyseren van roosterproblemen.

Wat vaak gebruikt wordt in de analyse van problemen is het in- en uitschakelen van vaste en/of keuzelokalen. Door bijvoorbeeld de keuzelokalen uit te schakelen kan men bekijken of de (selectie) opdrachten roosterbaar zijn met enkel de vaste lokalen. Ook enkel de keuzelokalen roosteren kan inzicht brengen.

Merk op dat het uitschakelen van vaste resources en/of keuzeresources (waaronder ook vensters) een rooster oplevert dat waarschijnlijk niet voldoet aan de opgelegde beperkingen. Doet men “Valideer Rooster” dan zal men onmiddellijk zien waar de problemen zitten. Men zal conflicten ook snel zien opduiken in de visualizers. Resources gaan dubbel gebruikt zijn etc. Deze opties dienen dus enkel uitgevinkt te worden om roosterproblemen op te sporen.

Extra | Update RandEnSpringUurlijsten (op basis van vaste uren) bij plannen

Deze optie heeft betrekking op opdrachten waarvan het vlagje “Rand Spring UL” aangevinkt is. Dit wordt bijvoorbeeld gebruikt om opdrachten bij te roosteren voor permanenties (ook vervangopdrachten genoemd) nadat het rooster didactisch klaar en geoptimaliseerd was. Een vervangopdracht (typisch met één leerkracht en zonder klas) heeft, net als alle andere opdrachten, een startuurlijst waarop de vervanguren kunnen geplaatst worden. Deze uurlijst kan impliciet zijn (en dus afgeleid van de statische tijdsbeperkingen van de resources) of hij kan expliciet zijn doordat de gebruiker de mogelijkheden verder beperkt heeft door een startuurlijst toe te voegen. Typisch voor vervangopdrachten is dat men deze graag plaatst op de springuren die een leerkracht waarschijnlijk toch heeft in zijn rooster of op de randuren waar hij ook geen reguliere lesopdrachten heeft. Als er bijvoorbeeld van een leerkracht verwacht wordt dat hij 2 uur permanentie per week doet, dan leggen we die uren best op springuren, randuren (aansluitend op andere lesopdrachten), maar niet op vrije dagen of vrije halve dagen.

Er bestaat een actie in het menu “Tools | Update RandEnSpringUurlijsten” die de startuurlijsten van opdrachten (enkel die met vlagje “Rand Spring UL” aangevinkt) aanpast (lees: overschrijft) zodat enkel springuren en randuren toegelaten zijn. Deze update is steeds op basis van het op dat moment geplaatste rooster en houdt rekening met de roosters van de vaste leerkracht(en) in de opdracht. Na deze actie zal de uurlijst enkel uren bevatten waarop géén les of wens staat voor de leerkracht(en) in kwestie. Indien men het rooster wijzigt worden deze uurlijsten in principe waardeloos en moet men ze weer aanpassen. Het is dus pas nuttig om deze uurlijsten te gebruiken wanneer de opdrachten, waarrond de uurlijsturen vallen, niet meer bewegen tijdens het roosteren van de vervangopdrachten.

Een andere handige manier om de uurlijsten van dergelijke opdrachten aan te passen is via de optie “Extra | Update RandEnSpringUurlijsten (op basis van vaste uren) bij plannen“.

Als men deze optie aanvinkt, zal Mondriaan, telkens wanneer de MBE gestart wordt, voor de geselecteerde vervangopdrachten de uurlijsten bepalen op basis van de “vaste” opdrachten. Voor elke opdracht gebeurt dat dan als volgt:

  • Het vertrekpunt is de startuurlijst die in het opdrachten tabblad staat. Kan impliciet of expliciet zijn.
  • Mondriaan bepaalt de spring- en randuren op basis van enkel de “Vaste” opdrachten die in het rooster van de vaste leerkracht(en) staan.
  • Mondriaan kijkt niet naar de andere opdrachten (die dus niet vast staan) voor het bepalen van de spring- en randuren. Mondriaan negeert deze opdrachten, doet alsof ze er niet staan voor de bepaling van de spring- en randuren.
  • Mondriaan bepaalt dan een nieuwe startuurlijst op basis van de gevonden spring- en randuren, maar houdt enkel die over die ook toegelaten worden door de startuurlijst die in het opdrachten tabblad staat. Stond er geen enkel uur in de startuurlijst dan houdt Mondriaan enkel rekening met de beperkingen van de resources (is de impliciete startuurlijst). Van zodra er minstens één startuur stond, zal Mondriaan de bestaande uurlijst enkel verder beperken tot de rand- en springuren.

Deze nieuwe, beperktere uurlijst wordt aan de MBE doorgegeven voor de planning van de vervangopdracht, maar de uurlijst in het opdrachten tabblad zelf wordt hierdoor niet aangepast, die blijft wat hij was.

Nog enkele weetjes over de dynamisch aangemaakte uurlijst en de vervangopdrachten:

  • Doordat de effectieve starturen in de uurlijst enkel kunnen bestaan rond “Vaste” opdrachten, kunnen vervangopdrachten in dit geval enkel geroosterd worden rond vaste opdrachten. Heeft een leerkracht géén vaste opdrachten, dan kunnen er in dit geval dus ook geen vervangopdrachten geplaatst worden.
  • Indien men een leerkracht heeft met zowel vaste als niet-vaste opdrachten, dan kan het gebeuren dat een vervangopdracht een gewone lesopdracht doet verschuiven. Mondriaan houdt immers geen rekening met de niet-vaste opdrachten om de spring- en randuren te bepalen.
  • De meest logische manier om deze optie te gebruiken is om alle lesopdrachten (en wensen) eerst vast te zetten en pas dan de vervangopdrachten te plannen. Op die manier kunnen vervangopdrachten nooit lesopdrachten of wensen van plaats doen veranderen.
  • Als deze optie NIET aangevinkt is: dan worden de vervangopdrachten als gewone opdrachten geplaatst rekening houdend met de uurlijst voorhanden in het opdrachten tabblad.

Verder informatie over vervangopdrachten kan men vinden op volgende pagina’s:

ZR-Link constructie

Dit is een eerder technische optie die bepaalt op welke manier de “ZR-Links” vertaald moeten worden naar de MBE. Deze optie heeft dus geen enkel effect op de beperking van de ZR-Link zelf, enkel op de manier waarop ze technisch behandeld wordt door de MBE. Toch laten we de optie vrij in te stellen omdat de keuze in sommige gevallen toch een significant effect kan hebben op de doorlooptijd van het roosteren.

Opties:

  • Via vensters: via deze keuze worden opdrachten die in een ZR-Link zitten als aparte opdrachten naar de MBE gestuurd, maar elk van deze opdrachten wordt gekoppeld aan een eigen technisch venster en al deze technische vensters worden op hetzelfde roosterpunt gezet (als gekoppelde vensters). Doordat die technische vensters steeds samen blijven, zullen ook de opdrachten in deze vensters op hetzelfde roosterpunt terechtkomen. Het voordeel van deze optie is dat elke opdracht apart geplaatst wordt door de MBE en dat het aantal keuzes die gemaakt moeten worden per roosterpunt bepaald wordt door de individuele opdracht. Als opdracht A uit 10 lokalen kan kiezen en opdracht B uit 20 dan moet voor één roosterpunt maximum 10 + 20 = 30 mogelijkheden bekeken worden. Het nadeel is dat de opdrachten elkaar, via de vensters, moeten vinden in het rooster en dat kost ook tijd.
  • Samensmelten indien niet teveel of-takken: via samensmelten worden de opdrachten die in een ZR-Link zitten, samengevoegd tot één technische opdracht. Het voordeel hiervan is dat de opdrachten elkaar niet moeten “vinden” in het rooster maar als één blok geplaatst worden. Het nadeel is echter dat het aantal keuzemogelijkheden per roosterpunt snel kan oplopen. Als bijvoorbeeld opdracht A kan kiezen uit 10 lokalen en B uit 20 lokalen dan moet de gecombineerde opdracht 10 x 20 = 200 mogelijkheden bekijken. Deze optie is dus enkel mogelijk indien de gecombineerde opdracht niet meer dan 256 keuzes moet bekijken. Indien het er meer zouden zijn, dan wordt automatisch overgegaan tot de oplossing met technische vensters (de eerste optie).

De standaardoptie is de tweede. Indien het aantal keuzes beperkt is (<256) dan wordt voor samensmelten gekozen, anders voor de “technische vensters” oplossing. Indien men de eerste optie kiest, dan wordt er altijd met technische vensters gewerkt.

Merk op dat de eerste optie (“via vensters”) enkel mogelijk is indien er totaal géén overlap is tussen de vaste resources van de participerende opdrachten. Van zodra er minstens 2 opdrachten minstens één vaste resource delen, zal er voor deze ZR-Link steeds overgegaan worden tot “samensmelten”.

Een andere beperking die een oplossing met vensters onmogelijk maakt, zijn opdrachten waarbij meerdere blokken geplaatst moeten worden en waarbij die opdrachten of-takken hebben waarbij gevraagd wordt om niet te ontdubbelen (“Ontdubbelen” uitgevinkt). Ook in dit geval wordt er weer overgestapt naar een oplossing via samensmelten.

Merk op dat de term “technisch venster” gewoon betekent dat Mondriaan achter de schermen zelf dergelijke vensters aanmaakt. De gebruiker hoeft en kan daar niets voor doen. Ze zijn ook niet zichtbaar voor de gebruiker.

Samenvatting van de aandachtspunten

  • Niet Ontdubbelen: heb je meerdere blokken te plaatsen met of-takken en je wenst in elk blok dezelfde keuze van of-tak dan kan de ZR-Link NIET via vensters opgelost worden.
  • Meer dan 256 of-takken: heb je meer dan 256 of-takken in de gecombineerde opdracht, zou die ontstaan via samensmelten, dan kan de ZR-Link NIET via samensmelten opgelost worden.
  • Overlap in resources: heb je overlappende resources in de opdrachten die samen in een ZR-Link zitten dan kan deze ZR-Link NIET via vensters oplossen.

Door een combinatie van bijvoorbeeld teveel of-takken en de vraag naar “Niet Ontdubbelen” kan het zijn dat er geen enkele mogelijkheid is om de ZR-Link op te lossen. Mondriaan zal hier een foutboodschap voor geven.

De keuze kan toch een andere oplossing opleveren

De manier waarop ZR-Links hier opgelost worden door de MBE gaat meer dan waarschijnlijk ook het resultaat van de MBE bepalen. Doordat op een andere manier naar de oplossing gezocht wordt, kan de uitkomst ook anders zijn. In alle gevallen gaat de oplossing wel aan alle gestelde voorwaarden voldoen maar zoals al eerder vermeld, zijn er meestal erg veel oplossingen voor hetzelfde probleem.

Bloklink constructie

Dit is een eerder technische optie die bepaalt op welke manier de “Bloklinks” vertaald moeten worden naar de MBE. Deze optie heeft dus geen enkel effect op de beperking van de Bloklink zelf, enkel op de manier waarop ze technisch behandeld wordt door de MBE. Toch laten we de optie vrij in te stellen omdat de keuze in sommige gevallen toch een significant effect kan hebben op de doorlooptijd van het roosteren.

Opties:

  • Via vensters en volgordespreidingen: via deze optie stelt men dat er voor een Bloklink een technisch venster aangemaakt wordt met een grootte die toelaat om beide opdrachten, te kunnen bevatten. Als er een volgorde gevraagd wordt (Bijvoorbeeld een TV-vak moet voor een PV-vak komen) dan wordt er een technische volgordespreiding gemaakt die die volgorde afdwingt. Deze constructie is trouwens de enig mogelijke van zodra beide opdrachten minstens één verschillende resource bevatten. Stel dat de ene opdracht in lokaal L1 doorgaat en de tweede in lokaal L2 dan kan (mag) mogen de opdrachten niet versmolten worden tot één opdracht, omdat dan zowel L1 als L2 teveel bezet zou worden door deze opdracht. Het voordeel van deze constructie is dus dat de opdrachten niet noodzakelijk dezelfde resources moeten bevatten. Het nadeel van deze constructie is dat de opdrachten elkaar moeten vinden in het rooster via het technische venster en dat er ook nog de goede volgorde moet bepaald worden.
  • Via samensmelten indien dezelfde resources: via deze optie worden de beide opdrachten die in een Bloklink zitten, samengevoegd tot één technische opdracht. Het voordeel hiervan is dat de opdrachten elkaar niet moeten “vinden” in het rooster maar als één blok geplaatst worden. Het nadeel is enkel dat deze constructie niet mogelijk is indien de opdrachten niet exact dezelfde resources hebben.

De standaardoptie is de tweede. Indien het het om dezelfde resources gaat, dan wordt de opdracht samengesmolten, anders wordt voor de oplossing met “technische vensters en volgordespreiding” gekozen. Indien men de eerste optie kiest, dan wordt er altijd met technische vensters en volgordespreidingen gewerkt.

De keuze kan toch een andere oplossing opleveren.

De manier waarop Bloklinks hier opgelost worden door de MBE gaat meer dan waarschijnlijk ook het resultaat van de MBE bepalen. Doordat op een andere manier naar de oplossing gezocht wordt, kan de uitkomst ook anders zijn. In alle gevallen gaat de oplossing wel aan alle gestelde voorwaarden voldoen, maar zoals al eerder vermeld, er zijn meestal erg veel oplossingen voor hetzelfde probleem.

Spreidingen in combinatie met Bloklink die via Samensmelten gerealiseerd wordt.

Indien men een Bloklink via samensmelten realiseert (=standaardoptie) dan moet men opletten met spreidingen. Zowel voor extra spreidingen (waardespreidingen, volgordespreidingen) als voor opdrachtspreidingen kan het beoogde effect misschien niet gerealiseerd worden. Stel dat we een eerste opdracht van 2 uur hebben met vak V1 en een tweede van 4 uur met vak V2. Als die via samensmelten gerealiseerd worden, dan gaat Mondriaan de MBE een opdracht van 6 uur geven waarin alle resources en vakken van zowel de eerste als de tweede opdracht zitten. Voor de MBE is dit dus gewoon een opdracht van 6 uur met de vakken V1, V2. Het is in deze context dat de gevraagde spreidingen ook geïnterpreteerd zullen worden. Zowel vak V1 als vak V2 staan 6 uur in het rooster. Als men dan bijvoorbeeld een eenvoudige opdrachtspreiding zou opgeven voor de eerste opdracht die stelt dat V1 max 3 uur per dag mag staan, dan gaat dat nooit lukken omdat de MBE denkt dat V1 meteen 6 uur geplaatst wordt. Zo zijn er nog een heel aantal voorbeelden aan te halen.

Mondriaan zal voor de opdrachtspreidingen in dit geval zeker een waarschuwing geven en indien de opdracht hierdoor helemaal niet geplaatst kan worden zal er ook een foutboodschap volgen. Dit probleem kan men vermijden door de Bloklinks via vensters en volgordespreiding re realiseren.

Effect van Roosteropties op “Valideer Rooster” en “Valideer Rooster met opties”

De actie “Valideer Rooster” houdt geen rekening met de opties die gezet worden in “Opties | Roosteren”. “Valideer Rooster” houdt enkel rekening met inactief gemaakte componenten in de respectievelijke tabbladen (elementen, spreidingsregels, vensters, etc).

Dus, als men bepaalde aspecten heeft uitgeschakeld via “Opties | Roosteren” en het resultaat van de MBE wordt na het roosteren onder deze opties bekeken, dan zal “Valideer Rooster” naar alle waarschijnlijkheid problemen vinden. Schakelt men bijvoorbeeld opdrachtspreidingen uit, dan komt de MBE terug met een resultaat dat waarschijnlijk sommige opdrachtspreidingen niet respecteert. “Valideer Rooster” gaat deze problemen dan naar boven halen.

Wenst men de rooster wel te valideren tegen deze roosteropties, dan gebruikt men “Valideer Rooster met opties”.

Print Friendly, PDF & Email

Didn't find your answer? Contact Us

  

Veelgezochte termen:Outputrooster, Volgordespreiding, Partitie