Automatisch Roosteren en Problemen Analyseren – time-tech

Optimaliseren van Leerkrachtroosters

Peter — Sun, 14 Jan 2018 14:30:22 +0000

Optimaliseren van Leerkrachtroosters

Het optimaliseren van lerarenroosters gebeurt door de compressie van de lesopdrachten van de betrokken leraar. M.a.w. er worden zoveel mogelijk “gaten” of springuren vermeden tussen de lessen in. Een eerste compressie van het rooster gebeurt reeds bij het toekennen van vrije halve dag(en) via de wensen. Er zijn echter belangrijke verschillen tussen de manieren waarop de compressie gebeurt: via wensen of via optimalisatie.

Het effect is voor beide systemen echter identiek: de lerarenroosters verbeteren. (zonder afbreuk te doen aan de didactische voorwaarden!)

Wensen zijn opdrachten die net als lesopdrachten kunnen falen. Er is geen voorrang: een wens kan geplaatst worden en een lesopdracht kan falen en vice versa. Er is dus geen
onderscheid mogelijk tijdens het plannen. De optimalisatietechniek is wel dezelfde: er worden bijkomende blokopdrachten, van bepaalde groottes (8, 4, 3, 2, 1, …), aangemaakt die als opdrachten, gekoppeld aan bepaalde leraren, kunnen geroosterd worden. Deze optimalisatieopdrachten worden na het normale planwerk gedaan waarbij de reeds geplaatst lesopdrachten en wensen niet meer kunnen falen. Het enige wat optimalisatieopdrachten doen is het verder comprimeren van de bestaande lerarenroosters.

Informatie over leerkrachtwensen kan men vinden op de pagina “Definiëren van Leerkrachtwensen“.

Voor leerkrachtoptimalisaties zijn er 2 aparte technieken voorhanden:

werken met optimalisatieopdrachten die Mondriaan zelf aanmaakt;
werken met zelf gedefinieerde optimalisatieopdrachten.

Mondriaan heeft een eigen techniek om de kwaliteit van een leerkrachtrooster te beoordelen. Op basis van springuren, aantal uren les, etc wordt er aan elke leerkracht een cijfer gekoppeld. Ook laat Mondriaan toe om de evolutie van dit cijfer tussen 2 plansessies op te volgen zodat men kan zien waar er verbetering is en waar er nog werk te verrichten is om de roosters te verbeteren.

Compressie van leerkrachtroosters via verschillende technieken

	Wensen	Automatische optimalisatie	Eigen optimalisatieopdrachten bijroosteren
Tijdstip	Tijdens het roosteren van de lesopdrachten.	Na het finaliseren van het didactische rooster, al dan niet aangevuld met wensen.	Na het finaliseren van het didactische rooster, al dan niet aangevuld met wensen.
Risico	Lesopdrachten kunnen falen ten voordele van wensen.	Lesopdrachten en wensen kunnen niet falen. Optimalisatieopdrachten zijn niet zichtbaar voor de gebruiker. Mondriaan maakt ze aan en ze kunnen falen.	Lesopdrachten en wensen kunnen niet falen. De Optimalisatieopdrachten die de gebruiker aanmaakt kunnen falen.
Doel	Aan opgebouwde rechten van leraren trachten te voldoen.	Verdere compressie van het rooster om flagrante problemen op te lossen i.v.m. springuren of geïsoleerde uren. Globale verbetering van de kwaliteit van alle lerarenroosters. Niet individueel.	Verdere compressie van het rooster om flagrante problemen op te lossen i.v.m. springuren of geïsoleerde uren. Kan per leerkracht gestuurd worden. Incrementeel toevoegen is mogelijk.
Kracht	Deze wensen moeten steeds voldaan zijn om van een didactisch rooster te kunnen spreken.	De gebruiker heeft er weinig werk mee. Meestal kunnen de resultaten wel beter gemaakt worden via eigen gemaakte optimalisatieopdrachten. Er zijn 2 verschillende automatische technieken die aangeboden worden.	Maximale kracht en flexibiliteit. Wel arbeidsintensief maar een geoefend gebruiker kan hier echt het onderste uit de kan halen voor het lerarenkorps.
Resultaat	Wensen staan in het rooster.	Na plannen zijn de optimalisatieopdrachten weer verdwenen. Enkel hun compressie-effect blijft zichtbaar.	Na plannen blijven de optimalisatieopdrachten in het rooster. De gebruiker kan ze er wel uithalen. Hun compressie-effect blijft zichtbaar.

Inhoud

Optimalisatie activeren
- Tabbladen die tevoorschijn komen door de optie “Optimalisatie”
Kwaliteit van een leerkrachtrooster
Automatische optimalisatietechniek
- Automatische optimalisatie met staafvormige blokken
- Automatisch springuren verminderen met polymorfe opdrachten
Zelf optimalisatieopdrachten maken en roosters individueel optimaliseren
Nog enkele tips en weetjes

Optimalisatie activeren

Men activeert de optimalisatie van zodra het rooster didactisch in orde is, en ook de noodzakelijke leerkrachtwensen geroosterd zijn. Optimaliseren is in theorie de laatste stap in het roosterproces, maar dat wil niet zeggen dat men daarna niet meer verder kan met het aanpassen van het rooster, al dan niet automatisch. Optimalisatieopdrachten kan men steeds weer uitschakelen (verwijderen uit het rooster of inactief maken) om weer te roosteren zonder optimalisatie. We komen hier later op terug.

Het activeren van optimalisatie brengt Mondriaan in een andere toestand waarbij er extra tabbladen tevoorschijn komen en waarbij sommige roosterinstellingen niet meer gekozen kunnen worden.

De activatie gebeurt door in het optiescherm (Opties | Andere | Geavanceerd) het vinkje “Optimalisatie” aan te vinken.

Een eerste gevolg hiervan zien we in het beschikbaar stellen van volgende opties in het optiescherm op de plaats “Opties | Roosteren | Bijkomende leerkrachtspecifieke opdrachtselectie“. Uitgebreide uitleg is te vinden in bij de roosteropties in de getoonde link.

De optie “Optimalisatieopdrachten meeroosteren” is hier van belang omdat we via dit vinkje de beslissing nemen tussen volgende 2 optimalisatietechnieken:

Automatische optimalisatie
Eigen optimalisatieopdrachten bijroosteren

Men kan steeds wisselen tussen beide opties. Zoals we verder zullen tonen, komt er na het aanvinken van “Optimalisatie” een tabblad bij onder “Opdrachten” waar de gebruiker de kwaliteit van de lerarenroosters kan evalueren en waar de gebruiker ook zelf optimalisatieopdrachten kan aanmaken.

Kiest men voor de optie “Optimalisatieopdrachten meeroosteren” dan worden de door de gebruiker gedefinieerde optimalisatieopdrachten geroosterd. Vinkt men deze optie uit, dan verdwijnen die optimalisatieopdrachten uit het rooster en gaat men over tot “Automatische optimalisatie”. Aanvinken en uitvinken heeft dus steeds tot gevolg dat men van het ene naar het andere systeem overgaat. Ofwel zijn de eigen gedefinieerde optimalisatieopdrachten actief, ofwel de automatisch gegenereerde optimalisatieopdrachten.

Een ander effect van het kiezen voor de “Optimalisatie” modus zien we in het optietabblad “Opties | Engine”.

Een aantal opties worden rood voorgesteld omdat ze niet bruikbaar zijn in een optimalisatiestap. Bij optimaliseren gaan we typisch incrementeel bijroosteren en wat bijgeroosterd wordt, zijn net de optimalisatieopdrachten die ervoor zorgen dat de leerkrachtroosters verbeteren.
Mondriaan gaat dan ook meteen de meest voor de hand liggende keuzes voorstellen zoals hier voorgesteld.

Tabbladen die tevoorschijn komen door de optie “Optimalisatie”

Van zodra de optie “Optimalisatie” aangevinkt is, komen er onder het tabblad “Opdrachten” een aantal tabbladen tevoorschijn. 2 tabbladen zijn specifiek voor het sturen van de manuele optimalisatie en 1 tabblad is bedoeld voor de automatische optimalisatie.

“Opdrachten | Optimalisatie | Selectie” (voor manuele optimalisatie)
- Het linkerdeel van het scherm bevat een overzicht van de leerkrachten en een indicatie van de kwaliteit van hun rooster. De kwaliteit van de roosters is onafhankelijk van de optimalisatietechniek die gebruikt werd, het is gewoon een kwaliteitsmaat. Men ziet ook steeds de nieuwe en de vorige waarde van de kwaliteit. Men kan ook het verschil zien met een eerder ingestelde baseline. Hoe de kwaliteit van een rooster bepaald wordt, leggen we verder uit.
- Het linkerdeel heeft nog een extra functie voor de selectie van leerkrachten die men wenst te optimaliseren via eigen gemaakte optimalisatieopdrachten.
- Het rechterdeel is een scherm waarin optimalisatieopdrachten aangemaakt/voorbereid kunnen worden.
“Opdrachten | Optimalisatie | Bouwstenen” (voor manuele optimalisatie)
- In dit scherm definieert de gebruiker de bouwstenen om optimalisatieopdrachten aan te maken. Deze bouwstenen zijn de blokgroottes en de definitie van de plaatsen waar de blokken kunnen staan. Dit is enkel van toepassing voor het zelf maken van optimalisatieopdrachten.
“Opdrachten | Optimalisatie | Auto optimalisatie” (voor automatische optimalisatie)
- In dit scherm kan men de parameters zetten voor een automatische optimalisatie. Hier kan gekozen worden tussen 2 technieken: via staafvormige blokken of via polymorfe blokken optimaliseren.
- De informatie over de kwaliteit van de roosters werd hier nog eens herhaald.
- Ook de selectie van leerkrachten waarvoor optimalisatie moet gebeuren, kan hier ingesteld worden.
- Om het de gebruiker gemakkelijker te maken werd ook een visualisatiegrid voorzien voor het bekijken van leerkrachtroosters (en andere). Stelt men ook een baseline in, dan kan men die ook hier als 2de grid bekijken. Is op zicht hetzelfde als wat men in Visualisatie | Baseline zou zien.

We bespreken deze tabbladen verderop in deze pagina.

De bouwstenen voor eigen gemaakte optimalisatieopdrachten:

Het tabblad voor de automatische optimalisatie:

Kwaliteit van een leerkrachtrooster

Voor we aan de optimalisatietechnieken beginnen, is het nuttig om even stil te staan bij de manier waarop Mondriaan de roosters van leerkrachten zelf evalueert en er een kwaliteitscijfer aan koppelt.

Mondriaan bekijkt 2 aspecten om tot een cijfer te komen:

Benutting van de beschikbare tijd: als een leerkracht op een bepaalde dag les heeft, dan is het aangewezen dat hij zoveel mogelijk van de beschikbare tijd van die dag nuttig is op school. Maar één uur les hebben is bijvoorbeeld een zeer slechte benutting van de beschikbare uren in de dag. Omdat er ook wensen van leerkrachten gerespecteerd moeten worden i.v.m. halve vrije dagen, of eventueel effectief vrije dagen, worden de momenten waarop wensen gepland worden niet in rekening gebracht voor de bepaling van de benutting. De wensuren zijn tenslotte geplande uren. Per dag wordt de benutting bepaald en een cijfer opgeplakt. Via een gewogen gemiddelde (op basis van het aantal uren per dag) wordt een weekbenutting bepaald.
Springuren in de dagen: springuren worden veelal als onwenselijk ervaren. Bekijken we een werkdag in de school, dan worden springuren gedefinieerd als de lege uren die zich tussen het eerste en laatste lesuur van de leerkracht bevinden. Hoe meer springuren, hoe slechter voor de leerkracht. Ook hier wordt weer een gewogen gemiddelde (op basis van het aantal uren per dag) genomen over de ganse week om tot een cijfer te komen.

Beide aspecten worden door Mondriaan berekend en tellen evenveel door in het eindcijfer. Het cijfer varieert van 0 tot 100 waarbij 100 een optimaal rooster is.

Voorbeeld van een verschil in kwaliteit voor dezelfde rooster door automatische optimalisatie

In het tabblad “Opdrachten | Optimalisatie | Selectie” zien we dat een optimalisatiestap die we uitgevoerd hebben een verbetering heeft gegeven voor bijvoorbeeld MVVL. We zijn van 64,4 naar 81,5 gegaan. De vraag is hoe je dat kan zien in het rooster zelf.

Net voor de optimalisatiestap werd een baseline gemaakt (Huidig model in dit geval, zie pagina “Huidig rooster met een baseline vergelijken” voor meer info over baseline). We kunnen nu in de visualizer (“Visualisatie | Baseline”) de huidige en vorige versie van het rooster van MVVL opvragen. Links de nieuwe versie, rechts de baseline. We zien hier duidelijk een verbetering. Woensdag is compacter geworden (1 springuur minder), donderdag is volledig vrij gemaakt, en vrijdag is een mooi gevulde dag geworden.

Vanaf versie 2023.1.0 kan deze Baseline ook in het tabblad “Auto optimalisatie” bekeken worden.

Extra vergelijkingsmogelijkheden t.o.v. de Baseline

Indien men een baseline actief heeft, dan kan men ook de verschillen in kwaliteit zien t.o.v. deze baseline. Men ziet dan 2 verschillen:

Verschil ten opzichte van de vorige situatie (Vorige, Verschil)
Verschil ten opzichte van de baseline (Baseline, Verschil B)

Berekening van de kwaliteit in meer detail

Bekijken we volgende 2 voorbeelden van roosters voor NV en EJ. Beide leerkrachten hebben een aantal uren les en hebben ook elk 2 wensopdrachten van 4 uur.

In volgende tabel zetten we de cijfers op een rijtje die de kwaliteit bepalen. Bekijken we NV op maandag:

Maandag telt 8 uren.
Er zijn 4 beschikbare uren want van de 8 zijn er 4 ingevuld door een wensopdracht.
Er zijn 2 uren bezet door lessen.
Er is 1 springuur
Nuttig = 1 – (Beschikbaar – Bezet)/Beschikbaar = 1 – (4 – 2)/4 = 1 – 1/2 = 0,50
Compact = 1 – Spring/(Beschikbaar – 1) = 1 – 1/(4-1) = 1 – 1/3 = 0,67
Combi = (Nuttig + Compact)/2 = (0,50 + 0,67)/2 = 0,58
Om de weekkwaliteit te bepalen, maken we het gewogen gemiddelde van Combi o.b.v. het aantal uren per dag (Dag).
Qdag = Dag * Combi = 8 * 0,58 = 4,67
Berekenen we Qdag voor elke dag en maken we het gewogen gemiddelde, dan komen we uit op een Weekkwaliteit van 68,63%

Het rooster van EJ is duidelijk beter dan dat van NV:

NV heeft 4 springuren, EJ heeft er 2
De benutting van de dagen voor NV zijn ook merkelijk beter dan die voor EJ.

Merk op dat er plannen zijn om de roosterkwaliteit van leerkrachten anders te berekenen zodat geïsoleerde uren harder afgestraft worden. Van zodra dat gebeurd is, zal deze sectie hier ook aan aangepast worden.

Automatische optimalisatietechniek

Er zijn 2 automatische technieken beschikbaar die allebei werken op basis van filler-opdrachten (vulopdrachten) die de leerkrachtroosters trachten te verbeteren.

Via staafvormige blokken die van groot naar klein geprobeerd worden.
Via polymorfe blokken die voor en na lessen geplaatst worden.

Beide technieken kunnen door elkaar gebruikt worden. Men kan eerst de ene en dan de andere proberen.

In het optietabblad “Opties | Roosteren | Bijkomende leerkrachtspecifieke opdrachtselectie” moet de checkbox “Optimalisatieopdrachten meeroosteren” uitgevinkt staan om automatisch optimaliseren te activeren.

De techniek gaat uit van Mondriaan zelf en vraagt geen interventie van de gebruiker buiten het zetten van enkele opties voor de MBE en de optimalisatie te starten. Volgende opties worden normaal standaard goed gezet als men automatische optimalisatie gebruikt:

Geen kennis vergaren. (automatisch uitgezet voor optimalisatie)
Incrementeel bijroosteren (gebruik huidig rooster als hint). We vrijwaren de lesopdrachten maar ze kunnen wel van plaats wijzigen.
Methode 1 diepte 3.

Verder kan men in opeenvolgende stappen de zoekdiepte zelf wat verhogen:

Methode 1 met een diepte 4, 5, 6, 7 of uitzonderlijk nog hoger.

Het tabblad om de automatische optimalisatie te sturen:

Parameters die in het scherm opgegeven kunnen worden:

Aantal leerkrachten: het systeem werkt met groepjes van leerkrachten die men gelijktijdig optimaliseert. Het systeem kan bijvoorbeeld 5 leerkrachten tegelijk trachten te verbeteren. Daarna de volgende 5 etc. Heeft men 100 leerkrachten dan zal het systeem 20 keer een optimalisatieslag doen, telkens voor de 5 volgende leerkrachten.

Herstart zolang verbetering: als na de optimalisatie (alle leerkrachten zijn aan bod geweest) er een globale verbetering is, dan wordt het geheel opnieuw gestart met dezelfde instellingen. Dit gaat door tot er geen verbetering meer is.

Opgelet met deze optie bij multiweekroosters: bij een multiweekrooster zal het optimaliseren langer duren naar gelang er meer weken in de multiweekrooster zitten. Zeker voor scholen die elke week van het schooljaar in het basisrooster opnemen. Vandaar is het best deze optie in eerste instantie niet te kiezen en af te wachten wat een eerste ronde al doet qua verbetering. Zeker in dergelijke grote roosters zal er altijd wel een verbetering gevonden worden waardoor Mondriaan steeds zal herstarten en het erg lang kan duren.

Methode: Mondriaan heeft nu 2 methoden waaruit men kan kiezen. Het vraagt wat experimenteren om te zien de welke het best aan de behoefte voldoet.

Via staafvormige blokken roosters comprimeren. Dit is de oudste methode in Mondriaan.
Via polymorfe blokken springuren verminderen. Deze methode is beschikbaar vanaf versie 2023.1.0

In het rechterpaneel zijn 2 grids (maar 1 getoond) voorzien waarin men leerkrachtroosters kan bekijken:

links de huidige situatie van een leerkracht;
rechts de baseline voor diezelfde leerkracht als er een baseline ingesteld is.

In het linkerpaneel ziet men ongeveer dezelfde informatie als in het linkerpaneel van “Selectie”. Men ziet de lijst van bestaande leerkrachten en informatie over hun roosterkwaliteit. De kolommen zijn:

Optimaliseren: moet deze leerkracht geoptimaliseerd worden.
Acro: de leerkracht.
Max Springuren / Max Springuren (gemiddeld): maximaal aantal springuren dat men wenst toe te laten per week voor de leerkracht. Dit is een streefcijfer. De default is 0 maar soms is het ook nuttig om toch wat springuren te voorzien om de roosters niet te zwaar te maken. Enkel beschikbaar indien men de methode “Via polymorfe blokken springuren verminderen” ingesteld heeft. Voor een multiweekrooster wordt met een gemiddelde gewerkt over alle roosterweken, vandaar de andere kolomnaam in geval van een multiweekrooster.
Springuren / Springuren (gemiddeld): het effectief aantal springuren in het huidige rooster. Voor een multiweekrooster zal dit een gemiddelde zijn over alle roosterweken, vandaar de andere kolomnaam.
Kwaliteit: huidige kwaliteit van het rooster.
Vorige: kwaliteit voor de laatste optimalisatie.
Verschil: verschil tussen Vorige en huidige Kwaliteit
Baseline: kwaliteit die er was t.o.. Baseline (als die gezet was).
Verschil B: verschil tussen kwaliteit Baseline en de huidige Kwaliteit.

Automatische optimalisatie met staafvormige blokken

Wil men deze techniek gebruiken, dan drukt men gewoon op “Plan” (“Plan selectie” kan ook maar is minder gebruikelijk).

Drukt men op “Plan” dan zal men zien dat Mondriaan verschillende keren de MBE zal opstarten om incrementeel de roosters van de leerkrachten te verbeteren. Mondriaan past volgende techniek toe:

De 5 leerkrachten (die nog niet aan de beurt geweest zijn) met de laagste kwaliteitscijfers worden geselecteerd. Merk op dat enkel leerkrachten in aanmerking komen die het “Optimaliseren” vlagje aangevinkt hebben staan.
In een eerste stap wordt gekeken naar hele dagen die minder dan 50% bezet zijn. Voor die dagen wordt een poging gedaan om de leerkracht volledig vrij te roosteren op die dag. Dit gebeurt via optimalisatieopdrachten die een volledige dag vrijmaken (een staafblok van 1 dag).
In een tweede stap wordt gekeken naar halve dagen die minder dan 50% bezet zijn. Voor die halve dagen wordt geprobeerd om die vrij te roosteren met optimalisatieopdrachten ter grootte van een halve dag (een staafblok van een halve dag). Indien een dag bestaat uit een oneven aantal roosterpunten dan zal de eerste helft een uur meer bevatten dan de tweede helft.
In een derde stap wordt ook weer naar halve dagen gekeken die minder dan 50% bezet zijn en waar geen halve dag vrijgemaakt kon worden. Hier wordt dan geprobeerd om met optimalisatieopdrachten ter grootte van een kwart dag het rooster verder te comprimeren (een staafblok van een kwart dag). In de eerste halve dag wordt geprobeerd het eerste kwart vrij te roosteren. In de tweede helft wordt geprobeerd de tweede helft vrij te roosteren.
In een vierde stap wordt gekeken naar dagen met springuren. Voor die dagen wordt een poging gedaan om die springuren weg te roosteren. Dit gebeurt door optimalisatieopdrachten te plaatsen op de randuren van die dagen ter grootte van het aantal springuren op die dag.
Na uitvoering van deze 4 stappen voor die 5 geselecteerde leerkrachten wordt er door Mondriaan volgende beslissing genomen per stap:
- alle niet geplande optimalisatieopdrachten worden sowieso verwijderd
- indien de globale kwaliteit niet toegenomen is, worden de optimalisatieopdrachten die in deze stap geplaatst werden toch weer weggehaald en wordt de tot dan toe beste oplossing weer als vertrekbasis gebruikt. Merk op dat het steeds de globale kwaliteit is die gemonitord wordt en dit is onafhankelijk van de selectie leerkrachten die men optimaliseert.
- indien de globale kwaliteit wel gestegen is worden de geplaatste optimalisatieopdrachten in het rooster behouden voor de volgende iteratie.
Daarna worden de volgende 5 leerkrachten geselecteerd en start de volgende iteratie.
Dit gaat door tot alle leerkrachten één keer aan bod gekomen zijn.

Tijdens de optimalisatie zal men dit voortgangsscherm zien. Hier ziet men dat Mondriaan al 7 van de in totaal 140 keer (afhankelijk van het aantal actieve leerkrachten) de MBE opgestart heeft. Omdat we gevraagd hebben door te gaan zolang er verbetering is zien we “Optimalisatie 1-7/140″. De 1 duidt op de eerste ronde.

Na gans dit proces worden alle automatisch aangemaakte optimalisatieopdrachten uit het rooster verwijderd. De andere opdrachten blijven op hun geoptimaliseerde positie staan.

Als voorbeeld nemen we een niet geoptimaliseerd rooster en stellen de juiste opties in zoals eerder aangegeven. We bekijken het tabblad waarin we de kwaliteit van de leerkrachtroosters kunnen bekijken:

Men kan eerst een Baseline nemen om het verschil tussen voor en na het optimaliseren beter op te volgen via “Rapportering | Baseline | huidig model”.

We drukken op “Plan” en zien dat Mondriaan iteratief pogingen doet om het rooster te verbeteren zonder verdere interventie van de gebruiker. Als Mondriaan klaar is, wordt er nog een klein rapport getoond met alle stappen die uitgevoerd werden om te optimaliseren.

Het resultaat kan men verder bekijken in het “Auto optimalisatie” tabblad. Men ziet nu dat de kolom “Vorige” gevuld is en dat men in de kolom “Verschil” het verschil kan zien. De globale kwaliteit wordt onderaan getoond. In dit geval zijn we globaal van 79 naar 79,1 gegaan. Om dit te bereiken werden de roosters van sommige verbeterd, weer andere hebben een minder goed rooster. Wat hier telt, is de globale verbetering en niet de individuele.

Wil men deze techniek gebruiken (vooral vanwege het gemak) doet men er wel goed aan om verschillende pogingen achter elkaar te doen met eventueel oplopende zoekdieptes voor Methode 1. Zoals eerder uitgelegd, is het een zeer rudimentaire methode waarvan men niet de beste oplossingen mag verwachten. Een tweede methode die aangeboden wordt, is die met polymorfe blokjes die in combinatie met volgordespreidingen zoveel mogelijk springuren tracht weg te werken.

Merk op dat “Plan selectie” ook werkt maar dit heeft meestal geen zin. Bij “Plan selectie” wordt enkel rekening gehouden met de geselecteerde opdrachten en daarrond wordt geoptimaliseerd. Hierdoor verliest men alle niet geselecteerde opdrachten uit het rooster.

Automatisch springuren verminderen met polymorfe opdrachten

Het basisprincipe is hetzelfde als voor de techniek met de staafvormige blokopdrachten maar bij deze techniek wordt via polymorfe blokken vooral ingezet op het verminderen van springuren in het rooster. Als we de 2de methode kiezen, dan zal men ook de kolom “Max springuren” ter beschikking krijgen. Hier kan men het gewenst maximaal aantal springuren instellen en men kan het vergelijken met de kolom “Springuren” waarin het effectief aantal springuren staat. Het maximum dat men instelt, is een streefcijfer. Standaard staat dat op 0 maar er kunnen steeds redenen zijn om toch wat zuurstof in het rooster te behouden.

Techniek die gebruikt wordt om springuren te verminderen:

Stel dat een leerkracht 7 springuren heeft in een week en dat we toelaten dat hij er 3 heeft. Mondriaan gaat dan 4 blokjes in het rooster trachten te plaatsen voor en na de lesopdrachten. De 4 blokjes zijn dus losse uren die in erg veel configuraties geplaatst kunnen worden. Vandaar de naam “Polymorf blok”. Via volgordespreidingen (VS), die achter de schermen worden aangemaakt, zorgt Mondriaan er voor dat die 4 blokjes nooit tussen lesopdrachten kunnen vallen, maar steeds er voor of er achter. Het polymorf blok kan dan bijvoorbeeld als volgt geplaatst worden:

4u : een volledig dagdeel
2 + 2 blokken op boven/en onderrand
3 + 1 blokken op boven/en onderrand
2 + 1 + 1 blokken op boven/en onderrand
1 + 1 + 1 + 1 blokken op boven/en onderrand

Voorbeeld van uitvoering van de optimalisatie:

De standaardinstelling voor de engine die gebruikt wordt, is diepte 3 methode 1. We zetten de diepte op 4.

We drukken op “Plan”. Net zoals bij de andere automatische techniek zien we een popup-scherm met de voortgang. Nadien krijgen we een rapportje met de verbeterstappen die uitgevoerd zijn. We hebben 5 leerkrachten per run ingesteld en we hebben gevraagd om door te gaan tot er geen globale verbetering meer is.

We zien dat BAERT en BAHSN erop vooruit gegaan zijn, maar de globale kwaliteit is niet gewijzigd. Ze hebben allebei 1 springuur minder. Dit wil zeggen dat er andere leerkrachten op achteruit gegaan zijn (zijn rood gemarkeerd ipv groen).

In het linkerscherm zien we in de kolom “Verschil” de verbetering van de kwaliteit.

We willen deze situatie nu bijvoorbeeld als Baseline gebruiken. We drukken op de knop “Rapportering | Baseline | Huidig model” om de baseline in te stellen. De kolommen Baseline en Verschil B komen dan tevoorschijn. Op dit moment is de baseline gelijk aan het huidige model. In het rechterpaneel komt er een grid bij die de baseline voorstelt. De selectie van leerkrachten kan enkel in de linker grid gebeuren. De rechter grid zal volgen. Momenteel zijn beide grids gelijk aan elkaar.

Om een volgende verbeterslag te doen, verhogen we de diepte van methode 1 tot bijvoorbeeld 6, behouden de andere instellingen en drukken op “Plan”.

Opnieuw het rapport met wijzigingen. Merk op dat er in dit rapportje enkel info staat over de geselecteerde leerkrachten die er op vooruit of achteruit gaan. De niet geselecteerde leerkrachten zullen ook geïmpacteerd zijn, maar dat is gewoon het gevolg dat men accepteert indien men met een beperkte set van leerkrachten werkt.

Resultaat in linkerpaneel:

Blijkbaar is BAHSN er goed op vooruit gegaan. We kunnen in het rechterpaneel zijn huidig rooster met de baseline vergelijken en zien inderdaad dat we van 6 naar 2 springuren gegaan zijn.

Merk op dat als men leerkrachten selecteert in de Resource dropdown van het linkerpaneel, dat de leerkrachten een kleur kunnen hebben in de lijst:

ROOD: huidig is gewijzigd ten opzichte van de baseline.
geen kleur: geen wijziging.

We proberen nog een stap verder te gaan en verhogen uitzonderlijk tot diepte 7 voor deze beperkte selectie van leerkrachten.

Er is geen verbetering, dus worden alle wijzigingen die hierdoor veroorzaakt werden ongedaan gemaakt.

Als laatste zetten we de diepte op 4 en selecteren alle leerkrachten. Na Plan zien we dit verslag:

Een globale verbetering en die wordt behouden. De baseline was 79,1, de vorige was 79,2 en de laatste was 80,0.

Op deze manier kan men spectaculaire verbeteringen bekomen van leerkrachtroosters. We raden de gebruikers aan om hier voldoende mee te experimenteren zodat ze deze techniek kunnen gebruiken als sluitstuk om hun roosters optimaal te maken voor het leerkrachtenkorps. Het zal zeker gewaardeerd worden!

Zelf optimalisatieopdrachten maken en roosters individueel optimaliseren

Deze techniek laat toe om zeer individueel te gaan optimaliseren. Men kan per leerkracht en/of groep leerkrachten optimaliseren. Dit is geen one-shot techniek, maar een iteratief proces waarbij men telkens de roosters evalueert en beslist waar er nog bijgeschaafd moet worden. Een geoefend gebruiker kan via deze techniek enorme verbeteringen in de roosters aanbrengen die zeker door het lerarenkorps gewaardeerd zullen worden. De kunst bestaat erin om individuele verbeteringen in evenwicht te houden met de verbetering van de totaliteit.

Instellingen in de optietabbladen

In het optie tabblad “Opties | Roosteren | Bijkomende leerkrachtspecifieke opdrachtselectie” moet zeker “Optimalisatieopdrachten meeroosteren” aangevinkt staan om deze modus te activeren. Verder laten we “Wensen meeroosteren” ook gewoon opstaan om de reeds geplaatste wensen niet te verliezen. De optie “Negeer niet-geplaatste normale opdrachten” staat ook aangevinkt, wat enkel nuttig is indien men wenst te optimaliseren in een context waarbij niet alle lesopdrachten geplaatst zijn en men ook niet wenst dat die mee geselecteerd worden. We willen enkel zelf gemaakte optimalisatieopdrachten bij roosteren.

Voor de opties in “Opties | Engine” kiezen we volgende opties.

Deze instellingen houdt men aan tijdens het optimalisatieproces. Men kan eventueel wel wat spelen met de diepte-instellingen voor de gekozen methode.

Bouwstenen maken om te optimaliseren

Optimaliseren van roosters betekent in wezen het zoveel mogelijk groeperen of compacteren van de lesuren van een leerkracht. De gebruiker beslist zelf voor welke leerkrachten en op welke manier deze compactering moet gebeuren. Een handige manier om een rooster te compacteren is door de betreffende leerkracht vrij te roosteren op ganse voormiddagen en of ganse namiddagen. Dit doen we door een aantal blokken van 4 uur vrij te roosteren, waarbij die blokken kunnen beginnen op de 1ste en 5de uren van een willekeurige dag van de week. Omdat we dit in theorie voor elke leerkracht nodig kunnen hebben, maken we van dat blok van 4 uur dat op die momenten mag staan een “bouwsteen”. Een andere bouwsteen zou bijvoorbeeld een blok van 2 uur kunnen zijn die op de 1ste en 7de uren van de dag mogen beginnen. De gebruiker is vrij om zijn bouwstenen zelf te definiëren.

Bouwstenen maakt men aan in het tabblad “Opdrachten | Optimalisatie | Bouwstenen”. Het volgende voorbeeld definieert deze voorbeelden:

De bouwstenen hebben de volgende eigenschappen:

ID: read-only technische identificatie.
Acro: een door de gebruiker bepaalde naam voor de bouwsteen.
Grootte: grootte van het blok dat men wenst vrij te roosteren.
Startuurlijsten: mogelijke startmomenten van het blok.
Mogelijkheden (~~Uurlijst~~): read-only visuele representatie van de mogelijke bezetting van het blok rekening houden met de startuurlijsten en de grootte.
Commentaar: vrij te gebruiken.

Gebruiken van de bouwstenen in optimalisatieopdrachten

in het tabblad “Opdrachten | Optimalisatie | Selectie” heeft men 2 delen. Het linkerdeel van het scherm werd eerder al besproken. Hier kan men de kwaliteit van de roosters bekijken en de leerkrachten selecteren die men wenst te optimaliseren. Als de checkbox “Optimaliseren” aangevinkt is, dan betekent dat dat de geselecteerde optimalisatieopdrachten voor die leerkracht actief zijn voor de volgende ronde van de planning.

Aan de rechterkant staan leerkrachtspecifieke optimalisatieopdrachten. Hier moet de gebruiker de opdrachten voor de leerkrachten definiëren op basis van de eerder gemaakte bouwstenen. De kolommen in het rechterscherm zijn:

Actief: opdrachten zijn actief of niet.
ID: read-only technische identificatie van de opdracht.
Leerkracht(en): een of meerdere leerkrachten waarvoor men dit type opdracht wenst te maken. Merk op dat het vermelden van meerdere leerkrachten niet betekent dat ze samen vrijgeroosterd worden. Het blijven optimalisatieopdrachten per individuele leerkracht. Het is een verkorte schrijfwijze. Maar, als men ze samen zet, maakt men ze ook samen actief of niet.
Categorie: hier geeft men de bouwsteen op. Hiermee zegt men dus welk soort blok men gaat vrijroosteren.
Aantal: hier kan men het aantal blokken opgeven dat men van dit type wenst vrij te roosteren voor de leerkracht.
% Geroosterd: na het plannen staat hier een cijfer in dat weergeeft hoeveel van de gevraagde blokken er ook daadwerkelijk geplaatst zijn. (Voor een beschrijving van de kleurcodes gebruikt in dit veld verwijzen we naar % Geroosterd in het opdrachten tabblad.)
Commentaar: vrij te gebruiken.

Merk op dat een optimalisatieopdracht voor een leerkracht pas geactiveerd is als:

en in het linkerscherm “Optimaliseren” aangevinkt is voor de leerkracht
en in het rechterscherm “Actief” aangevinkt is voor de opdracht.

De MBE probeert om aan zoveel mogelijk van de gevraagde optimalisatieopdrachten te kunnen voldoen terwijl alle andere opdrachten in het rooster blijven staan, maar wel verplaatst kunnen worden tijdens het proces.

In volgend voorbeeld hebben we leerkracht BN aangevinkt met de vraag om er 2 blokken van het type BL2 voor vrij te roosteren. Momenteel is er nog 0% geroosterd.

Bekijken we voor het plannen het rooster van BN (momenteel met kwaliteit 67%) dan zien we dat er al 2 wensen in staan en dat er verder nog wat springuren zijn. De twee gevraagde blokken van 2 uur zouden redelijk gemakkelijk in dit rooster moeten gepland geraken. De eerste krijgen we al gratis op woensdag 1 en voor het tweede blok zal de MBE even moeten zoeken.

Drukken we nu op “Plan” dan start de MBE en als hij klaar is, wordt weer de gekende popup getoond waar nu ook vermeld wordt hoeveel uren er geoptimaliseerd werden.

Verder verschijnt er ook een klein venstertje waarin men kan zien wat het effect was van de optimalisatie. Voor BN een kleine verbetering maar het heeft ook op andere leerkrachten effect gehad.

De informatie uit dit venstertje kan men ook zien in het tabblad “Selectie” waar men de verandering in kwaliteit op de roosters stap per stap kan volgen. BN is er met 1,4 op vooruit gegaan. Rechts ziet men nu dat de 2 gevraagde blokken 100% geroosterd zijn.

Bekijken we BN opnieuw in de visualizer (Roosters) dan zien we 2 purperen blokken in zijn rooster staan (zie linker beeld). BN heeft hierdoor een springuur minder op vrijdag. Rechts ziet men het beeld waarbij men de optimalisatieopdrachten weer inactief gemaakt heeft, maar het effect ervan wel zichtbaar blijft.

Door na het plannen “Actief” uit/aan te vinken, krijgt men het beeld met en zonder de optimalisatieopdrachten.

Het actief of niet actief laten van geplaatste optimalisatieopdrachten

Optimaliseren is een iteratief proces waarbij men steeds verder gaat in het proberen verbeteren van de roosters. Wil men dat het effect van eerder gemaakte verbeteringen (lees “gerealiseerde optimalisatieopdrachten”) niet verloren gaat, dan moet men de eerste geplaatste optimalisatieopdrachten steeds actief laten voor de volgende iteratie. Telkens roostert men op een incrementele wijze nieuwe optimalisatieopdrachten bij. De enige reden waarvoor men eerder geplaatste optimalisatieopdrachten weer inactief zou willen maken, is omdat ze in de weg zouden kunnen zitten van een andere verbetering die men wil realiseren. Voorbeelden hiervan:

men heeft een optimalisatieopdracht van grootte 2 die belet dat we er een van 4 zouden kunnen realiseren in een rooster. Optimalisatieopdrachten kunnen elkaar niet overlappen.
men heeft de rooster van leerkracht A zeer goed gemaakt, maar dat gaat ten koste van het rooster van leerkracht B die veel slechter is. Dan kan men een of meerdere optimalisatieopdrachten inactief maken en of vervangen door andere.
…

Uiteindelijk is het de bedoeling dat er zoveel mogelijk gerealiseerd worden en dus actief zijn.

Merk op dat indien men een eerder geplaatste optimalisatieopdracht inactief maakt dat zijn effect op het rooster niet noodzakelijk verdwijnt. Als de MBE vervolgens een planning doet, kan het zijn dat het effect blijft of tenietgedaan wordt. Het is enkel als men ze actief laat dat de MBE ze blijvend als geplaatst zal respecteren.

Hoe meer optimalisatieopdrachten er actief zijn, hoe moeilijker het natuurlijk wordt om er nog bij te realiseren, niet alleen binnen hetzelfde rooster maar ook tussen roosters. Daarom is het goed om het evenwichtig aan te pakken en niet een paar leerkrachten te bevoordelen ten koste van alle andere.

Rechtermuisklikacties in de Optimalisatie tabbladen

Rechtermuisklikacties in “Opdrachten | Optimalisatie | Bouwstenen”

Rechtermuisklikacties in “Opdrachten | Optimalisatie | Selectie” – Linkerpaneel

Handig is zeker de actie “Bekijk op rooster” om snel een beeld te krijgen van de leerkrachtrooster.

Rechtermuisklikacties in “Opdrachten | Optimalisatie | Selectie” – Rechterpaneel

Nog een aantal voorbeelden

Bij het verbeteren van BN zien we dat KaMa er wat op achteruit gegaan is (-5,2 punten).

Op het eerste zicht moet het mogelijk zijn om in het KaMa rooster wat halve dagen vrij te rooster. We vragen om 3 blokken van 4 uur vrij te roosteren voor KaMa:

We drukken op “Plan” en bekijken het resultaat.

In het rooster kan men mooi zien hoe die 3 blokken 3 extra halve dagen vrijgeroosterd hebben voor KaMa.

Proberen we nog een extra BL4 bij te roosteren, dan blijkt dat niet te lukken. Van de 4 blokken zijn er maar 75% (3) gerealiseerd. Om dat 4de blok niet telkens opnieuw te proberen bij volgende iteraties zetten we het aantal weer op 3.

Vervolgens proberen we 2 andere leerkrachten te verbeteren: VV en KW:

voor KW proberen we 1 BL4 en 2 BL2
voor VV proberen we 2 BL4

Wordt als volgt toegevoegd:

We drukken op “Plan” en bekijken het resultaat:

Voor VV is alles gelukt, voor KW is de BL4 niet gelukt.

We kunnen als alternatief voor KW meer blokken van het type BL2 trachten te plaatsen. Drukken we vervolgens op “Plan” dan is dit het resultaat.

Merk op dat door deze actie niet alleen KW er met 4,3 punten op verbeterd is, maar ook MVD en JDBL hebben een beter rooster als neveneffect. KG en SS zijn er dan weer op achteruit gegaan.

Tenslotte bekijken we leerkrachten NDM, EV en HVDB.

NDM kan zeker 2 BL4 blokken gebruiken. Misschien lossen we het probleem van dinsdag daarmee op.
EV heeft een vrij goed rooster, maar om dit veilig te stellen kunnen we er preventief wat BL4 blokken in plaatsen.
HVDB heeft maar 1 uur op donderdag. Dat kunnen we misschien wegwerken door 2 BL4 blokken te plaatsen.

Invoer als volgt en resultaat na het drukken op “Plan”.

Resultaat in de visualizer:

NDM is er zeker op vooruit gegaan omdat hij dinsdagochtend niet meer moet komen voor 1 uur. De namiddag is nog een probleem.
EV heeft een zeer compact rooster gekregen.
HVDB is verlost van het geïsoleerde uurtje op donderdag.

Nog enkele tips en weetjes

Voldoening: een rooster kan didactisch in orde zijn met de wensen van de leerkrachten vervuld. Echter, na die stap zijn er nog heel wat mogelijkheden om de kwaliteit te verbeteren. Het is aan het roosterteam om hier ook de nodige aandacht aan te schenken. Het loont de moeite.
Geen eindpunt: na het optimaliseren kan men nog steeds het rooster naar believen aanpassen. Als men de optimalisatieopdrachten weer uitschakelt, verdwijnen ze uit het rooster, maar hun effecten blijven achter. Brengt men vervolgens wijzigingen aan, dan kan de kwaliteit van een aantal roosters weer verminderd zijn. Men kan steeds weer terug optimaliseren.
Tijdelijkheid: optimalisatieopdrachten moeten gezien worden als blokken die tijdelijk in het rooster geduwd worden om te compacteren, maar hebben verder geen functie en kunnen perfect weer uit het rooster verdwijnen.
Roosterrapport: wensen en optimalisatieopdrachten worden nooit getoond in roosterrapporten.

Verder zal time-tech nog investeren in een betere bepaling van de roosterkwaliteit voor leerkrachten. Ook een verdere automatisering van het optimalisatieproces is niet uitgesloten.

Analyseren van opdrachten

Peter — Sat, 28 Oct 2017 20:58:42 +0000

Analyseren van opdrachten

Het plannen van een rooster gaat vaak gepaard met het onderzoeken van strijdige stelsels van opdrachten en beperkingen, of meer algemeen, van knelpunten in het rooster waardoor een oplossing erg moeilijk wordt. Als er niet genoeg “zuurstof” in de opdrachten en beperkingen zit, kan het soms zoeken zijn naar een speld in een hooiberg. We moeten niet alleen aandacht besteden aan strijdige stelsels, maar ook aan knelpunten die het roosteren erg bemoeilijken.

De MBE kan strijdige stelsels niet zelf oplossen en dit leidt vaak tot frustratie bij de gebruiker omdat deze niet weet waar het probleem vandaan komt. Mondriaan heeft wel een aantal tools die kunnen helpen bij het opsporen van strijdigheden in het systeem. Plant men alle opdrachten en komt de MBE niet tot een oplossing (opdrachten falen), of niet snel genoeg, dan is de vraag waaraan dit ligt niet makkelijk te beantwoorden, omdat er vaak erg veel opdrachten en beperkingen in het spel zijn.

De kunst bij het opsporen van dergelijke strijdigheden of knelpunten is het inzoomen op een zo klein mogelijke set van opdrachten en beperkingen waarbinnen het probleem zich voordoet. Indien men een bepaald vermoeden heeft vanwaar het probleem komt dan kan men met volgende tools al een eind komen:

Plan Selectie: men selecteert en plant een deel van de opdrachten om te zien of het probleem zich dan ook stelt.
Roosteropties: via de besproken roosteropties (Opties | Roosteren) kan men allerhande beperkingen globaal uitschakelen om te zien of de problemen zich dan nog voordoen.
Combinaties van beide technieken.

Via “Plan Selectie” kan men beginnen zoeken naar de kleinste set van opdrachten/beperkingen waarvoor het probleem zich voordoet om vervolgens de nodige relaxaties te doen in de opdrachten en beperkingen. Het zoeken naar die set is soms een lastig probleem op zich.

Mondriaan biedt een extra mogelijkheid om op een automatische manier naar die set van opdrachten te zoeken die problemen veroorzaken binnen de context van de roosteropties en MBE opties. De tool die hiervoor bestaat, vindt men in de toolbar onder “Start | Plannen | Analyseer Opdrachten“.

Via deze tool kan de gebruiker de grenzen bepalen waarbinnen Mondriaan combinaties van opdrachten gaat onderzoeken (=proberen te plannen). Het onderzoeken van de deelverzamelingen gebeurt door telkens die deelverzameling aan de MBE aan te bieden en te zien of er binnen de context van de Rooster en MBE Opties tot een oplossing gekomen wordt. Alle deelverzamelingen waarvoor dit niet lukt, worden dan aan de gebruiker getoond zodat men op basis van deze strijdige deelverzamelingen verder kan inzoomen op het probleem.

Inhoud

Analyseren is (veel) deelverzamelingen van opdrachten afzonderlijk proberen
- Combinaties van elementen maken i.p.v. van combinaties van opdrachten
- Combinaties worden geprobeerd van klein naar groot
Context waarbinnen de analyse gebeurt
- Opties voor het roosteren
- Opties voor de MBE
Openen van de analysetool
Overlopen van enkele “Analyseer opdracht” technieken
Analyseer Individueel
Behouden van de gegevens van een Analyseer Opdrachten
Locatie van tekstbestanden die de MBE aanmaakt bij Analyseer opdrachten
Extra analysebestanden met statistieken over de uitgevoerde analyse

Analyseren is (veel) deelverzamelingen van opdrachten afzonderlijk proberen

De manier waarop we via deze tool problemen trachten op te sporen is door steeds andere combinaties van opdrachten aan te bieden aan de MBE. Als je maar alle mogelijke combinaties van opdrachten naar de MBE stuurt, zal er uiteindelijk wel de kleinste combinatie uitkomen die strijdig is of een knelpunt vormt. En daar zit nu het probleem, we kunnen onmogelijk alle combinaties van opdrachten aanbieden omdat dat veel te lang zou duren. Om een idee te geven van wat het bijvoorbeeld zou betekenen indien we in totaal 10 opdrachten zouden hebben dan kunnen we volgende combinaties van opdrachten naar de MBE sturen:

1 opdracht sturen: 10 combinaties (1 opdracht uit 10 opdrachten)
2 opdrachten sturen: 45 combinaties (2 opdrachten uit 10 opdrachten)
3 opdrachten sturen: 120 combinaties (3 opdrachten uit 10 opdrachten)
4 opdrachten sturen: 210 combinaties (4 opdrachten uit 10 opdrachten)
5 opdrachten sturen: 252 combinaties (5 opdrachten uit 10 opdrachten)
6 opdrachten sturen: 210 combinaties (6 opdrachten uit 10 opdrachten)
7 opdrachten sturen: 120 combinaties (7 opdrachten uit 10 opdrachten)
8 opdrachten sturen: 45 combinaties (8 opdrachten uit 10 opdrachten)
9 opdrachten sturen: 10 combinaties (9 opdrachten uit 10 opdrachten)
10 opdrachten sturen: 1 combinaties (10 opdrachten uit 10 opdrachten)

Dat zijn opgeteld 1.023 combinaties voor maar 10 opdrachten. Voor 11 opdrachten zouden dat er al 2.047 zijn. Als men enkele duizenden opdrachten heeft, kan men zich voorstellen dat alles uittesten absoluut geen optie is.

Er moeten dus keuzes gemaakt worden over welke beperkte combinaties we aan de MBE zullen aanbieden om een analyse van de opdrachten te doen. Een eerste oplossing om de combinaties te beperken is door met combinaties van elementen te werken in plaats van met combinaties van individuele opdrachten.

Combinaties van elementen maken i.p.v. van combinaties van opdrachten

Een eerste manier om combinaties te beperken vertrekt niet van een combinatie van individuele opdrachten, maar combineert elementen en selecteert voor die combinaties van elementen de overeenkomstige opdrachten. Meestal ontstaat een strijdig stelsel toch vanuit een resource waar teveel beperkingen voor bestaan indien we die resource plannen in combinatie met de opdrachten van één of meerdere andere resources. Dus, selecteer je bijvoorbeeld alle opdrachten van klas 1A (bv 25) en plan je die, dan kan het zijn dat het rooster van 1A perfect opgelost wordt. Hetzelfde kan gelden voor de opdrachten van een klas 1B (bv 25). Neem je vervolgens alle opdrachten van 1A en 1B samen (bv 40 omdat ze gedeeltelijk samen zitten en dus gemeenschappelijke opdrachten hebben) dan kan het zijn dat het plots niet meer lukt. Het feit dat 1A en 1B samen een knelpunt vormen, is erg nuttige informatie. Op basis hiervan kan de gebruiker gemakkelijk op zoek gaan naar de reden van het knelpunt, omdat het over een beperkte set aan opdrachten gaat (40 in dit voorbeeld). Op basis van die 40 kan men dan verder inzoomen tot men het probleem ofwel in de opdrachten, ofwel in de spreidingen of andere beperkingen gevonden heeft.

Stel dat we 10 opdrachten hebben voor de elementen A, B en C. Stel dat we dan volgende verdeling hebben over die 10 opdrachten:

A zit in 6 van de 10 opdrachten
B zit in 8 van de 10 opdrachten
C zit in 4 van de 10 opdrachten

A, B, en C zullen in die 10 opdrachten in bepaalde combinaties samenzitten. Bijvoorbeeld:

A en B samen in 4 van de 10 opdrachten
B en C samen in 4 van de 10 opdrachten
A en C niet samen

Als we nu alle combinaties van elementen gaan maken om te analyseren komen we bijvoorbeeld tot volgende beperkte set van 7 combinaties:

(A): 6 opdrachten
(B): 8 opdrachten
(C): 4 opdrachten
(A, B): 10 opdrachten (6 + 8 – 4 overlap)
(A, C): 10 opdrachten (6 + 4)
(B, C): 8 opdrachten (8 + 4 – 4 overlap)
(A, B, C): 10 opdrachten

Elk van deze 7 combinaties kan naar de MBE gestuurd worden om te plannen. Van zodra een combinatie niet gepland kon worden, kan de gebruiker hier verder op inzoomen. De MBE hoeft ook niet alle combinaties te proberen. Als bijvoorbeeld de combinatie (A) faalt, dan heeft het verder geen zin om de combinatie (A,B) te testen. Of als (A,C) faalt heeft het geen zin om (A,B,C) te testen. Dus, tijdens de analyse kan Mondriaan beslissen om een grotere combinatie niet meer te proberen omdat een deelverzameling ervan al faalde.

Door combinaties van elementen te nemen, reduceren we het aantal te testen opdrachtcombinaties al drastisch, maar er blijven nog veel te veel elementencombinaties mogelijk. Om het aantal te testen elementencombinaties verder te verkleinen biedt Mondriaan aan de gebruiker een aantal opties aan. Via deze opties heeft men invloed op volgende vragen:

Welke elementen kunnen in combinaties voorkomen?
Hoe groot mogen de combinaties van elementen zijn?
Welke types van elementen mogen samen in een combinatie voorkomen?
Kunnen we nog extra voorwaarden stellen opdat een combinatie weerhouden wordt?

Gosso modo delen we de methodes in volgens de Groepen methode en de Cluster methode. Voor elk van deze 2 methodes leggen we uit hoe deze 4 vragen beantwoord worden.

Volgende tabel geeft een overzicht van de mogelijkheden:

	Groepen-methode	Cluster-methode
1. Elementen die kunnen voorkomen in combinaties?	Opsomming van elementen (Filter veld) door gebruiker. Dit zijn de enige elementen die in combinaties kunnen voorkomen.	Opsomming van elementen (Filter veld) door gebruiker. Dit is enkel het startpunt. Via de cluster-detectie-methode worden hier nog extra elementen aan toegevoegd. (zie verder).
2. Grootte van de elementencombinaties?	Men geeft de minimale (Clustergrootte vanaf veld) en maximale grootte (Tot en met veld) op van combinaties de getest mogen worden.	Zelfde manier
3. Types van elementen die gecombineerd mogen worden?	Alle elementen kunnen met elkaar gecombineerd worden, onafhankelijk van het type. Een klas samen met een lokaal kan dus perfect.	Per combinatie zijn de types van de elementen gelijk. Een klas met een lokaal kan dus niet. Meer nog, de enige types waarvoor combinaties gemaakt worden zijn ook types die in het Filter voorkomen.
4. Extra beperkingen op de combinaties?	keuze: Combinatie bestaat in Cluster? veld (zie verder) keuze: Combinatie delen een resource? veld (zie verder)	Enkel combinaties die in een getypeerde cluster bestaan worden weerhouden. (zie verder)

Een aantal concepten uit deze tabel moeten nog uitgelegd worden. We zullen hiervoor af en toe gebruik maken van dit kleine artificiële voorbeeld met 3 opdrachten (ID’s 0, 1, 2). We hebben de elementen A, B, R1, …, R6. We hebben 2 types elementen: klassen en leerkrachten.

Rechts een visuele voorstelling die kan helpen bij het begrijpen van de voorbeelden.

Stel dat we A, R1, R2 opgeven als Filter elementen voor de analyse. We stellen ook dat we combinaties van 1 of 2 elementen wensen door te geven aan de MBE om te testen (plannen). Laat ons met die instelling de methoden Groepen en Clusters bekijken.

Groepen-methode

Combinaties van 1 element en combinaties van 2 elementen waarbij de types door elkaar gebruikt mogen worden. Dat levert volgende mogelijkheden op waarbij we meteen ook weergeven welke opdrachten (ID’s) geselecteerd zullen worden voor elk van de combinaties:

Combinaties van 1:

(A) ⇒ 0, 2
(R1) ⇒ 0, 1
(R2) ⇒ 1

Combinaties van 2:

(A, R1) ⇒ 0, 1, 2
(A, R2) ⇒ 0, 1, 2
(R1, R2) ⇒ 0, 1

Zonder verdere beperkingen zullen dit de 6 combinaties zijn die we een voor een naar de MBE sturen. Merk op dat we vanwege het kleine voorbeeld we vaak dezelfde opdrachten zullen selecteren. De eerste 2 combinaties leveren inderdaad exact dezelfde opdrachten op.

Cluster-methode

Bij de cluster methode worden de opgegeven filterelementen niet rechtstreeks gebruikt om er combinaties van 2 van te maken. Hier komen we op de vermeldde cluster-detectie-methode om de te gebruiken elementen te bepalen en om te bepalen welke combinaties er gemaakt mogen worden.

Wat is een Cluster in deze context? Als je een opdracht bekijkt, zijn de clusters de groepjes elementen van die opdracht die van hetzelfde type zijn. We kunnen in de 3 opdrachten volgende clusters onderscheiden:

ID0: (A) en (R1)
ID1: (R1, R2, R3)
ID2: (A, B) en (R4, R5, R6)

De cluster-detectie-methode start van de elementen uit de filter (A, R1, R2). De methode zoekt eerst alle opdrachten die iets met de elementen in de filter te maken hebben. In dit geval zijn dat alle opdrachten. Van deze nemen we alle clusters:

(A), (R1), (R1, R2, R3), (A, B), (R4, R5, R6)

Enkel combinaties met elementen uit deze clusters zijn mogelijk. Sterker nog, als je een combinatie van 2 elementen maakt mag dat enkel indien ze ook samen in een cluster zitten. Dit slaat op de impliciete extra beperking die geldt voor de Cluster methode (vraag 4: Extra beperkingen op de combinaties?). Passen we die logica toe dan krijgen we volgende combinaties van 1 en 2:

Combinaties van 1:

(A) ⇒ 0, 2
(B) ⇒ 2
(R1) ⇒ 0, 1
(R2) ⇒ 1
(R3) ⇒ 1
(R4) ⇒ 2
(R5) ⇒ 2
(R6) ⇒ 2

Combinaties van 2:

(A, B) ⇒ 0, 2
(R1, R2) ⇒ 0, 1
(R1, R3) ⇒ 0, 1
(R2, R3) ⇒ 1
(R4, R5) ⇒ 2
(R4, R6) ⇒ 2
(R5, R6) ⇒ 2

Wat bijvoorbeeld niet kan is (A, R1) omdat ze niet in 1 cluster kunnen zitten, omdat ze niet van hetzelfde type zijn. Wat ook niet kan is (R1, R4) omdat ze niet in dezelfde cluster zitten.

Opnieuw de opmerking dat we vanwege dit kleine voorbeeld voor meerdere combinaties dezelfde opdrachten selecteren.

Men ziet nu duidelijk het verschil tussen de elementen die gebruikt worden en de manier waarop de combinaties samengesteld worden tussen beide methodes.

Wat met cluster-detectie-methode in het geval dat er keuzeresources zijn? Stel dat leerkrachten R1, R2, R3 in opdracht ID1 keuzeresources zouden zijn. In dat geval moet de opdracht een van de resources kiezen en kunnen ze niet samen geplaatst worden. Dat heeft ook een belangrijke impact op de clusters die bekeken worden. We zouden dan volgende clusters krijgen:

ID0: (A) en (R1)
ID1: (R1) en (R2) en (R3)
ID2: (A, B) en (R4, R5, R6)

Dit zou nu geen invloed hebben op de combinaties van 1 maar wel op die van 2. De resulterende combinaties van 2 zouden de volgende zijn:

(A, B) ⇒ 0, 2
(R4, R5) ⇒ 2
(R4, R6) ⇒ 2
(R5, R6) ⇒ 2

Stel dat er 2 groepen van keuzelokalen zouden zijn in 1 opdracht, eentje van 2 en eentje van 3 lokalen. In dat geval willen we dus 2 lokalen laten kiezen. Bijvoorbeeld keuze uit (L1, L2) samen met een keuze uit (L2, L3, L4) in dezelfde opdracht (met bv 1 lokaal in beide keuzegroepen). Op dat moment worden de clusters gevormd door enkel de mogelijke combinaties:

(L1, L2) en (L1, L3) en (L1, L4) en (L2, L3) en (L2, L4)

Extra beperkingen op de combinaties voor de Groepen methode

Voor vraag 4 in het geval van Groepen hebben we nog 2 beperkende voorwaarden die nog uitgelegd moeten worden. Zonder die extra voorwaarden laten we alle gevonden combinaties toe. Elk van deze beperkende voorwaarden gaat uit van combinaties die minstens grootte 2 hebben. De combinaties met 1 element vallen er dan sowieso uit.

Volgende extra beperkingen zijn mogelijk:

Combinatie bestaat in cluster: De combinatie wordt enkel weerhouden als ze effectief in minstens één opdracht voorkomt (met cluster bedoelen we hier alle elementen uit de opdracht, ongeacht hun type). Door deze beperking op te leggen is men zeker dat de elementen in de combinatie elkaar beïnvloeden tijdens het plannen. Ze worden samen door minstens een opdracht in het rooster geplaatst. Dan weet je dat er een koppeling is en het dus de moeite is om ze samen te testen.

(A, R1) komt voor in ID0.
(A, R2) komt nergens voor en zal dus niet weerhouden worden.

Passen we deze regel toe op de combinaties die we eerder bepaalt hebben voor Groepen dan resulteert dit in:

Combinaties van 1:

~~(A)~~
~~(R1)~~
~~(R2)~~

Combinaties van 2:

(A, R1) ⇒ 0, 1, 2
~~(A, R2)~~
(R1, R2) ⇒ 0, 1

Combinatie delen een resource: Een combinatie wordt weerhouden indien er een willekeurige (niet-keuze) element bestaat (verschillend van de elementen in de combinatie) die via willekeurige opdrachten (meer dan 1) met elk van de elementen uit de combinatie verbonden is. Ook door deze beperking op te leggen is men zeker van een koppeling tussen de elementen van de combinatie. De koppeling is minder direct dan bij “De combinatie moet in een opdracht bestaan”, het is een aan de combinatie extern element dat een koppeling tussen de elementen van de combinatie veroorzaakt.

Passen we deze regel toe op de combinaties die we eerder bepaald hebben voor Groepen dan resulteert dit in:

Combinaties van 1:

~~(A)~~
~~(R1)~~
~~(R2)~~

Combinaties van 2:

~~(A, R1)~~
(A, R2) ⇒ 0, 1, 2
~~(R1, R2)~~

Beide voorwaarden samen aanvinken:

Indien men beide opties samen kiest dan krijgt men de unie van beide keuzes. Je gaat dan zowel de sterke als de zwakkere koppelingen tussen de elementen van de combinatie aanvaarden als reden om ze mee te nemen.

De resulterende combinaties zijn dan de volgende:

Combinaties van 1:

~~(A)~~
~~(R1)~~
~~(R2)~~

Combinaties van 2:

(A, R1) ⇒ 0, 1, 2
(A, R2) ⇒ 0, 1, 2
(R1, R2) ⇒ 0, 1

Nog een voorbeeld om de verschillen aan te tonen

We hernemen het voorbeeld en gebruiken nu volgende elementen uit de 3 opdrachten in de filter: A, B, R1, R2, R4, R5. We kiezen combinaties van grootte 1 tot 2 en we bekijken dit voor volgende 5 instellingen:

Groepen Methode: Geen bijkomende voorwaarden
Groepen Methode: Combinatie bestaat in opdracht
Groepen Methode: Combinatie delen een resource
Groepen Methode: Combinatie bestaat in opdracht of Combinatie delen een resource
Cluster Methode

We tonen nogmaals de 3 eenvoudige opdrachten en al een preview van het optiescherm waarmee we de analyseparameters bepalen:

Afhankelijk van de 5 instellingen toont volgende tabel de resulterende combinaties die naar de MBE gestuurd zullen worden.

1. Groepen: Geen beperking

2. Groepen: Bestaat in opdracht

3. Groepen: Delen een resource

4. Groepen: Beide beperkingen

5. Cluster

(A)
(B)
(R1)
(R2)
(R4)
(R5)
(A, B)
(A, R1)
(A, R2)
(A, R4)
(A, R5)
(B, R1)
(B, R2)
(B, R4)
(B, R5)
(R1, R2)
(R1, R4)
(R1, R5)
(R2, R4)
(R2, R5)
(R4, R5)

~~(A)~~
~~(B)~~
~~(R1)~~
~~(R2)~~
~~(R4)~~
~~(R5)~~
(A, B): in 2
(A, R1): in 0
~~(A, R2)~~
(A, R4): in 2
(A, R5): in 2
~~(B, R1)~~
~~(B, R2)~~
(B, R4): in 2
(B, R5): in 2
(R1, R2): in 1
~~(R1, R4)~~
~~(R1, R5)~~
~~(R2, R4)~~
~~(R2, R5)~~
(R4, R5): in 2

~~(A)~~
~~(B)~~
~~(R1)~~
~~(R2)~~
~~(R4)~~
~~(R5)~~
~~(A, B)~~
~~(A, R1)~~
(A, R2): delen R1
~~(A, R4)~~
~~(A, R5)~~
(B, R1): delen A
~~(B, R2)~~
~~(B, R4)~~
~~(B, R5)~~
~~(R1, R2)~~
(R1, R4): delen A
(R1, R5): delen A
~~(R2, R4)~~
~~(R2, R5)~~
~~(R4, R5)~~

~~(A)~~
~~(B)~~
~~(R1)~~
~~(R2)~~
~~(R4)~~
~~(R5)~~
(A, B): in 2
(A, R1): in 0
(A, R2): delen R1
(A, R4): in 2
(A, R5): in 2
(B, R1): delen A
~~(B, R2)~~
(B, R4): in 2
(B, R5): in 2
(R1, R2): in 1
(R1, R4): delen A
(R1, R5): delen A
~~(R2, R4)~~
~~(R2, R5)~~
(R4, R5): in 2

(A)
(B)
(R1)
(R2)
(R3)
(R4)
(R5)
(R6)
(A, B)
(R1, R2)
(R1, R3)
(R2, R3)
(R4, R5)
(R4, R6)
(R5, R6)

Anders gekleurde zijn combinaties die niet kunnen voorkomen bij Groepen.

6 Combinaties van 1
15 Combinaties van 2

8 Combinaties van 2

4 Combinaties van 2

12 Combinaties van 2

8 combinaties van 1
7 combinaties van 2

Welke methode gebruiken?

Strikte regels kunnen niet gegeven worden maar deze inzichten kunnen wel helpen in de keuzes:

Groepen Methode: Geen bijkomende voorwaarden: Het aantal combinaties neemt exponentieel toe met het aantal elementen in de filter en met de grootte van de gevraagde combinaties. Men zal al snel merken wanneer dit niet langer houdbaar is. Voor kleine combinaties (bv max 2) is het zeker nog doenbaar met niet teveel elementen. Heeft men bijvoorbeeld 100 elementen dan heeft men met combinaties van 2 toch al snel 4.950 combinaties van 2. Heeft men 100 elementen en vraagt men combinaties van 3 dan zijn dat er al 161.700 combinaties van 3 die een voor een naar de MBE gestuurd worden. Dit is niet doenbaar. Deze methode houdt dan ook weinig rekening met de effectieve verbanden tussen de elementen in de combinatie.
Groepen Methode: Combinatie bestaat in opdracht: Door te eisen dat de elementen van de combinatie ook samen in minstens 1 opdracht voorkomen gaat men het aantal combinaties uit 1 al sterk verminderen. Men limiteert de combinaties door een sterke vorm van koppeling te eisen tussen de elementen.
Groepen Methode: Combinatie delen een resource: Door te eisen dat alle elementen van de combinatie door minstens een ander extern element beperkt worden gaat men het aantal combinaties uit 1 sterk verminderen. We kunnen dit een zwakke koppeling tussen de elementen noemen. Echter, ook dergelijke koppelingen kunnen de plaatsing van het geheel onmogelijk maken. Men limiteert de combinaties door een zwakke koppeling te eisen tussen de elementen.
Groepen Methode: Combinatie bestaat in opdracht of Combinatie delen een resource: Hier gaat men meteen met de sterke en de zwakke koppelingen tegelijk rekening houden. Geeft uiteindelijk hetzelfde resultaat als ze apart proberen.
Cluster Methode: Dit is de meest complexe methode met als doel zo verstandig mogelijk zo weinig mogelijk combinaties uit te proberen. Hier wordt de harde koppeling tussen de elementen van de te testen combinaties impliciet afgedwongen. Mondriaan gaat op basis van de filterelementen die de gebruiker opgeeft (liefst niet te veel) en de clusters in de opdrachten er ook andere elementen bij betrekken die er iets mee te maken zouden kunnen hebben. Vertrekkende van deze slimme set van elementen worden de combinaties dan gevormd. Men gaat merken dat als een combinatie niet lukt tijdens het plannen dat het kan zijn dat er in die combinatie elementen voorkomen die de gebruiker niet vermeld had in de filter.

Per rooster moet men wat ervaring opdoen om te zien wat het best werkt om problemen op te sporen. We geven hier een aantal tools die dat mogelijk maken zonder harde regels op te leggen.

Combinaties worden geprobeerd van klein naar groot

Van zodra Mondriaan alle te evalueren combinaties opgelijst heeft, wordt geprobeerd ze te plannen (door MBE) in volgorde van klein naar groot (grootte = aantal elementen). Vermits de gebruiker kan opgeven wat de minimale en maximale grootte is, worden ook enkel combinaties die hier aan voldoen weerhouden.

Eerst worden de kleinste combinaties geprobeerd. Voor elk van deze combinaties weet Mondriaan na de test of het een succes was of niet. Stel dat Mondriaan de combinaties van grootte 2 geprobeerd heeft en vaststelt dat combinatie (P,Q) niet succesvol was. In een volgende stap, bij het evalueren van combinaties van grootte 3 gaat Mondriaan alle combinaties van 3 die ook (P,Q) bevatten al schrappen. De combinatie (A,P,Q) wordt dus niet geprobeerd. Dat is immers niet zinvol omdat we al vastgesteld hebben dat (P,Q) niet lukt.

Mondriaan gaat systematisch alle weerhouden combinaties van klein naar groot testen en na elke set (per grootte) eerst een schrapping doen van combinaties uit grotere sets. Op die manier beperken we ook weer het aantal combinaties dat in de analyse moet bekeken worden.

Verder in deze pagina wordt nog uitgelegd waar alle instellingen kunnen gebeuren om deze analyses te doen.

Context waarbinnen de analyse gebeurt

De tool “Analyseer opdrachten” werkt, net zoals “Plan” of “Plan Selectie”, binnen een context van een basisselectie van opdrachten (via elementen) en de settings in volgende gekende optietabbladen:

Opties voor het roosteren
Opties voor de MBE

Opties voor het roosteren

Opties voor het roosteren (Opties | Roosteren): Hier zijn de meeste opties relevant voor “Analyseer opdrachten”.

Bijkomende opdrachtselectie: Voor elke combinatie van elementen die geanalyseerd moet worden, worden eerst de opdrachten geselecteerd op de manier die hiervoor beschreven werd. Aan deze opdrachten worden vervolgens nog extra opdrachten toegevoegd zoals gesteld in “Bijkomende opdrachtselectie”. Deze volledige set van opdrachten zal naar de MBE gestuurd worden.
Bijkomende leerkrachtspecifieke opdrachtselectie: Ook de wensen kunnen aan elke combinatie toegevoegd worden. “Optimalisatie” heeft hier geen zin en gebruiken we niet. Er zijn 3 mogelijkheden voor de wensen:
- Men neemt ze niet mee in de analyse.
- Men neemt alle wensen van alle leerkrachten steeds mee voor elke combinatie die geanalyseerd wordt.
- Men neemt per combinatie enkel de wensen mee van de leerkrachten die expliciet geselecteerd worden in de combinatie.
Algemene beperkingen: Ook deze worden meegenomen in de analyse van elke combinatie.
Opdrachtelementen al dan niet mee te nemen tijdens het roosteren: Ook aan deze voorwaarden wordt voldaan tijdens de analyse. Merk op dat het niet is omdat we bijvoorbeeld “Klassen meeroosteren” uitvinken dat het systeem van het vormen van combinaties op basis van klassen niet meer zou werken. Dit staat los van elkaar. Selecties en het maken van combinaties worden niet beïnvloed door deze settings. Enkel als de opdrachten naar de MBE gestuurd worden zal deze de instructie krijgen om niet naar de klassen te kijken tijdens het zoeken naar een oplossing.
ZR-Link/Bloklink constructie: ook hier van toepassing.

Opties voor de MBE

Opties voor de MBE (Opties | Engine): vooral de opties i.v.m. kennis vergaren en de te gebruiken methode zijn hier van belang.

Enkel de eerste 2 blokken uit dit optietabblad zijn ook relevant voor “Analyseer opdrachten”. Zie algemene pagina over dit thema.

Enkele vrijblijvende tips over deze opties

Indien men kleine deelverzamelingen van opdrachten en beperkingen gaat analyseren:

kan het nuttig zijn om lagere zoekdieptes te gebruiken. Gebruikt men bijvoorbeeld zoekdiepte 3 voor het volledige rooster dan kan men voor de analyse bijvoorbeeld zoekdiepte 2 gebruiken. Als een klein deelprobleem niet of moeilijk op te lossen is op zoekdiepte 2 maakt dit deelprobleem misschien weinig kans om opgelost te worden binnen de context van het volledige rooster op diepte 3.
zouden deze opdrachten misschien oplosbaar moeten zijn met Methode 1. Dezelfde redenering geldt als voor de zoekdiepte. Een klein probleem zou oplosbaar moeten zijn met de eenvoudige Methode 1.
zouden deze opdrachten misschien oplosbaar moeten zijn zonder kennis te vergaren.

Dit is echter een kwestie van keuze en ervaring. Men kan ook gewoon de instellingen gebruiken die men gebruikt tijdens het roosteren.

Openen van de analysetool

Via het menu “Start | Plannen | Analyseer opdrachten” start men de analysetool op. Eerst wordt een kleine popup getoond met de gekozen MBE opties voor het plannen van de combinaties.

Drukt men op OK, dan komt men in de analysetool:

Ter voorbereiding van de analyse kan men volgende instellingen doen in dit scherm:

Filter: In het veld “Filter” kan men een selectie maken van elementen (en elementgroepen) die gebruikt zullen worden om combinaties te maken. In het voorbeeld tonen we ook het “Wijzig selectie” scherm waarmee de elementen geselecteerd kunnen worden. Merk op dat het veld “Type” bepaalt wat in dit selectiescherm getoond wordt.
Type: Omdat er erg veel elementen zijn die in het veld “Filter” geselecteerd kunnen worden, kunnen we dit handig beperken door eerst een elementtype in te geven. Mogelijkheden zijn:
- Alle: bij deze keuze kan je in het Filter alle mogelijke elementen en groepen kiezen die er bestaan.
- Klassen: alle klassen en klasgroepen
- Leerkrachten: alle leerkrachten en leerkrachtgroepen
- Lokalen: alle lokalen en lokaalgroepen
- Vakken: alle vakken en vakgroepen
Clustergrootte vanaf: minimale grootte van de combinaties die getest moeten worden.
Tot en met: maximale grootte van de combinaties die getest moeten worden.
Clusters/Groepen: De keuze tussen de “Groepen” methode of de “Cluster” methode om op basis van de opgegeven elementen combinaties samen te stellen die getest moeten worden. Zie eerder in deze pagina voor een uitgebreide beschrijving van de verschillen tussen deze technieken.
Extra opties voor de “Groepen”-techniek:
- Combinatie bestaat in cluster: enkel combinaties weerhouden als die combinatie als cluster bestaat in minstens één willekeurige opdracht.
- Combinatie delen een resource: enkel combinaties weerhouden waarvan alle elementen met minstens één gemeenschappelijke resource in contact staan via willekeurige opdrachten. (zie eerder op deze pagina voor de uitleg.)
Stop na eerste gefaalde groep: indien men de analyse wenst te stoppen van zodra de MBE een gefaalde groep of cluster gevonden heeft dan kan men deze optie aanvinken. Vinkt men dit niet aan dan blijft Mondriaan de MBE aansturen tot alle gevraagde combinaties geprobeerd werden.

Knoppen:

Analyseer: start een analysesessie met de ingegeven parameters.
Reset: alle settings van het Analysescherm worden weer naar de default settings gezet. De inhoud van “Nodes” waar de probleemcombinaties opgelijst staan, wijzigt uiteraard niet. Verder onthoudt Mondriaan ook per Type de Filter-waarden die laatst gekozen werden. Had men als Type “Klassen” gekozen en als klassen A en B, dan zal dit na een reset onthouden blijven. Kiest men na Reset weer Klassen dan zal Filter gevuld zijn met A en B en kan de gebruiker hier mee verder werken of dit aanpassen.

Overlopen van enkele “Analyseer opdracht” technieken

In dit voorbeeld selecteren we 10 klassen van het 6de jaar. We kiezen vervolgens om te analyseren volgens de “Groepen”-techniek. Als minimale combinatie grootte kiezen we 1 en als maximale 3. Omdat er 10 klassen zijn kunnen we in het geval van “Groepen” de maximale grootte opdrijven tot 10 maar hier kiezen we 3. Verder hebben we in de optietabbladen “Opties | Roosteren” en “Opties | Engine” de standaardopties gekozen.

Drukken we vervolgens op “Analyseer”, dan krijgen we volgend beeld te zien tijdens de analyse. Het voortgangsscherm laat zien waarmee Mondriaan bezig is:

Parser: opstellen en doorsturen van de analyse input aan de MBE (klaar)
Engine: opstarten van de MBE met de analyseopdrachten (klaar)
1: Combinaties van 1 elementen worden geanalyseerd (klaar)
2: Combinaties van 2 elementen worden geanalyseerd (klaar)
3: Combinaties van 3 elementen worden geanalyseerd (bezig…)

Indien Mondriaan geen problemen gevonden heeft bij het analyseren van deze combinaties, krijgt men het volgende beeld te zien:

Opzoeken van knelpunten door de MBE minder zoekvrijheid te geven

We passen de opties in “Opties | Engine” aan op de volgende manier:

Hierdoor gaat de MBE veel minder “moeite” doen om naar een oplossing te zoeken voor elke combinatie die hij moet analyseren. Drukken we vervolgens opnieuw op de “Analyseer” knop in het Analyse scherm dan krijgen we volgend beeld te zien. Volgende 3 combinaties geven problemen binnen de huidige set aan parameters:

(6BO, 6HB)
(6CA, 6LC)
(6HT, 6IW, 6MT)

Een gefaalde combinatie gebruiken als filter voor bijvoorbeeld Plan Selectie

Selecteren we de eerste gefaalde combinatie (6BO,6HB), dan kunnen we er via een rechtermuisklik een filtercriterium van maken voor “uitgebreid zoeken” in het opdrachten tabblad. De actie “Maak filter” doet dat en navigeert dan ook meteen naar het opdrachten tabblad.

Indien we met deze selectie en dezelfde “Opties | Roosteren” en “Opties | Engine” als voor het analyseren van opdrachten (dus in dezelfde context) een “Plan Selectie” doen van deze selectie, dan zou het resultaat inderdaad moeten zijn dat het niet gepland kan worden. We voeren “Plan Selectie” uit:

Er is inderdaad 1 opdracht die in deze context niet geplaatst kon worden. Maar, omdat we in dit geval weten dat het zeker oplosbaar is als we bijvoorbeeld naar Methode 2 zouden overstappen, of kennis vergaren zouden aanzetten, is het gewoon een indicatie dat het een wat lastigere combinatie is. Merk op dat in dit voorbeeld de eerste 2 opdrachten waar “25% geroosterd” bij staat niet gaat over gefaalde opdrachten. Dit zijn 2 opdrachten waarvan een deel “vast” is en meegeroosterd werd. Het gaat om 1ste jaars. Enkel die 25% is dus mee naar de MBE gegaan. Voor ons gaat het hier vooral om die opdracht van 6HB die niet geplaatst werd.

Opgepast met de optie “Wensen per geselecteerde leerkracht (Analyse)”

“Plan selectie” maakt momenteel geen gebruik van deze optie. Enkel “Analyseer opdrachten” gebruikt die. Als “Wensen meeroosteren” aangevinkt is dan zal “Plan selectie” altijd ALLE leerkrachtwensen meenemen, onafhankelijk van de geselecteerde leerkrachten tijdens “Plan selectie”. Indien men dus een verschil ziet tussen de analyse van een combinatie en een Plan selectie van ogenschijnlijk dezelfde combinatie dan kan dat hier aan liggen.

Mocht er in de toekomst nood zijn om de optie “Wensen per geselecteerde leerkracht” ook van toepassing te laten zijn voor “Plan selectie” dan zullen we dat zeker aanpassen. Nu kan men trouwens ook hetzelfde effect bekomen door in het Wensen tabblad enkel de wensen actief te maken die men wenst te plannen.

Dubbelklik op een gefaalde combinatie toont de gefaalde opdrachten

In het Analyse scherm kan men dubbelklikken op een gefaalde combinatie. Dit opent een tekstbestand met de gefaalde opdrachten voor die combinatie. Voor de combinatie (6CA,6LC) gaat het om één gefaalde opdracht, een blok van 6 uur. In volgend beeld tonen we die gefaalde opdracht en op de achtergrond wordt ook meteen het resultaat getoond dat we bekomen hadden door een “Plan selectie” te doen met dezelfde gefaalde combinatie. Hier ziet men dus inderdaad dat een “Plan selectie” van dezelfde combinatie in dezelfde context exact hetzelfde resultaat geeft als wat de MBE als resultaat had bij “Analyseer opdrachten”.

Minder combinaties proberen door de “Cluster”-techniek

Herhalen we hetzelfde voorbeeld maar met de “Cluster”-techniek dan zien we in dit geval dat de maximale combinatiegrootte niet 10 is maar maximum 3. De reden is dat Mondriaan binnen de 10 geselecteerde klassen maximaal 3 elementen ziet die in eenzelfde opdracht voorkomen. We kiezen min 1 en max 3 en drukken op de “Analyseer” knop:

Dit is veel sneller klaar dan bij de “Groepen”-techniek. Wat onmiddellijk opvalt, is dat er maar 2 combinaties gevonden werden die een knelpunt vormen in de gestelde context. De reden hiervoor is dat de combinatie (6HT,6IW,6MT) nergens voorkomt als cluster in een opdracht. Deze combinatie van elementen werd dus ook niet geprobeerd. De andere 2 combinaties werden wel geprobeerd en komen er uit als knelpunten. Dat ze samen in opdrachten voorkomen kan men in het opdrachten tabblad duidelijk zien:

Teveel combinaties analyseren

Het is niet moeilijk om in te zien dat men zaken kan vragen die niet echt uitvoerbaar zijn. In theorie kan men bijvoorbeeld voor 100 elementen alle combinaties van grootte 1 tot 100 uitproberen. Dit is niet echt zinnig maar Mondriaan en de MBE zullen niet weigeren om dit uit te voeren. De gebruiker zal snel vaststellen dat hij iets gevraagd heeft wat onzinnig is. Het enige wat er dan opzit, is om de analyse af te breken. In dit voorbeeld hebben we de onmogelijke opdracht gegeven om van de 225 opgegeven elementen alle combinaties groottes uit te proberen van 1 tot 225. De enige manier om dit te stoppen is door op de knop “Annuleer” te klikken.

Drukt men op “Annuleer” dan stopt Mondriaan met het geven van instructies aan de MBE. Het kan echter zijn dat de MBE zelf niet stopt. Als dat het geval is, kan men de MBE zelf gewoon afbreken door op het klassiek kruisje te klikken rechtsboven in het blauwe scherm.

Analyse stoppen na eerst gefaalde groep

Wenst men de analyse te stoppen na de eerste faling die de MBE tegenkomt dan dat dat door de optie “Stop na eerste gefaalde groep” te kiezen. De MBE wordt dan afgebroken en krijgt de gebruiker de controle terug.

Analyseer Individueel

Een veelgebruikte techniek om te zien of het rooster op zijn meest elementaire manier al roosterbaar is, is om het rooster te maken van elke resource afzonderlijk. Kan men voor elke klas, elke leerkracht, elk lokaal, etc. de opdrachten gepland krijgen? Dat is het minste wat men kan verwachten alvorens men begint te roosteren. De tool “Analyseer opdrachten” leent zich uitstekend om dit te onderzoeken. Men selecteert de resources waarvoor men dit wenst te doen, men kiest de “Groepen”-techniek en men selecteert 1 voor zowel de minimale als de maximale combinatiegrootte.

In dit voorbeeld hebben we de standaardgroepen KLASSEN, LEERKRACHTEN, en LOKALEN geselecteerd. Dit kan enkel tegelijkertijd indien men als Type “Alle” gekozen heeft. Vervolgens drukken we op “Analyseer” om voor elke klas, elke leerkracht, en elk lokaal de opdrachten te selecteren en te roosteren. Uiteraard gebeurt dit ook weer binnen de gestelde context in “Opties | Roosteren” en “Opties | Engine”.

Na uitvoering krijg je bijvoorbeeld volgend beeld waarbij 2 klassen en 1 lokaal een probleem hebben. Opnieuw kan je dan via “Plan Selectie” gaan bekijken wat er mis is met deze individuele resources.

Behouden van de gegevens van een Analyseer Opdrachten

De gegevens van de laatste “Analyseer opdrachten” die te zien zijn in het “Analyse” scherm blijven beschikbaar zolang men ze niet overschrijft door een nieuwe Analyseer opdrachten actie. Ook als men het bestand bewaart en weer opent, blijven deze gegevens beschikbaar.

Het dubbelklikken op een gefaalde combinatie toont normaal een tekstdocument met daarin de gefaalde opdrachten. Deze tekstdocumenten blijven enkel tijdens de Mondriaan sessie beschikbaar. Van zodra men Mondriaan sluit, worden deze gegevens gewist.

Locatie van tekstbestanden die de MBE aanmaakt bij Analyseer opdrachten

De tekstbestanden die Mondriaan toont als men dubbelklikt op een gefaalde combinatie staan op volgende locatie:

Afhankelijk van de gebruiker (in dit geval “Peter”) moet men onder “Users” (of “Gebruikers”) in de juiste directory kijken. Onder “Mondriaan” vindt men de “Content” map. Daarbinnen wordt elke keer dat de MBE opgestart wordt, een cryptische foldernaam aangemaakt (in dit geval “17028dat2”). Onder deze folder staan subfolders en bestanden die de MBE aanmaakt. Onder “Selectie” kan men de “NG_*.txt” bestanden vinden die tijdens de analyse aangemaakt worden. De link tussen de gefaalde combinatie en het bestand kent alleen Mondriaan.

Extra analysebestanden met statistieken over de uitgevoerde analyse

Soms kan het nuttig zijn om van alle geanalyseerde combinaties, of ze nu slagen of niet binnen de gestelde context, te weten hoe ze zich verhouden tot de andere combinaties voor wat betreft hoe “lastig om op te lossen”. De MBE voorziet hiervoor per “grootte” van de geanalyseerde combinaties een analysebestand (“anafile”). Deze analysebestanden-files kan men op volgende locatie vinden:

Deze bestanden staan per datum gesorteerd, wat meteen betekent dat ze per grootte van de combinaties gesorteerd zijn. We openen het laatste bestand. Elke lijn stelt een combinatie voor die geanalyseerd werd. Het is duidelijk dat in dit bestand steeds combinaties van 4 elementen opgelijst zijn. We zien volgende kolommen:

Pogingen: geeft een idee van het aantal “pogingen” die de MBE heeft uitgevoerd om de opdrachten van een bepaalde combinatie te plaatsen.
geplaatste: aantal geplaatste opdrachten
Totaal: totaal aantal aangeboden opdrachten voor de combinatie van elementen
Percentage: percentage geplaatste opdrachten (geplaatst tov totaal)
Selectie: de selectiecriteria om opdrachten te selecteren voor de combinatie

We kunnen opmaken uit de kolom “Selectie” dat buiten de 4 elementen nog andere opdrachten geselecteerd werden. Zo zien we volgende indicaties:

“SYS_VAST”: vaste opdrachten worden mee geselecteerd
“openingen”: vensters worden mee geselecteerd
“WENS”: alle leerkrachtwensen worden mee geselecteerd

Dit is het resultaat van de standaardopties bij “Opties | Roosteren”. Kiest men andere opties dan zullen er ook andere indicatoren instaan.

Interessant aan dit bestand is dat het “tab gescheiden” is en dat men het ook eenvoudig kan openen in bijvoorbeeld Excel. Vervolgens kan men de gegevens gemakkelijk sorteren op “Pogingen” waardoor men een goed zicht krijgt op de lastige combinaties. Een voorbeeld hiervan:

Na openen in Excel en omgekeerd sorteren op “Pogingen”, krijgen we zicht op de lastige combinaties van 4 elementen. Voor de opdrachten van de eerste 2 combinaties zien we dat er ook telkens een opdracht gefaald is. Het is logisch dat die dan ook hoog gesorteerd staan. Men ziet ook een duidelijke sprong in het aantal pogingen.

Deze informatie is niet onmiddellijk beschikbaar in Mondriaan zelf, maar de geïnteresseerde gebruiker kan de informatie hier vinden en het kan soms nuttig zijn om een beeld te krijgen van lastige combinaties als men moeilijk oplosbare problemen onderzoekt.

Diagnose en Diagnose selectie

Peter — Sat, 28 Oct 2017 20:57:26 +0000

Diagnose en Diagnose selectie

De MBE (Mondriaan Backtrack Engine) kan een diagnosebestand genereren voor de opdrachten die men naar de MBE stuurt. Net zoals voor “Plan” en “Plan selectie” kan ook de diagnose voor alle te roosteren opdrachten of enkel voor de geselecteerde opdrachten gebeuren. Merk op dat “diagnose” een faciliteit is die in de MBE ingebouwd zit en vooral zijn dienst bewezen heeft in de oudere versies van het lessenroosterprogramma. De meeste informatie die men uit de diagnose kan halen is ook beschikbaar binnen de Mondriaanschermen. Sommige diagnose-informatie is niet in de Mondriaanschermen beschikbaar en kan nuttig zijn bij de analyse van problemen.

De knoppen om beide vormen van diagnose op te starten vindt men in het menu “Start | Plannen”.

Het diagnosebestand geeft volgende informatie:

resources en hun bezetting: hier kan men zien of een resources niet teveel of te weinig ingepland is.
koppelingen tussen resources: hier kan men bijvoorbeeld zien welke leerkracht in welke klassen lesgeeft en voor hoeveel uren.
resources en hun opdrachten: overzicht van elke opdracht per resource
resources en hun moeilijkheidsgraad binnen de context van de opdrachten

Inhoud

Opties voor “Plan” en “Plan selectie” gelden ook voor “Diagnose” en “Diagnose selectie”
Starten van de diagnose
Informatie in het diagnosebestand

Opties voor “Plan” en “Plan selectie” gelden ook voor “Diagnose” en “Diagnose selectie”

Alle opties die gelden voor “Plan” en “Plan selectie” gelden ook voor “Diagnose” en “Diagnose selectie”. Meer specifiek gaat het dan over volgende opties:

Plan en Diagnose werken beiden met het volledige rooster.
Plan selectie en Diagnose selectie werken beiden op basis van uitgebreid zoeken in het opdrachten tabblad.
Wat in de pagina “Plan en Plan selectie” beschreven werd onder “Wat nooit meegenomen wordt tijdens de planning” geldt ook voor een diagnose.
De “Opties | Roosteren” voor “Plan” en “Plan selectie” gelden ook voor “Diagnose” en “Diagnose selectie”. Dit heeft vooral te maken met welke opdrachten er extra meegenomen worden naar de MBE.
De “Opties | Engine” voor “Plan” en “Plan selectie” gelden ook voor “Diagnose” en “Diagnose selectie”. Wat van deze opties niet gebruikt wordt zijn:
- “Roosteren”: omdat er geen planning gemaakt wordt maar wel een diagnose.
- “Maak diagnose”: deze optie die toelaat om tijdens een reguliere planning ook een diagnosebestand aan te maken heeft geen betekenis als men expliciet een “Diagnose” of “Diagnose selectie” doet.

Indien men informatie over de moeilijkheidsgraad van resources wil bekomen in het diagnosebestand, moet men zeker “vergaar kennis” gebruiken in de “Opties | Engine”.

In de verdere uitleg over diagnose maken we geen onderscheid meer tussen beide vormen.

Starten van de diagnose

Drukt men op een van de diagnoseknoppen in het menu “Start | Plannen” dan verschijnt, net zoals bij een normale planning, een popup die aangeeft met welke opties de MBE gestart wordt.

Drukt men op “OK” dan verschijnt er een “Progress popup” die de 4 gekende stappen toont die Mondriaan uitvoert om de MBE aan te sturen: Parsen, Engine, Plan, Inlezen.

Vervolgens verschijnt het MBE scherm en hier ziet men dat de MBE kennis vergaart en uiteindelijk het diagnosebestand zal schrijven.

Als de diagnose klaar is verschijnt automatisch een tekstvenster waarin het diagnosebestand geopend wordt. Men kan niet meer aan het Mondriaanscherm tot men het diagnosebestand weer sluit.

Informatie in het diagnosebestand

Resources en hun bezetting

Informatie wordt gegeven voor volgende types resources:

DIAG_01: Leerkrachten en hun bezetting
DIAG_02: Klassen en hun bezetting
DIAG_03: Lokalen en hun bezetting
DIAG_04: Varia en hun bezetting

We bekijken enkel het voorbeeld voor Lokalen. In het bestand zoeken we DIAG_03:

Betekenis van de kolommen:

Naam: acroniem van de resource
Min: minimum aantal uren dat de resource bezet zal worden, dit op basis van de opdrachten die meegenomen werden naar de diagnose. Het minimum wordt bepaald door te veronderstellen dat in de OF-takken waar de resource voorkomt deze NOOIT gekozen wordt. Dus, als het om een lokaal gaat en het lokaal komt in verschillende keuzelijsten voor dan veronderstellen we dat hij nooit gekozen wordt. Verder worden ook de opdrachten in rekening gebracht waar de resource voorkomt als “vaste resource”. Voorbeeld: A23 heeft min 13 uur bezetting.
Max: maximaal aantal uren dat de resource bezet kan worden. Dit op basis van de opdrachten die meegenomen werden naar de diagnose. Het maximum wordt bepaald door te veronderstellen dat in de OF-takken waar de resource voorkomt deze ALTIJD gekozen wordt. Dus, als het om een lokaal gaat en het lokaal komt in verschillende keuzelijsten voor dan veronderstellen we dat hij steeds gekozen wordt. Verder worden ook de opdrachten in rekening gebracht waar de resource voorkomt als “vaste resource” Voorbeeld: A23 heeft max 150 uur bezetting. Dit kan uiteraard niet omdat een week geen 150 uur bevat.
Niet: dit zijn de uren waarop een resource nooit bezet kan worden. Dit wordt afgedwongen in de resource tabbladen en wordt in de Roosters/Planborden voorgesteld door een rood kruis. Voorbeeld: A23 heeft geen uren waarop hij niet bezet kan worden (0).
Tot: dit totaal is de som Min + Niet. Het gaat dus om het minimum totaal dat een resource in de week al bezet is. Voorbeeld: A23 13 + 0 = 13.
OK: dit zijn de uren waar de resource effectief geplaatst werd door opdrachten. Voorbeeld: A23 heeft 28 effectief geplaatste uren. Deze kolom is enkel van betekenis indien men de diagnose aanvraagt via de optie “Maak diagnose” in “Opties | Engine” en dan ook enkel en alleen indien men effectief roostert. Dus, voor de hier besproken acties “Diagnose” en “Diagnose selectie” die steeds zonder roosteren werken heeft de kolom geen betekenis.
Prob: geeft aan (met een sterretje “*”) of er een probleem is met de bezetting. Er is een probleem van zodra Tot > aantal uren in de roosterweek.

Opmerking over de “OK” kolom:

Bij “Diagnose” en “Diagnose selectie” wordt al dan niet gebruik gemaakt van “kennis vergaren”. Via de optie “Opties | Engine” kan men instellen of en hoe kennis vergaard moet worden. Indien er geen kennis vergaard wordt dan zal de OK kolom steeds 0 aangeven. Indien wel kennis vergaard wordt dan zal de OK kolom waarden vertonen die “achtergebleven” zijn na het kennis vergaren en in feite geen betekenis hebben.

Zoals al aangehaald heeft deze kolom pas betekenis wanneer de diagnose uitgevoerd wordt via de engine optie “Opties | Engine | Maak diagnose” en enkel indien er ook effectief geroosterd wordt. In alle andere gevallen moet men de informatie in deze kolom negeren.

Resources in relatie tot andere resources of vakken

Informatie wordt gegeven voor volgende combinaties:

DIAG_10: Leerkrachten en hun klassen
DIAG_11: Leerkrachten en hun vakken
DIAG_12: Leerkrachten en hun lokalen
DIAG_20: Klassen en hun leerkrachten
DIAG_21: Klassen en hun vakken
DIAG_22: Klassen en hun lokalen
DIAG_30: Vakken en hun leerkrachten
DIAG_31: Vakken en hun klassen
DIAG_32: Vakken en hun lokalen
DIAG_40: Lokalen en hun leerkrachten
DIAG_41: Lokalen en hun klassen
DIAG_42: Lokalen en hun vakken

We bekijken enkel het voorbeeld voor “Klassen en hun lokalen”. In het bestand zoeken we DIAG_22:

Op basis van de set van opdrachten (alles of selectie) waarvoor de diagnose gebeurt zien we hier per klas het mogelijke gebruik van lokalen. Hier wordt rekening gehouden met opdrachten die vaste lokalen hebben en opdrachten die keuzelokalen hebben. Men ziet 2 kolommen met cijfers bij elk lokaal staan.

minimale bezetting: dit is de bezetting die zou ontstaan als het lokaal NOOIT gekozen zou worden uit de keuzelijsten.
maximale bezetting: dit is de bezetting die zou ontstaan als er ALTIJD gekozen zou worden voor het lokaal uit de keuzelijsten.

Bekijk als voorbeeld de combinatie klas 1AA met lokaal A27: 1AA zit minimum 6 en maximaal 12 uur in A27.

Resources en de opdrachten waarin ze voorkomen

Informatie wordt gegeven voor volgende resources met hun opdrachten (hier regels genoemd):

DIAG_50: Leerkrachten en hun regels
DIAG_51: Klassen en hun regels
DIAG_52: Lokalen en hun regels

We bekijken enkel het voorbeeld voor “Leerkrachten en hun regels”. In het bestand zoeken we DIAG_50:

Per leerkracht worden hier alle opdrachten getoond waarin hij voorkomt. Bekijken we de eerste opdracht van Aerts_Dirk. Opnieuw dezelfde logica voor de cijfers tussen haakjes (3,3). Het eerste cijfer geeft de minimale bezetting van de leerkracht in die opdracht, het tweede cijfer de maximale. Omdat er geen OF-takken in deze opdracht staan waar Dirk al dan niet in voorkomt, is de minimale en maximale bezetting gelijk. Voor lokalen (DIAG_52) zal het veelvuldig voorkomen dat de cijfers verschillen.

Onderaan vinden we dan nog de som “=> (26,26)”. De leerkracht Dirk heeft dus over al opdrachten heen minimum en maximum 26 uur bezetting.

Bekijken we de opdracht van Dirk in Mondriaan dan zien we waar de cijfers vandaan komen:

Opmerkingen over de “technische” elementen die vermeld worden in de opdrachtlijnen in het diagnosebestand

In de opdrachtbeschrijvingen komen technische elementen voor die Mondriaan toevoegt aan de opdrachten om interne administratieve redenen. Voorbeelden hiervan zijn SYS_SELECTIE, System_Opdr_31, … Voor de gebruiker heeft dit geen betekenis. Het enige wat eventueel wel van pas kan komen zijn de “System_Opdr_xxx” elementen. Het nummer dat daar in vermeld wordt komt namelijk overeen met het ID van de opdracht in Mondriaan. In de eerst getoonde opdracht van Dirk is dat “31”. Dit kan handig zijn om een opdracht snel terug te vinden.

Naast technische elementen die Mondriaan toevoegt voor interne administratieve redenen zijn er ook nog herkenbare elementen terug te vinden die te maken hebben met eigenschappen van de opdracht zelf. Voorbeelden:

CC_PV: gaat om een custom kolom PV in het opdrachten tabblad van het type “vlagje”.
VT_AV: gaat over het vaktype van het vak in de opdracht. In dit geval een AV.

Resources en hun Complexiteit

Er is maar één sectie waar de complexiteit van de resources (hier leden genoemd) getoond worden:

DIAG_60: Leden en hun complexiteit

De Complexiteit van de resources wordt enkel bepaald indien er kennis vergaard wordt. Dit stuurt men dus via “Opties | Engine”. De opties voor het kennis vergaren bepalen hoeveel moeite de MBE stopt in het vergaren van de kennis. Het eindresultaat is dan de MBE een idee heeft van de complexiteit van elke opdracht. De complexiteit van de opdrachten wordt vervolgens geprojecteerd op de resources die in die opdrachten participeren. Het is geen exacte wetenschap maar de verhoudingen tussen de complexiteitswaarden per resource geven zeker een idee van hoe moeilijk elke resource in het geheel te roosteren is.

In het bestand zoeken we DIAG_60:

Alle resources staan door elkaar in omgekeerde volgorde van hun complexiteit. Hie hoger het cijfer naast de resource, hoe moeilijker. In dit voorbeeld wordt de klas 3MT dus als moeilijkste resource ervaren.

Dit aspect van de diagnose kan zeker gebruikt worden om problemen te analyseren. Dit kan zowel op het totale rooster als op selecties van opdrachten. Het kan een hint geven in de zoektocht naar hardnekkige problemen. Een absolute waarde mag men er echter niet aan koppelen.

MBE opties (Opties | Engine)

Peter — Sat, 28 Oct 2017 17:03:22 +0000

MBE opties (Opties | Engine)

Deze opties bepalen een aantal belangrijke parameters voor de sturing van de MBE:

De vertreksituatie voor de geselecteerde opdrachten: de opdrachten die geselecteerd zijn, kunnen al een plaats hebben in het rooster. Opties zullen bepalen wat we met die informatie moeten doen: gebruiken of niet en, indien wel, is de vraag op welke manier.
Wat moet er gedaan worden met opdrachten die niet geselecteerd werden, maar die al wel een plaats in het rooster hadden? Moeten we die opdrachten negeren in de MBE of moeten we ze dan toch meenemen en op welke manier moet de informatie over hun huidige plaats in het rooster gebruikt worden?
Moet de MBE voor het effectieve zoeken naar een oplossing eerst een analyse doen van de complexiteit van de opdrachten? Indien zo, is de vraag hoever hij moet gaan in die analyse. De informatie die uit die analyse komt, wordt dan gebruikt in het effectieve zoeken naar een oplossing. Dit gaat meestal helpen om sneller tot een oplossing te komen.
Welke methode moet de MBE gebruiken om naar een oplossing te zoeken? Er werden 2 methodes voorzien.
Tenslotte kan men nog vragen om een diagnosebestand aan te laten maken waarin de MBE een overzicht geeft van de opdrachten die geplaatst moeten worden en onder meer een overzicht geeft van de door de MBE bepaalde complexiteit van elke resource.

Bepaalde combinaties van opties zijn niet mogelijk. Dit zal ook uitgelegd worden. Mondriaan geeft ook een waarschuwing wanneer onmogelijke combinaties opgegeven worden.

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.

Inhoud

Gebruik van informatie uit de huidige (partiële) roosteroplossing
Plan selectie: geplaatste maar niet geselecteerde opdrachten
Kennis vergaren
Mogelijke combinaties van opties
Extra | Geen conflicten toelaten voor startpositie Geplaatste opdrachten
Extra | Gebruik prioriteit
Engine | Kennis vergaren
Engine | Roosteren
Engine | Maak Diagnose

Gebruik van informatie uit de huidige (partiële) roosteroplossing

Deze opties zijn van toepassing voor “Plan” en “Plan selectie”, niet voor “Analyseer opdrachten”.

Hiermee bepalen we wat de MBE moet doen met de informatie die Mondriaan heeft over de huidige plaats in het rooster en de resourceskeuzes die gemaakt werden. Elke opdracht die geselecteerd wordt om naar de MBE te sturen, kan immers al geplaatst zijn. Ofwel doet de MBE niets met deze informatie, ofwel neemt de MBE deze informatie mee en wordt het enkel als hint gebruikt, ofwel wordt een deel of alles behouden.

Opties:

Geen gebruik huidig rooster: de eventuele informatie die Mondriaan heeft over de plaats in het rooster en de resourcekeuzes die gemaakt werden, worden niet gebruikt door de MBE.
Laad .pos file: (niet actief voor gebruikers): deze optie laat toe om informatie over de plaats in het rooster en de resourcekeuzes apart te laden in de MBE.
Gebruik huidig rooster als hint: de informatie die Mondriaan heeft, wordt als hint meegegeven aan de MBE. De MBE zal die informatie gebruiken als eerste keuze wanneer hij een opdracht in het rooster tracht te plaatsen. Met deze optie kunnen eerder geplaatste opdrachten falen ten behoeve van de plaatsing van nog niet geplaatste opdrachten. Verder heeft dit geen effect.
Gebruik huidig rooster als hint, geplaatste opdrachten blijven in het rooster (incrementeel bijroosteren): ook hier wordt de informatie van de geplaatste opdrachten door de MBE als hint gebruikt in de zoektocht naar een oplossing, met een belangrijk verschil: de geplaatste opdrachten kunnen nooit falen ten behoeve van opdrachten, die nog niet geplaatst waren en mee opgenomen werden in de selectie. Hierdoor verzekert men een blijvende oplossing voor de reeds geplaatste opdrachten en probeert men er de niet geplaatste bij te roosteren. Deze techniek noemt men ook “incrementeel bijroosteren”.
Geplaatste opdrachten blijven op hun plaats staan, resourcekeuzes blijven mogelijk: dit is een verdere beperking van de vorige optie. De reeds geplaatste opdrachten kunnen niet meer van plaats wijzigen in het rooster, enkel de keuze van de resources blijft vrij voor de geplaatste opdrachten. Dit is ook een vorm van incrementeel bijroosteren maar strenger dan de vorige.
Geplaatste opdrachten blijven op hun plaats staan, ook de resourcekeuze blijft ongewijzigd: een laatste beperking t.o.v. de vorige optie is dat het niet toegelaten wordt om de keuzeresources van de geplaatste opdrachten nog te wijzigen ten behoeve van de niet geplaatste opdrachten. Dit is de laatste vorm van incrementeel bijroosteren.

De standaardoptie is de eerste, waarbij we de informatie uit het huidig rooster niet gebruiken.

Plan selectie: geplaatste maar niet geselecteerde opdrachten

Deze opties zijn enkel van toepassing voor “Plan selectie”. Het gaat over geplaatste opdrachten die niet in de selectie opgenomen werden en dus niet naar de MBE zouden gaan. Opdrachten die niet mee in de selectie zitten, worden standaard als ongeplaatst gemarkeerd als Mondriaan het resultaat van de MBE inleest. Indien men dit wil vermijden, kan men dat doen via deze opties. Hier kan men bepalen of de niet geselecteerde, maar wel geplaatste, opdrachten mee naar de MBE gaan en wat de MBE moet/mag doen met deze opdrachten.

Opties:

Niet in het rooster opnemen: de wel geplaatste, maar niet geselecteerde, opdrachten worden niet naar de MBE gestuurd en er wordt dan ook geen rekening mee gehouden tijdens het roosteren. Na het roosteren zullen ze niet langer geplaatst zijn.
Gebruik huidig rooster als hint, geplaatste opdrachten blijven in het rooster (incrementeel bijroosteren): hier wordt de informatie van de geplaatste opdrachten door de MBE als hint gebruikt in de zoektocht naar een oplossing. Bijkomend wordt via deze optie een ander belangrijk aspect bepaald. De geplaatste opdrachten kunnen nooit falen ten behoeve van opdrachten, die nog niet geplaatst waren en mee opgenomen werden in de selectie. Hierdoor verzekert men een blijvende oplossing voor de reeds geplaatste opdrachten en probeert men er de niet geplaatste bij te roosteren. Deze techniek noemt men ook “incrementeel bijroosteren”.
Geplaatste opdrachten blijven op hun plaats staan, resourcekeuzes blijven mogelijk: dit is een verdere beperking van de vorige optie. De reeds geplaatste opdrachten kunnen niet meer van plaats wijzigen in het rooster, enkel de keuze van de resources blijft vrij voor de geplaatste opdrachten. Dit is ook een vorm van incrementeel bijroosteren, maar strenger dan de vorige.
Geplaatste opdrachten blijven op hun plaats staan, ook de resourcekeuze blijft ongewijzigd: een laatste beperking t.o.v. de vorige optie is het ook niet toelaten dat de keuzeresources van de geplaatste opdrachten nog wijzigen ten behoeve van de niet geplaatste opdrachten. Dit is de laatste vorm van incrementeel bijroosteren.

De standaardoptie is de eerste, waarbij de niet geselecteerde maar wel geplaatste opdrachten niet mee opgenomen worden voor de MBE planning.

Kennis vergaren

De MBE heeft er meestal baat bij om eerst een analyse te doen van de complexiteit van het probleem. Het bepalen van de complexiteit van de opdrachten, in de context van andere opdrachten en andere gestelde beperkingen, noemen we hier “kennis vergaren”.

Opties:

Geen kennis vergaren: bij deze optie wordt geen kennis vergaard en gaat de MBE een oplossing zoeken zonder extra kennis over de complexiteit van de opdrachten.
Kennis vergaren voor de niet-geplaatste opdrachten: bij deze optie wordt enkel de complexiteit bepaald van de geselecteerde maar niet-geplaatste opdrachten. De geplaatste opdrachten maken hier dan wel deel uit van de context waarbinnen kennis vergaard wordt voor de niet-geplaatste opdrachten.
Kennis vergaren voor alle opdrachten: bij deze optie wordt kennis vergaard voor alle geselecteerde opdrachten.

De standaardoptie is de derde, waarbij steeds kennis vergaard wordt voor alle geselecteerde opdrachten.

Mogelijke combinaties van opties

Voor de optieblokken die tot nu toe besproken werden, zijn niet alle combinaties mogelijk. In deze sectie bespreken we de mogelijke combinaties. Het gaat hier om deze optieblokken:

Kennis vergaren
Gebruik van informatie uit de huidige (partiële) roosteroplossing. (Voor Plan en Plan selectie)
Plan selectie: geplaatste maar niet geselecteerde opdrachten.

	1ste optieblok: Geen kennis vergaren: Kennis vergaren voor niet-geplaatste opdrachten Deze opties zijn combineerbaar met elk van de opties in de 2 andere blokken. Geen kennis vergaren is steeds een optie. Kennis vergaren van de niet geplaatste opdrachten kan ook steeds, onafhankelijk van het feit of men kennis van geplaatste opdrachten wenst te gebruiken.
	1ste optieblok: Kennis vergaren voor alle opdrachten Is enkel combineerbaar met de eerste optie van de andere blokken. Van zodra men informatie van de huidige plaatsing van opdrachten wenst te gebruiken, kan men geen kennis meer vergaren van de geplaatste opdrachten. Dus, als men informatie over de huidige plaatsing wenst te gebruiken, kan men enkel kennis vergaren voor de niet geplaatste opdrachten.
	2de optieblok: Geen gebruik huidige rooster Gebruik huidig rooster als hint Kan enkel gecombineerd worden met “Niet in het rooster opnemen” van de geplaatste, maar niet geselecteerde, opdrachten. Dus, als men de niet geselecteerde (wel geplaatste) opdrachten als basis wil behouden (en incrementeel bijroosteren) dan moeten ook de geselecteerde opdrachten die geplaatst waren in die basis opgenomen worden.
	2de optieblok: Gebruik huidig rooster als hint, geplaatste opdrachten blijven in het rooster (incrementeel bijroosteren) Geplaatste opdrachten blijven op hun plaats staan, resourcekeuzes blijven mogelijk Geplaatste opdrachten blijven op hun plaats staan, ook de resourcekeuze blijft ongewijzigd Deze opties zijn combineerbaar met elke van de 3 laatste opties van blok 3.

De meest gebruikte combinaties zijn:

Alles in een geheel normaal roosteren:
- Blok 1: Kennis vergaren voor alle opdrachten
- Blok 2: Geen gebruik huidig rooster
- Blok 3: Niet in rooster opnemen
Incrementeel een deel bijroosteren:
- Blok 1: Kennis vergaren voor niet-geplaatste opdrachten
- Blok 2: Gebruik huidig rooster als hint, geplaatste opdrachten blijven in het rooster (incrementeel bijroosteren)
- Blok 3: Niet in rooster opnemen

Extra | Geen conflicten toelaten voor startpositie Geplaatste opdrachten

Onderaan in het optiescherm vindt men volgende optie:

Deze optie is van belang bij planactiviteiten waarbij men wenst te vertrekken van een deel reeds geplaatste opdrachten waarbij men een deel niet geplaatste opdrachten wenst bij te roosteren (incrementeel roosteren). Indien men bij dergelijke planactiviteit niet wenst dat er geplaatste opdrachten kunnen opgeofferd worden ten voordele van nog niet geplaatste opdrachten dan heeft men dit vangnet nodig.

Volgend voorbeeld moet dit verduidelijken. Stel dat men een rooster heeft dat didactisch in orde is en volledig geroosterd met leerkrachtwensen. Stel dat na inspectie van het rooster blijkt dat er toch nog wat leerkrachtwensen toegevoegd moeten worden. Als men deze nieuwe wensen aanmaakt, dan worden die wensen op een bepaalde plaats in de leerkrachtroosters geplaatst waarbij er mogelijk conflicten kunnen ontstaan. Ook de gebruiker zou die wens in het rooster een voorlopige plaats kunnen gegeven hebben, niet rekening houdend met mogelijke conflicten. Wensen en lesopdrachten conflicteren, maar zijn wel gemarkeerd als “geplaatst”. Bij incrementeel bijroosteren, met behoud van geplaatste opdrachten, gaat Mondriaan de geplaatste opdrachten doorgeven aan de MBE. Maar, de MBE aanvaardt geen conflicten. Echter, de bijgemaakte wensen staan in het rooster en hebben conflicten met lesopdrachten. Wat Mondriaan dan doet, is alle conflicterende opdrachten als NIET geplaatst doorgeven aan de MBE, en dit zonder onderscheid te maken tussen lesopdrachten, leerkrachtwensen, etc. Dus, de lesopdrachten die geplaatst waren en in conflict staan met geplaatste wensen, zullen opnieuw geroosterd worden met de kans dat ze opgeofferd worden ten voordele van een wens.

Om deze kans te vermijden kan men deze optie aanvinken. Als deze optie aangevinkt is, gaat Mondriaan de MBE niet opstarten als er conflicten bestaan tussen “geplaatste” opdrachten en waarbij gevraagd wordt om aan incrementeel roosteren te doen. De enige functie van deze optie is dus het tegenhouden van de planning als dergelijke situatie zich voordoet. Het is aan de gebruiker om te kiezen voor dit vangnet.

Verder is het aan de gebruiker om deze conflicten eerst te verwijderen. De gebruiker kan conflicten opsporen via de “Conflicten” knop. Dit geeft alle mogelijke conflicten, ook tussen lesopdrachten. Heeft men een conflict tussen bijvoorbeeld een (aantal) lesopdrachten en een wens dan kan men de wens gewoon uit de planning halen zodat hij als “niet geplaatst” wordt gemarkeerd voor hij de MBE ingaat.

Mondriaan heeft ook 2 acties voorzien om op een snelle manier conflicterende wensen en conflicterende optimalisatieopdrachten op “niet geplaatst” te zetten. Deze acties vindt men in:

Tools | Plannen | Wis conflicterende wensen
Tools | Plannen | Wis conflicterende optimalisaties

Met “Wis” wordt hier bedoeld dat ze uit de planning gehaald worden en dus als “niet geplaatst” naar de MBE zullen gaan.

Heeft men echter conflicten tussen lesopdrachten onderling dan gaat de gebruiker dit eerst manueel moeten oplossen (indien de optie aanstaat).

Extra | Gebruik prioriteit

Onderaan in het optiescherm vindt men volgende optie:

Voor de MBE is er tussen aangeboden opdrachten, die gepland moeten worden, normaal geen verschil in prioriteit. Alle opdrachten worden evenwaardig behandeld en elke opdracht heeft evenveel kans om geplaatst te worden of om te falen. In sommige uitzonderlijke gevallen kan het echter nuttig zijn om opdrachten in prioriteitscategoriëen in te delen. De gebruiker kan dat doen door in het Opdrachten tabblad (en ook in het Wensen tabblad) de kolom “Prioriteit” te gebruiken en daar via een getal een prioriteit op te geven. Alle opdrachten en wensen die dezelfde prioriteit hebben, worden gelijkwaardig behandeld. Een opdrachtcategorie met een hogere prioriteit (hogere prioriteit = lager nummer in Prioriteit kolom. 0 is hoogste prioriteit) heeft voorrang op een opdrachtcategorie met een lagere prioriteit. Dus, de opdrachten met Prioriteit 0 worden eerst geplaatst, dan komen de opdrachten met prioriteit 1, enz. Opdrachten met prioriteit 1 kunnen nog wel verplaatsingen veroorzaken van de opdrachten met prioriteit 0, maar kunnen er nooit voor zorgen dat een opdracht van prioriteit 0 faalt. Merk op dat opdrachten zonder prioriteit met de laagste prioriteit behandeld worden.

In feite komt het werken met prioriteiten er op neer dat de MBE telkens de volgende set van opdrachten incrementeel bijroostert maar dan op een automatische manier. Hier heeft de gebruiker geen invloed op de roosterparameters (methode, diepte, etc) die voor elke categorie gebruikt wordt. Het zijn voor elke categorie dezelfde parameters.

Merk ook op dat het falen van een opdracht met een hogere prioriteit niet belet dat de MBE aan de volgende categorie van opdrachten begint.

Het gebruiken van veel verschillende prioriteiten heeft geen zin. Het gebruik van 2 tot 4 prioriteiten is zeker mogelijk, maar als men veel hoger gaat dan zal men ook zien dat de MBE niet meer de volledige flexibiliteit heeft om een oplossing voor het geheel te vinden, zeker niet voor “Methode 2” (zie verder).

Engine | Kennis vergaren

Naast de beslissing of er al dan niet kennis vergaard moet worden en voor welke opdrachten, kan de gebruiker ook bepaalde parameters zetten, die bepalen hoe grondig de analyse van de complexiteit gedaan moet worden. Met grondig wordt hier dan vooral bedoeld hoeveel moeite de MBE moet doen om een idee te krijgen van de complexiteit van elke opdracht binnen de context van de andere opdrachten en gestelde beperkingen. Na het bepalen van de complexiteit start de MBE met het echte zoekwerk naar een oplossing en kan hij bij die zoektocht gebruik maken van de kennis over die complexiteit. Het vergaren van kennis geeft geen 100% garantie op een snellere oplossing, maar het is zeker nuttig om dit te doen. De MBE (“Mondriaan Backtrack Engine”) maakt gebruik van recursieve backtrack algoritmes. Deze worden zowel gebruikt voor het vergaren van kennis als voor het roosteren. Omdat het kennis vergaren en het roosteren gebruik maken van dezelfde algoritmes, kan men voor beide gevallen via parameters invloed hebben op deze algoritmes. De linkerkant van dit scherm toont de parameters die we kunnen zetten voor het kennis vergaren. Er zijn soorten algoritmes, “Methode 1” en “Methode 2”. Omdat we voor kennis vergaren enkel “Methode 1” gebruiken, kan er voor kennis vergaren geen keuze gemaakt worden. Bij het roosteren kan dat wel.

Er zijn 3 parameters die de gebruiker kan instellen (voor “Methode 1” binnen kennis vergaren) en die momenteel getoond worden zoals ze standaard ingesteld worden.

Aantal iteraties: kennis vergaren wordt in iteraties uitgevoerd. Bij elke iteratie worden de opdrachten in een andere context bekeken en wordt er de complexiteit van bepaald. Van alle iteraties wordt de gemiddelde complexiteit bepaald. Echt moeilijke opdrachten komen dan bovendrijven. Een goede standaard blijkt een 20-tal iteraties te zijn. Als uit experimenten met een specifiek probleem blijkt dat het ook met minder kan of met meer moet, dan kan dat zeker aangepast worden.
Zoekdiepte: het MBE algoritme (hier “Methode 1”) maakt gebruik van backtracktechnieken. De zoekdiepte bepaalt hoe diep gegaan mag worden in “het verplaatsen” van opdrachten ten voordele van “het plaatsen” van een te plaatsen opdracht X. Is de zoekdiepte bijvoorbeeld 3 dan mag om X te plaatsen Y verplaatst worden, om Y te plaatsen Z verplaatst worden en om Z te plaatsen Q verplaatst worden. Maar Q moet dan een vrije plaats vinden want voor Q mag niets meer verplaatst worden. Standaard zetten we de zoekdiepte op 3 en dat is in de meeste gevallen goed. Voor iets complexere gevallen is 4 nodig maar 5 komt zelden voor.
Startdiepte: via deze parameter bepaalt men of men eerst eerder in de breedte zoekt, of meteen in de diepte. Standaard zetten we de startdiepte op 1. Dit wil zeggen dat we in een eerste stap kijken of we voor X geen oplossing kunnen vinden op een roosterpunt waar geen enkele opdracht moet wijken. Als dat niet lukt verhogen we de diepte tot we aan de ingestelde zoekdiepte zitten.

Merk op dat de standaardinstellingen voor Zoekdiepte en Startdiepte gelijk zijn voor “Kennis vergaren” en “Roosteren”. Het is gebleken dat de snelste oplossing vaak bekomen wordt door deze instellingen inderdaad in lijn te houden. De gebruiker heeft de uiteindelijke keuze.

Engine | Roosteren

Naast de beslissing voor welke opdrachten er een oplossing gezocht moet worden, kan de gebruiker ook sturing geven aan de algoritmes die gebruikt worden. Er zijn 2 backtrack algoritmes waaruit de gebruiker kan kiezen. Het eerste algoritme (“Methode 1”) werd al aangehaald bij “Engine | Kennis vergaren” en wordt uitzonderlijk ook gebruikt bij het roosteren (bij bepaalde technieken die op een andere plaats uitgelegd worden). Meestal wordt een andere versie van het algoritme gebruikt (“Methode 2”) voor het effectieve roosteren.

Methode 1: zelfde als bij “kennis vergaren”. Wordt meestal niet gebruikt omdat het voor het roosteren te beperkt is. Wel bij sommige roostertechnieken, zoals bij incrementeel roosteren, kan het soms nuttig zijn om op een dieper niveau een beperkt aantal opdrachten bij te roosteren.
Methode 2: de standaardoptie voor het Roosteren. Het grote voordeel van deze methode is dat er veel verder gezocht wordt dan met het eenvoudig recursief in de breedte en diepte zoeken van Methode 1. Het zou ons te ver leiden om die technieken hier uit te leggen maar in de kern maakt Methode 2 zelf ook gebruik van Methode 1. Vandaar dat men ook voor Methode 2 de parameters Zoekdiepte en Startdiepte ziet.

Er zijn 4 parameters die de gebruiker kan instellen (de eerste 2 voor “Methode 1” en “Methode 2”, de laatste twee zijn enkel nuttig voor “Methode 2”) en die momenteel getoond worden zoals ze standaard ingesteld worden.

Zoekdiepte: (M1 en M2) Zie beschrijving bij “Engine | Kennis vergaren”
Startdiepte: (M1 en M2) Zie beschrijving bij “Engine | Kennis vergaren”
Extra Zoekdiepte: (M2). Zoals uitgelegd maakt het M2 algoritme ook gebruik van het M1 algoritme maar heeft er als het ware een laag rond gebouwd. De parameters “Zoekdiepte” en “Startdiepte” hebben dus voor M1 en M2 dezelfde betekenis en dienen in beide gevallen voor het sturen van algoritme van M1. Als de extra laag die M2 rond M1 gebouwd heeft, merkt dat een bepaalde opdracht X ook niet geplaatst kan worden via de extra intelligentie die M2 aan M1 toevoegt, dan kunnen we overgaan tot het individueel toekennen van toch een hogere zoekdiepte voor de gefaalde opdracht X. Standaard wordt die extra bonusdiepte op 1 gezet. Indien X een eerste keer faalt met M2 dan wordt de opgegeven zoekdiepte voor X met één verhoogd en krijgt X een tweede kans. Men kan deze parameter ook op bijvoorbeeld 2 zetten. Dit laat dan toe om voor X de zoekdiepte in 2 stappen te verhogen. In een eerste stap Zoekdiepte+1, indien geen oplossing gevonden naar Zoekdiepte+2. Als X dan ook via deze individuele verhoging van de zoekdiepte niet opgelost kan worden, dan faalt X finaal. De standaardwaarde voor “Extra zoekdiepte” is dus 1 en dat is in 99% van de gevallen voldoende.
M2b: dit is een vlagje dat standaard uitgevinkt is. M2b slaat op een b-versie van Methode 2. Standaard staat dus de a-versie actief. Vanaf versie BT20.00.02 van de MBE is deze gewijzigde versie van Methode 2 beschikbaar. De b-versie van Methode 2 zorgt ervoor dat het algoritme op een meer conservatieve manier de kaarten herschudt tijdens het niet kunnen oplossen van lokale problemen (een cluster van lastige opdrachten). Als men in de a-versie ziet dat tijdens het verloop van het roosteren er extreem veel falingen van dezelfde opdrachten voorkomen (jump-factoren gaan de hoogte in) dan is het waarschijnlijk goed om eens te kijken of de b-versie het niet beter doet. Er zijn heel wat voorbeelden waarbij het verschil tussen de a-versie en de b-versie spectaculair is. Opnieuw is het aan de gebruiker om te bepalen wat voor zijn roosterprobleem de beste oplossing is.

Voor al deze parameters geldt dat er omzichtig mee omgesprongen moet worden. Het te snel verhogen van de zoekdiepte of extra zoekdiepte kan al snel leiden tot onnodige lange rekentijden van het algoritme. Indien problemen moeilijk oplosbaar zijn, moet er een (door Mondriaan ondersteunde) analyse gebeuren om de knelpunten (of onoplosbaarheden) te vinden. Het is vaak interessant om op minder hoge dieptes te roosteren om snel een zicht te krijgen op probleemgevallen.

Engine | Maak Diagnose

Deze optie is van toepassing op “Plan” en “Plan selectie”. Als deze optie aangevinkt is, dan gaat de MBE een diagnosebestand aanmaken over de opdrachten en resources die in het spel zijn.

Indien men de optie “Maak diagnose” aanvinkt en men doet vervolgens een “Plan” of “Plan selectie”, dan komt er een extra knop tevoorschijn in de popup die verschijnt als de MBE afgelopen is.

Drukt men op “Bekijk diagnose” dan opent volgend “txt” bestand waarin men de gevraagde diagnose kan vinden. Merk op dat je geen toegang meer hebt tot het Mondriaan scherm zolang dit tekstbestand open staat.

De diagnose gebeurt met dezelfde instellingen als die voor de planning voorzien werden.

Het moment waarop de diagnose gebeurt

Indien men “Plan” of “Plan selectie” doet, dan kan afhankelijk van de MBE opties al dan niet kennis vergaard worden en al dan niet geroosterd worden. In elk van de mogelijke gevallen wordt de diagnose als laatste stap uitgevoerd. Op die manier kan zowel de mogelijks vergaarde kennis als de mogelijke plaatsing van de opdrachten in rekening gebracht worden voor de diagnose.

Meer uitleg over de inhoud van het diagnosebestand kan men vinden op volgende pagina:

Diagnose en Diagnose selectie

Roosteropties (Opties | Roosteren)

Peter — Sat, 28 Oct 2017 14:52:25 +0000

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 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)
Bijkomende leerkrachtspecifieke opdrachtselectie
Algemene beperkingen
Opdrachtelementen al dan niet mee te nemen tijdens het roosteren
Extra – Update RandEnSpringUurlijsten (op basis van vaste uren) bij plannen
ZR-Link constructie
Bloklink constructie
Effect van Roosteropties op “Valideer Rooster” en “Valideer Rooster met opties”

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”.

Plan en Plan selectie

Peter — Sun, 01 Oct 2017 13:19:39 +0000

Plan en Plan selectie

De bedoeling van Mondriaan is om voor alle opgegeven opdrachten en beperkingen een mogelijke oplossing te vinden. Het is mogelijk dat er vele oplossingen zijn voor het gestelde probleem maar het uitgangspunt is dat eender welke oplossing een goede oplossing is. Indien een gevonden oplossing toch niet goed genoeg is, betekent dit dat de opgegeven opdrachten en beperkingen niet afdoende waren. Het staat de gebruiker dan vrij om in te grijpen in de opdrachten en beperkingen.

Het vinden van een oplossing is de taak van de “Mondriaan Backtrack Engine” (MBE). De MBE neemt als input het op te lossen probleem en stuurinstructies van de gebruiker. Het op te lossen probleem kan het volledige rooster zijn (alle actieve opdrachten en beperkingen) of een beperkte selectie hiervan. De gebruiker kan een selectie maken van opdrachten en beperkingen die hij apart wenst op te lossen. Deelproblemen oplossen (in isolatie) maakt deel uit van een verstandige roosterstrategie. Indien deelproblemen oplosbaar zijn, is het waarschijnlijker dat ook het geheel oplosbaar is door de MBE. Een strategie die meestal niet werkt, is dat men het testen van de oplosbaarheid uitstelt tot alle opdrachten en beperkingen ingegeven zijn. Door deelproblemen te bekijken en trachten op te lossen krijgt de gebruiker meer inzicht in de knelpunten van zijn rooster en kan hij ook beter inschatten waar relaxaties nodig zijn om het geheel op te lossen. Mondriaan biedt allerlei mogelijkheden om deelproblemen op te lossen en analyses te maken van deelproblemen.

Naast de selectie van het probleem dat opgelost moet worden heeft de gebruiker ook invloed op de manier waarop de MBE naar een oplossing zoekt. Mondriaan heeft standaardinstellingen voor de MBE, die gemiddeld genomen goed werken, maar het komt ook voor dat men met gewijzigde instellingen sneller tot een oplossing komt. De ervaring leert meestal snel welke de beste instellingen zijn voor een bepaald probleem of een bepaalde school.

In dit hoofdstuk gaan we dieper in op volgende aspecten:

selectie van de opdrachten en beperkingen waarvoor een oplossing gezocht moet worden
starten van de MBE om een oplossing te zoeken voor gans het rooster (“Plan”)
starten van de MBE om een oplossing te zoeken voor een deel van het rooster (“Plan Selectie”)

Nuttige informatie over opties kan men op volgende pagina’s vinden:

Nuttige informatie over het aspect Diagnose:

Diagnose en Diagnose selectie

Nuttige informatie over analyseren opdrachten:

Analyseren van opdrachten

Inhoud

Roosteren van het volledige rooster met standaardinstellingen (“Plan”)
Wat nooit meegenomen wordt tijdens het Plannen
Betekenis van de kleuren en cijfers in de kolom “%geroosterd”
Roosteren van een subset van de opdrachten met standaardinstellingen (“Plan selectie”)
- Nog enkele weetjes en verschillen tussen “Plan” en “Plan selectie” met dezelfde standaardopties
Wissen van conflicterende opdrachten en verwijderen van niet geplande opdrachten
Bestanden die de MBE op de achtergrond aanmaakt tijdens het plannen
Meer details over de getoonde informatie in de logfile en op het MBE scherm (gevorderd!)

Roosteren van het volledige rooster met standaardinstellingen (“Plan”)

Als eerste introductie in het automatisch roosteren bekijken we hoe we de MBE de instructie kunnen geven om voor alle opdrachten en beperkingen, en met standaard instellingen voor de stuurinstructies, een oplossing te zoeken. In het het optie-tabblad kiezen we voor de standaardopties. De 2 tabbladen die we uit het optiescherm verder uitvoerig zullen bespreken zijn “Opties | Engine” en “Opties | Roosteren”. Door “Standaardopties” te kiezen worden er bepaalde keuzes gemaakt in deze 2 tabbladen die van belang zijn voor de selectie van opdrachten en de sturing van de MBE.

We vertrekken van een rooster waarbij nog niets gepland is. Het is geen vereiste om te vertrekken van een niet gepland rooster, we kunnen deze stappen evengoed doen voor een rooster dat al geheel of gedeeltelijk opgelost was. Volgend beeld toont het planbord met in de assen Klassen/Roosterpunten. Men ziet dat het rooster quasi leeg is. De opdrachten die wel zichtbaar zijn, zijn dus gepland en staan in het rooster. Het zijn “vaste” opdrachten. Vaste opdrachten werden door de gebruiker op een bepaald roosterpunt vastgezet en kunnen nooit verplaatst worden. Dat kan men zien aan het “gele slotje” in de opdracht. Dus, vaste opdrachten zal men steeds zien en die kunnen niet uit het rooster verwijderd worden.

In het menu “Start | Plannen” ziet men de knop “Plan”. Het is via deze knop dat men de MBE laat starten met als input alle actieve opdrachten en beperkingen (zonder selectie). Omdat de standaardinstellingen voor de MBE gekozen werden, zal de MBE gewoon nu naar een oplossing zoeken voor het probleem via standaard stuurinstructies.

Drukt men op “Plan” dan verschijnt nog volgende popup die toont met welke opties geroosterd gaat worden. Men drukt hier op “OK”.

Van zodra men op “OK” gedrukt heeft, verschijnt er een “Progress popup” die de 4 stappen toont die Mondriaan uitvoert om de MBE aan te sturen:

Parser: Mondriaan vertaalt de opdrachten en beperkingen in een taal die de MBE kan begrijpen.
Engine: de MBE wordt opgestart met als input het vertaalde probleem en de stuurinstructies.
Plan: gedurende de tijd dat de MBE naar een oplossing zoekt.
Inlezen: als de MBE klaar is, wordt het gevonden resultaat door Mondriaan ingelezen en wordt de oplossing zichtbaar in de Mondriaan schermen.

Tijdens de “Parser” fase zal men mogelijks een popup zien verschijnen waarin verschillende validaties gebeuren om te zien of bepaalde grenzen die de MBE stelt niet overschreden worden. Deze validaties kunnen in uitzonderlijke gevallen lang duren. De gebruiker kan dit steeds onderbreken.

Tijdens de “Plan” fase verschijnt er een blauw scherm waarin men de voortgang van de MBE kan volgen. Wat de precieze betekenis is van wat getoond wordt in dit scherm zal in een meer geavanceerd hoofdstuk uitgelegd worden en is hier nu niet aan de orde om te begrijpen hoe men de MBE moet aansturen.

Als de MBE klaar is (al dan niet succesvol) wordt het resultaat ingelezen en ziet men volgende popup met het resultaat van de MBE. In dit geval toont de popup dat alle opdrachten, alle leerkrachtwensen, en alle vensters 100% geplaatst werden. Ook de effectieve aantallen worden vermeld. Zo werden er hier 1.627 opdrachten, 70 wensen en 17 vensters gepland. Omdat het beeld nog steeds op het eerder lege planbord staat, zien we nu ook onmiddellijk het resultaat in het planbord. Voor alle klassen zien we nu duidelijk dat het rooster gevuld is. Hetzelfde beeld zal men nu zien in planborden waar de leerkrachten en lokalen getoond worden. Ook in de individuele roosters kan men nu bekijken hoe het resultaat eruit ziet.

Ook in het opdrachtentabblad wordt duidelijk aangegeven dat alle opdrachten “geroosterd” zijn. Niet alleen in de kolom “% Geroosterd” kan men het effect zien. In de kolom “Gekozen” en “Gekozen uren” ziet men de roosterpunten die de MBE gekozen heeft. In de kolom “Gekozen lokalen” ziet men de lokalen die de MBE voor elke opdracht gekozen heeft.

Uit de planning halen van geplande opdrachten en vensters

Tip: indien je alle (of een deel) opdrachten weer uit het rooster wenst te halen (ongepland maken) dan kan dat door alle opdrachten te selecteren en via rechtermuisklik “Verwijderen | Planning” te kiezen.

Het resultaat is dat alle geselecteerde opdrachten weer uit de planning gehaald werden. Er zijn geen gekozen uren meer, geen gekozen lokalen, vensters, etc. De enige opdrachten die niet uit de planning gehaald kunnen worden, zijn opdrachten die “Vast” staan. Het resultaat ziet er dan in het opdrachtentabblad als volgt uit:

Ook vensters staan ergens in het rooster en kunnen uit de planning gehaald worden via dezelfde weg. Selecteert men één of meerdere vensters dan kan men via rechtermuisklik “Verwijderen | Planning” een venster uit de planning halen. Het resultaat ziet men in de kolom “% Geroosterd”.

Merk op: als men opdrachten die gebruik maken van vensters uit de planning haalt, zal daardoor de waarde in de kolom “Vullingsgraad” van het venster dalen. In het getoonde voorbeeld werd een opdracht die in het venster “Ve2b” staat uit de planning gehaald waardoor de vullingsgraad naar 50% gegaan is.

Onderbreken van de planning: 2 manieren

In normale omstandigheden laat men de MBE gewoon zijn werk doen en stopt de MBE als hij zijn taak volbracht heeft. Er kunnen redenen zijn waarom men de MBE niet wenst verder te laten doen en dan zijn er 2 manieren om hem te onderbreken.

Onderbreken zonder recuperatie tussenresultaten MBE

Men kan de planning geforceerd stoppen door op de knop “Annuleer” te drukken in het “Bezig met plannen” progress scherm.

Indien het blauwe scherm van de MBE zichtbaar is (in de “Plan” fase) zal dit blauwe scherm niet automatisch sluiten als men op “Annuleer” drukt. Men kan dat scherm dan gewoon zelf sluiten. Het effect van “Annuleer” zal zijn dat het eventuele resultaat (tussentijds) van de MBE ook niet meer zal ingelezen worden. Het is dus alsof men nooit op “Plan” gedrukt zou hebben; het werk van de MBE wordt niet meer ingelezen.

Onderbreken met recuperatie tussenresultaten MBE

Hier gaat men NIET op “Annuleer” drukken maar het blauwe scherm van de MBE sluiten (door op het standaard “close window” kruisje te drukken). Hierdoor stopt men de MBE. Het resultaat is dat Mondriaan ziet dat de MBE klaar is en dat Mondriaan het tussentijdse resultaat van de MBE zal inlezen. Dit is dus een manier om toch een deel van het werk dat de MBE al gedaan had te recupereren. Het nut hiervan zal later nog besproken worden bij de meer geavanceerde roostertechnieken. Dit tussentijdse resultaat wordt door Mondriaan op dezelfde manier behandeld als een volledig resultaat. Mondriaan zal tonen welk deel wel en niet geplaatst werd. Men kan perfect vanuit deze situatie weer opnieuw plannen.

Zie ook “Rekenen met Methode 2 afbreken en overschakelen op Methode 1 voor de nog niet geplaatste opdrachten” voor het onderbreken van Methode 2 op een manier die er nog het beste tracht uit te halen via Methode 1.

Geplande Leerkrachtwensen zijn ook te herkennen

Zoals we verder zullen zien, maakt het roosteren van de leerkrachtwensen deel uit van de standaardopties voor het roosteren. Indien men leerkrachtwensen geroosterd heeft, zal Mondriaan laten weten welk percentage van deze wensen geroosterd werden en kan men in het tabblad “Opdrachten | Wensen” ook perfect zien welk deel wel en niet geplaatst werd in het rooster.

Ook wensen kan men via de rechtermuisknop “Verwijderen | Planning” weer uit het rooster halen.

Geplande Vensters zijn ook te herkennen

In het tabblad “Elementen | Vensters” kan men in de kolom “% Geroosterd” zien of een venster al dan niet gepland is. Een venster is ofwel 100% ofwel 0% gepland. Men kan ook de vullingsgraad van een venster zien. De vullingsgraad is enkel relevant als het venster geplaatst is. Heb je een geplaatst venster met grootte 4 (100% geroosterd), maar er zit enkel 1 opdracht van 1 uur in dit venster, dan is de vullingsgraad 25%.

Tip: Via rechtermuisklik “Verwijderen | Planning” kan men een vensteropdracht ook uit het rooster halen.

Nog enkele weetjes over dit basisproces met standaardopties

De uitkomst van de planning is onafhankelijk van eerdere planningen

Het resultaat van de planning wordt niet beïnvloed door de resultaten van een eerdere volledige of gedeeltelijke oplossing. Ook de manuele plaatsingen die eventueel gebeurd zouden zijn, hebben geen effect.

Merk op dat er opties bestaan om wel rekening te houden met eerdere resultaten. Dit zal verder toegelicht worden.

De uitkomst van de planning is onafhankelijk van de sortering van de opdrachten in het opdrachten tabblad

Men kan opdrachten op veel manier sorteren maar het resultaat van de planning zal hier niet door wijzigen. Wat wel een effect heeft op de planning is het “ID” van de opdracht. Dit unieke volgnummer van de opdracht wijzigt echter nooit. Indien men dezelfde opdrachten zou aanmaken in een andere volgorde in een ander Mondriaanbestand, en de opdrachten een andere volgorde zouden hebben volgens hun “ID”, dan zal de resulterende planning wel kunnen verschillen.

De selectie die men maakt in “Uitgebreid zoeken” heeft geen effect op de planning die men via “Plan” doet

Men kan een selectie van de opdrachten zichtbaar maken via uitgebreid zoeken. Deze selectie heeft geen invloed op de opdrachten en beperkingen die naar de MBE gestuurd worden. Bij “Plan” worden steeds alle actieve opdrachten en beperkingen naar de MBE gestuurd.

Om effectief een deelselectie van de opdrachten te plannen moet men niet “Plan” maar “Plan selectie” gebruiker. Dit wordt verder behandeld.

Wat nooit meegenomen wordt tijdens het Plannen

Mondriaan biedt de mogelijkheid om de volledige set aan opdrachten en beperkingen te plannen of om er een deel van te plannen, gebaseerd op bepaalde selecties en/of settings in de optietabbladen. Deze opties en selecties zullen verder besproken worden. Echter, los hiervan, bespreken we hier de lijst van zaken die NOOIT in de planning opgenomen zullen worden, onafhankelijk van enige opdrachtselectie of setting in de optietabbladen. Ook onafhankelijk van de methode van plannen (Plan, Plan selectie, etc)

Hier gaat het over het inactief maken van opdrachten, wensen, vensters, extra spreidingen, en resources. Door zaken in hun respectievelijke tabbladen op non-actief te zetten zullen ze nooit opgenomen worden in een planning en dus ook nooit naar de MBE gestuurd worden om rekening mee te houden in de planning.

Opdrachten waarvoor “Roosteren” uitgevinkt is

Opdrachten die op deze manier uitgeschakeld worden voor het roosteren gaan nooit opgenomen worden in de planning. Ze zullen dus nooit naar de MBE gestuurd worden om te plannen. Voorbeeld:

Wensen waarvoor “Actief” uitgevinkt is

Wensen die inactief gemaakt zijn, gaan nooit opgenomen worden in de planning. Ze zullen dus nooit naar de MBE gestuurd worden om te plannen. Voorbeeld:

Vensters waarvoor “Actief” uitgevinkt is

Vensters die inactief gemaakt zijn, gaan nooit opgenomen worden in de planning. Ze zullen dus nooit naar de MBE gestuurd worden om te plannen. Voorbeeld:

Extra Spreidingen waarvoor “Actief” uitgevinkt is

Zowel “waardespreidingen” als “volgordespreidingen” kunnen op non-actief gezet worden. Deze spreidingen worden nooit naar de MBE gestuurd. Voorbeeld:

Resources waarvoor “Actief” uitgevinkt is

Resources zijn Leerkrachten, Klassen, Lokalen, Vensters, en Varia. Resources op zich zijn geen opdrachten (met uitzondering van vensters) maar participeren in opdrachten en beperkingen allerhande. Men kan deze resources inactiveren. Overal waar de resource gebruikt wordt, is hij ~~doorstreept~~. Voor een inactieve resource hoeft geen rooster gemaakt te worden. Inactieve resources moeten beschouwd worden als niet aanwezig. Dus, de inactieve resources worden geschrapt uit alle opdrachten en wensen. Verder worden de spreidingsregels waarin ze vermeld worden als essentieel selectieonderdeel ook op inactief gezet.

Dus, inactieve resources worden nooit in de planning opgenomen. Alle opdrachten, wensen, vensteropdrachten zullen eerst ontdaan worden van inactieve resources. Alle spreidingsregels worden aangepast door de resources te schrappen en indien ze noodzakelijk waren, worden ook die spreidingsregels op inactief gezet.

Voorbeeld: we maken een leerkracht inactief:

In de opdrachten waar hij voorkomt wordt hij doorstreept voorgesteld.

In volgende 2 spreidingen komt deze leerkracht voor en wordt ook hier doorstreept. Omdat hij in de eerste spreiding essentieel is, wordt de spreiding zelf op inactief gezet.

Groepen van Resources waarvoor “Actief” uitgevinkt is

Groepen van resources inactief maken heeft als effect dat, op de plaats waar die groepen gebruikt worden, het is alsof de groep er niet meer staat. Ze worden ook doorstreept voorgesteld. Dit heeft hetzelfde effect op opdrachten en spreidingsregels als inactieve resources. Omdat groepen zelf geen resources zijn, heeft het verder geen effect. Het is niet omdat een groep inactief gemaakt wordt dat de resource binnen de groep inactief zouden zijn. Toch wel een essentieel verschil.

Als men alle resources binnen een groep inactief maakt dan is het gevolg dat ook de groep zelf inactief zal zijn.

Betekenis van de kleuren en cijfers in de kolom “%geroosterd”

Een opdracht is maar geplaatst in het rooster als al zijn deelopdrachten of blokken een plaats gevonden hebben in het rooster. Dit veld “%geroosterd” geeft aan hoeveel % er van de opdracht geplaatst werd. Een kleurcode in de cel geeft ook aan of er inactieve resources en/of niet geplaatste actieve resources zijn. De codering werkt als volgt in deze cel:

Het percentage duidt op het aantal geplaatste t.o.v. de gevraagde uren. Een opdracht kan enkel geplaatst zijn als er minstens 1 resource geplaatst is, anders kan je niet spreken over een plaatsing. De achtergrondkleuring wordt op de volgende manier bepaald:

BLANCO: 100% geplaatst, alle resources in de opdracht zijn actief, alle resources zijn geplaatst. (vb: ID37)
ORANJE: <100% geplaatst, alle resources in de geplaatste deelopdrachten zijn actief, alle resources in de geplaatste deelopdrachten zijn geplaatst.
(vb: ID42. Hier gaat het om een opdracht waar maar 3 van de 4 blokjes geplaatst werden met als resultaat de waarde 75%.)
ROOD: er is minstens één niet geplaatste actieve resource in minstens één geplaatste deelopdracht.
(vb: ID31. Hier gaat het om een OF-groep van varia types X en Y. Y was gekozen maar is achteraf inactief gemaakt. X schiet dan nog over maar is niet geplaatst.)
GEEL: er is minstens één niet actieve resource in minstens één geplaatste deelopdracht.
(vb: ID45. Hier gaat het om lokaal A37 dat inactief gemaakt werd.)
Leeg: de opdracht moet niet geroosterd worden (het vlagje “Roosteren” is uitgevinkt). (vb: ID33)

Volgend scherm toont een aantal voorbeelden voor “% geroosterd”:

Resources kunnen op verschillende manieren inactief worden gezet door de gebruiker:

Individuele Elementen en of groepen van elementen op non-actief zetten (doorstreept voorgesteld) via hun respectievelijke tabbladen.
Via “Opties | Roosteren” bepaalde categorieën van resources inactief maken

Speciaal geval: als alle elementen van een actieve groep inactief zijn, dan kunnen we de groep als inactief beschouwen.

Voorbeeld met keuzelokalen:

In het optie tabblad zetten we “Keuzelokalen meeroosteren” uit.

Daarna plannen we alle opdrachten. Het resulterend beeld zou er als volgt kunnen uitzien:

Alle opdrachten die keuzelokalen hadden, hebben nu een gele kleur in het veld “%geroosterd”. De opdrachten die enkel vaste lokalen hebben, hebben een blanco achtergrondkleur.

Nu zetten we “Keuzelokalen meeroosteren” weer aan en kijken naar het resultaat in het opdrachten tabblad:

Alle opdrachten die keuzelokalen gebruikten, zijn nog steeds voor 100% geroosterd maar de rode kleur geeft nu aan dat er in die opdrachten actieve resources zijn die toch niet geplaatst zijn. Merk op dat opdracht ID45 nog steeds geel is omdat het lokaal A37 nog steeds inactief is.

Plannen we nu weer dan zullen de lokalen geplaatst worden en zal de achtergrondkleur van rood naar blanco gaan.

Als alle resources van een (deel)opdracht plots inactief zijn en de opdracht was wel 100% geplaatst dan zal in dit uitzonderlijke geval toch 0% getoond worden. Er zal dan ook een foutboodschap te zien zijn omdat een opdracht zonder actieve resources niet kan bestaan.

Voor examenopdrachten en toezichten werken deze kleurcodes ook. Een toezicht die in het rooster staat, is 100% geplaatst maar als de toezichter nog niet gekozen is, zal die examenopdracht 100% ROOD zijn.

Roosteren van een subset van de opdrachten met standaardinstellingen (“Plan selectie”)

Via “uitgebreid zoeken” in het Opdrachten tabblad kan men een deel van de opdrachten selecteren. Deze selectiemogelijkheid werd uitgebreid besproken in de sectie “Definiëren van opdrachten“. Indien de gebruiker niet alle opdrachten, maar enkel de geselecteerde opdrachten wenst te plannen, kan hij dat doen door de knop “Plan selectie” i.p.v. “Plan” te gebruiken. Bij “Plan selectie” worden enkel de geselecteerde opdrachten opgenomen in de planning. Enkel deze zullen naar de MBE gaan.

Ook hier vertrekken we weer van de situatie waarbij niets gepland is behalve de opdrachten waarvoor “Vast” aangevinkt is. Opnieuw is het geen vereiste om van een niet gepland rooster te vertrekken. Bij wijze van voorbeeld selecteren we in uitgebreid zoeken de volgende klassen:

In het menu “Start | Plannen” ziet met de knop “Plan selectie”. Het is via deze knop dat men de MBE laat starten met als input alle geselecteerde actieve opdrachten en beperkingen. Omdat de standaardinstellingen voor de MBE gekozen werden, zal de MBE nu naar een oplossing zoeken voor het gestelde probleem via standaard stuurinstructies. We openen het planbord en kiezen Klassen/Roosterpunten op de assen. Omdat uitgebreid zoeken actief is, zien we enkel de geselecteerde klassen en enkel indien er iets voor gepland is. Opnieuw zien we nu enkel de “vaste” opdrachten.

We kiezen “Plan selectie”. We krijgen volgend confirmatiescherm en drukken op “OK”:

Net zoals bij “Plan” krijgen we ook het progress scherm te zien met de stappen “Parser”, “Engine”, “Plan”, en “Inlezen”. Volgend plaatje toont het resultaat nadat de MBE klaar is. Alles is 100% geplaatst maar deze keer zien we inderdaad dat het om een veel kleiner aantal opdrachten gaat. We hebben nu 195 opdrachten geplaatst. Merk op dat het aantal wensen en vensters gelijk gebleven is. Dit heeft te maken met de standaardopties voor het roosteren. Daar staat vermeld dat bij “Plan selectie” steeds alle leerkrachtwensen en alle vensteropdrachten meegenomen moeten worden.

Het resultaat is onmiddellijk zichtbaar in de verschillende tabbladen. Het planbord, wat voorheen enkel de vaste opdrachten toonde voor de geselecteerde klassen, toont nu een vol rooster voor elk van de geselecteerde klassen.

Net zoals bij “Plan” kunnen we ook in de andere tabbladen het resultaat van een “Plan selectie” zien.

Wissen van conflicterende opdrachten en verwijderen van niet geplande opdrachten

In het menu “Tools” kan men volgende opties vinden:

Wis planning
Wis niet-geplande uren
Wis conflicterende wensen
Wis conflicterende optimalisaties

Wis planning

via “Wis planning” kan men de opdrachten die bij bepaalde resources horen uit de planning halen. De opdrachtdefinitie wordt hierdoor normaal niet aangepast. De geplaatste opdrachten worden gewoon als niet gepland aanzien en dus uit het rooster gehaald. Men kan dit in bulk doen via deze popup die vraagt voor welke resources en voor welk tijdsinterval in het rooster dit moet gebeuren.

Vaste opdrachten:

Enkel opdrachten die niet “Vast” staan, kunnen gewist worden uit de planning. Wenst men ook vaste opdrachten (die per definitie in het rooster staan) te wissen uit de planning, dan zal men hiervoor eerst het vlagje “Vast” moeten uitvinken.

Als 2 klassen in een opdracht staan en men vraagt om maar 1 klas te wissen:

Via de optie “Splits opdrachten op klas indien klassen slechts gedeeltelijk worden gewist” kan men ervoor kiezen om die opdrachten eerst op klas te splitsen. De klassen die dan nog wel in het rooster moeten blijven, krijgen dan een aparte opdracht. Dit past dus in wezen de opdrachtdefinities aan. Voor andere resourcetypes bestaat deze splits-optie niet.

Als het tijdsinterval een blok splitst:

Stel dat men vraagt om alles te wissen van 1La in het tijdsinterval [ma1, ma3] en 1La heeft een blok van 4 uur staan op ma1 dan gaat de opdracht gedeeltelijk uit de planning gehaald worden zonder dat de opdracht op zich aangepast wordt. Van die 4 uur gaan er dan nog 2 uur als gepland in het rooster blijven staan. Dit zijn situaties die men best vermijdt.

Wis planning via rechtermuisklik op een opdracht:

Selecteert men een opdracht in het “Opdrachten” tabblad dan kan men via rechtermuisklik ook “Verwijderen | Planning” of “Verwijderen | Blok” kiezen. Deze opties hebben hetzelfde effect in die zin dat ze een volledige opdracht of een deel van de opdracht (blok) uit de planning verwijderen. Wat men niet kan via deze rechtermuisklik is een deel van een geplaatst blok verwijderen uit de planning.

Wis niet-geplande uren

Wenst men opdrachten effectief uit het bestand te verwijderen (opdracht verwijderen) dan kan men dat via deze actie doen. Alle opdrachten die niet geplaatst zijn, zullen uit het bestand verwijderd worden. Dit kan aanzien worden als een opschoonactie van het bestand. De enige opdrachten die nog overblijven zijn de geplande opdrachten.

Vaste opdrachten:

Per definitie kunnen opdrachten die “Vast” staan, niet verwijderd worden. Vaste opdrachten zijn immers altijd gepland.

Deelopdrachten:

Indien een deel van een opdracht gepland is en een ander deel niet dan zal enkel het deel dat gepland was overblijven. De opdrachtdefinitie wordt dan aangepast.

Wis conflicterende wensen

Wenst men na het roosteren van een bestand nog leerkrachtwensen toe te voegen om individuele roosters te verbeteren dan kan men de techniek van het incrementeel roosteren gebruiken. Men vertrekt dan van een rooster dat helemaal of grotendeels gepland is. Men voegt enkele wensopdrachten toe (“Opdrachten | Wensen”) en men wil die via incrementeel rooster mee plannen in het reeds geplande rooster. We weten niet of de MBE daarin zal slagen maar wat men vooral niet wil is dat bijvoorbeeld lesopdrachten opgeofferd worden, uit de planning gehaald worden, ten voordele van een dergelijke wensopdracht.

Bij incrementeel roosteren vertrekt Mondriaan van een gedeeltelijk opgelost rooster. Wat Mondriaan naar de MBE stuurt als zijnde “reeds opgelost” moet voldoen aan alle opgelegde eisen en kan dus geen conflicten bevatten. Als men aan een bestaand rooster een wens toevoegt dan gaat Mondriaan die misschien al in het rooster geplaatst hebben maar op een plaats die conflicterend is. Om geen conflicten naar de MBE te sturen, gaat Mondriaan alle conflicterende opdrachten, en dus mogelijks ook conflicten tussen nieuwe wensen en eerder geplaatste lesopdrachten, uit de planning halen. De MBE krijgt dan naast die nieuwe wensen ook de uit de planning gehaalde lesopdrachten om ook die opnieuw te plaatsen. Dat is het moment waarop het mis kan lopen. Mondriaan zou in dit geval bijvoorbeeld de wens kunnen plaatsen maar een aantal lesopdrachten niet meer.

Om dat scenario te vermijden bestaat de knop “Wis conflicterende wensen”. Het enige wat die knop doet, is nagaan of er wensen zijn die conflicteren met lesopdrachten. Als dat het geval is, worden die wensen uit de planning gehaald en gaan dus naar de MBE als niet gepland. Het resultaat is dat alle lesopdrachten die eerder gepland waren niet meer uit het rooster gehaald kunnen worden ten voordele van die wensen.

Wis conflicterende optimalisaties

Wenst men na het roosteren van een bestand leerkrachtroosters verder te optimaliseren via optimalisatieopdrachten die men manueel aanmaakt, dan kan me hetzelfde probleem tegenkomen als bij het incrementeel bijroosteren van wensen. Om te vermijden dat geplaatste opdrachten ten koste van optimalisatieopdrachten uit de planning gehaald zouden worden bij incrementeel bijroosteren van optimalisatieopdrachten kan men via deze actie (“Wis conflicterende optimalisatie”) alle conflicterende optimalisatieopdrachten uit de planning halen.

Zie ook Optimaliseren van leerkrachtroosters.

Nog enkele weetjes en verschillen tussen “Plan” en “Plan selectie” met dezelfde standaardopties

De niet geselecteerde opdrachten zullen na het plannen ook niet gepland zijn

Bij “Plan selectie” is het de bedoeling om een subset te plannen en enkel het resultaat van deze oefening te bekijken als resultaat. Als het resultaat van deze planning terugkomt van de MBE dan wordt dit resultaat in isolatie getoond. Alle niet geselecteerde opdrachten staan dan ook niet in het rooster. Eén uitzondering op deze regel zijn de “Vaste” opdrachten.

Alle “vaste” opdrachten blijven gepland, ook als ze niet mee geselecteerd werden in “Plan selectie”

Vaste opdrachten (door gebruiker vastgezet) staan altijd in het rooster, ook als ze niet mee gepland worden in een “Plan selectie”. In de standaardopties wordt vermeld dat “Vaste” opdrachten steeds meegenomen worden, onafhankelijk van de selectie die men wenst te plannen. Moest de gebruiker kiezen om deze optie uit te zetten, dan gaan ze niet mee en kan de MBE er dus ook geen rekening mee houden. Het gevolg kan zijn dat in dat geval het resultaat van de MBE conflicteert met de vaste opdrachten die niet meegenomen worden in de planning. De reden is duidelijk, “Vaste” opdrachten staan altijd in het rooster, of ze nu door de MBE gepland worden of niet.

“Plan selectie” wordt enkel gebruikt om deelproblemen te onderzoeken, nooit om een oplossing te bekomen voor het ganse rooster

Omdat “Plan selectie” per definitie enkel een subset van de opdrachten gaat plannen, en de niet geselecteerde opdrachten als “niet gepland” achterblijven, kan het niet gebruikt worden om een volledig rooster te plannen. Ook het in stukken oplossen van het rooster gaat niet via “Plan selectie”. Er zijn technieken voorhanden om een partiële oplossing van het rooster verder uit te breiden tot een volledige oplossing maar dat gaat niet via “Plan selectie”, dat gaat ook via “Plan” maar dan met de juiste instellingen in de opties. Wordt verder behandeld.

Men selecteert enkel lesopdrachten bij “Plan selectie”, wensen, spreidingsregels, vensteropdrachten, etc gaan automatisch mee

Via uitgebreid zoeken selecteert men enkel opdrachten uit het opdrachtentabblad. Andere aspecten die invloed hebben op het rooster worden via opties bepaald.

Indien er spreidingsregels zijn waaraan de geselecteerde opdrachten moeten voldoen, dan worden die spreidingsregels automatisch meegenomen. Men hoeft ze dus niet apart te selecteren. Dit is zo met standaardopties. Men kan ze wel uitschakelen via de opties.
De standaardopties stellen dat vensteropdrachten altijd worden meegenomen, onafhankelijk van de selectie van opdrachten. Via de opties kan men dit uitschakelen.
De standaardopties stellen dat leerkrachtwensen altijd worden meegenomen, onafhankelijk van de selectie van opdrachten. Via de opties kan men dit uitschakelen.

Bestanden die de MBE op de achtergrond aanmaakt tijdens het plannen

De MBE wordt aangestuurd door Mondriaan om een bepaalde opdracht uit te voeren. Normaal heeft de gebruiker geen nood aan het bekijken van de bestanden die de MBE op de achtergrond gebruikt of aanmaakt. Uitzonderlijk kan het echter nuttig zijn om bepaalde bestanden te consulteren.

Alle bestanden die de MBE aanmaakt, kan men steeds vinden onder een centrale folder die per gebruiker wordt aangemaakt. Volgend beeld toont de folder voor de gebruiker “Peter”. De folder “Peter” kan men vinden onder de folder “Users” of “Gebruikers”, afhankelijk van de taalinstelling van de computer. Onder de folder “Peter” vindt men dan de folder “Appdata\Local\Mondriaan\Content“. Elke keer dat Mondriaan de MBE aanstuurt, wordt er onder deze folder een technische folder aangemaakt. In het beeld ziet men op dit moment 4 van dergelijke folders staan. De meest recente heeft in dit voorbeeld de naam “15472dat2”. Van zodra men Mondriaan afsluit, worden die technische folders verwijderd.

De structuur onder deze technische folders ziet er steeds hetzelfde uit. In volgend voorbeeld werd de meest recente technische folder opengeklapt. Folders die voor de geïnteresseerde gebruiker nuttig kunnen zijn:

Dump: informatie over gefaalde opdrachten tijden het plannen.
Log: informatie over de voortgang van de MBE.
Selectie: informatie die tijdens “Analyseer Opdrachten” verzameld wordt. Hiervoor verwijzen we naar de pagina over “Analyseren van opdrachten”.

Merk op dat men onmiddellijk onder de hoofdfolder ook bepaalde bestanden kan terugvinden. De enige waar de gebruiker vanuit Mondriaan mee in aanraking kan komen, is het diagnosebestand (TT_21Diagnose.txt). Hiervoor verwijzen we naar de pagina over “Diagnose en Diagnose selectie”

Dump Folder

Er worden verschillende types bestanden aangemaakt in de Dump folder die allen te maken hebben met het falen van opdrachten tijdens het plannen.

“failed.txt“: bevat een opsomming van alle definitief gefaalde opdrachten tijdens het plannen. Geldig voor zowel Methode 1 als Methode 2.
“Dump.txt“: bij het definitief falen van een opdracht tijdens het plannen met Methode 2 wordt er voor deze gefaalde opdracht een dump bestand gemaakt. Dit bestand bevat alle opdrachten die wel geplaatst waren op het moment dat de opdracht faalde. Het bevat ook wat statistieken over het gebruik van resources in de context van de gefaalde opdracht.
“lastdump.txt“: enkel voor plannen met Methode 2. Heeft dezelfde structuur als de “dump.txt” bestanden maar bevat steeds de context van de meest gevorderde stand. Telkens de MBE een betere oplossing gevonden heeft, wordt in dit bestand vermeld welke opdrachten al geplaatst zijn en met welke volgende opdracht hij bezig is. Omdat genereren van dit bestand vaak tijdrovend is, werd vanaf versie BT19.00.09 ervoor gekozen om enkel de “Member statistieken” steeds te genereren en de opdrachten achterwege te laten. Wenst men ze er toch steeds in te hebben dan kan men dit forceren door de toggle-knop “t” te gebruiken tijdens het plannen met Methode 2.

Indien er tijdens het plannen met Methode 2 opdrachten definitief falen dan zal Mondriaan volgend scherm tonen met de mogelijkheid om de informatie uit deze dump files te bekijken. Drukt men op de knop “Bekijk dump” dan toont Mondriaan een compilatie van alle “dump.txt” bestanden in één scherm.

Log Folder

Er staan 2 types bestanden in deze folder:

“logfile .txt“: in dit bestand schrijft de MBE de voortgang van de stappen die de MBE op vraag van Mondriaan moet uitvoeren.
“anafile .txt“: uitgelegd bij “Analyseren van opdrachten“.

Voorbeeld van de logfile:

Onderaan in de logfile kan men zien hoeveel “Pogingen” de MBE heeft ondernomen om het probleem op te lossen. In dit voorbeeld heeft de MBE 1.130 opdrachten moeten plannen en heeft hiervoor 11.934.735 pogingen voor uitgevoerd. Hij heeft voor die pogingen 37 seconden nodig gehad. Onderaan in het logbestand kan men ook nog zien hoeveel tijd de MBE over de volledige opdracht gedaan heeft. In dit geval ging het over 20 keer kennis vergaren en het plaatsen van het rooster met Methode 2 op diepte 4.

Selectie Folder

Informatie die tijdens “Analyseer Opdrachten” verzameld wordt. Hiervoor verwijzen we naar de pagina over “Analyseren van opdrachten”.

Meer details over de getoonde informatie in de logfile en op het MBE scherm (gevorderd!)

In dit hoofdstuk gaan we wat dieper in op de informatie die getoond wordt tijdens het plannen in het MBE scherm (blauwe scherm) en de informatie die tijdens het plannen in de logfile weggeschreven wordt. De informatie die hier beschreven wordt, is nuttig voor een geoefende gebruiker die wat meer achtergrond wenst over wat er achter de schermen gebeurt. Het is dus niet nodig om deze zaken te kennen om Mondriaan goed te kunnen gebruiken.

Om een en ander te illustreren vertrekken we van een bestand dat we plannen via o.a. deze Engine opties:

Vervolgens plannen we het bestand in zijn totaliteit.

Informatie die getoond wordt tijdens de opstart van de MBE

Men ziet de versie van de MBE. In dit geval versie “BT v18.00.15”, een 64bit versie van de MBE. Tijdens het inladen van het “*.OUT” bestand, waarin alle opdrachten staan die de MBE moet uitvoeren, wordt voldoende computergeheugen gereserveerd, nodig om de MBE zijn zoektocht te laten beginnen. In dit geval ziet men een “MEMORY CONSUMPTION” van 54.266.438 bytes (ongeveer 52MB). Dit op voorhand gereserveerde geheugen blijft vrijwel constant tijdens de uitvoer van de MBE.

De eerste taak van de MBE is het vergaren van kennis over alle te plaatsen opdrachten. In het voorbeeld zijn er 1.356 opdrachten te plaatsen. Van deze 1.356 zijn er 1.321 effectief te plaatsen, de rest (35) zijn opdrachten die al een vaste plaats in het rooster hebben en dus niet geplaatst of verplaatst moeten worden. De MBE gaat nu eerst met deze 1.321 opdrachten kennis vergaren.

Opmerking: Vanaf versie BT19.00.09 ziet het opstarten er iets anders uit. Dit heeft te maken met een nieuwe parser die gebruikt werd om de OUT-file in de MBE in te laden. Men ziet nu tijdens het laden van de data de voortgang die de parser maakt.

Getoonde informatie tijdens kennis vergaren

Kennis vergaren begint bij “Start Calculating Difficulties”. We hebben ervoor gekozen om 20 keer kennis te vergaren met een zoekdiepte van 4 (en een startdiepte van 1). De eerste iteratie begint met “1 Randomize” (verder zal het dan 2, 3, … 20 worden). De 1.321 te plaatsen opdrachten worden in een willekeurige volgorde in de oplossingsruimte gebracht met een zoekdiepte “Depth 4 0”. Die “0” heeft geen betekenis voor kennis vergaren. Men ziet dat er 2 x “Depth 4 0” staat. Dit heeft te maken met de indeling van opdrachten volgens een bepaalde prioriteit. Een klein aantal opdrachten krijgen erg hoge prioriteit en worden in het rooster geplaatst voor alle andere. Deze prioriteit kan zowel door Mondriaan zelf bepaald zijn of kan door de gebruiker bepaald zijn. Voor elk prioriteitsniveau zal men een aparte planning zien. In dit geval zijn er 2 niveaus. Er zijn blijkbaar een 7-tal opdrachten met de hoogste prioriteit, de rest heeft een lagere.

Betekenis van de puntjes, uitroeptekens en kruisjes:

Kennis vergaren gebeurt met Methode 1. Wat we hier vertellen is dus meteen ook waar voor het gewone plannen met Methode 1. Als de MBE tijdens het plannen opdrachten probeert te plaatsen, dan wordt tijdens dit proces de voortgang op het scherm getoond als volgt:

Puntje (‘.’): er werd een opdracht succesvol in het rooster geplaatst.
Uitroepteken (‘!’): via de huidige zoekdiepte lukte het niet om de opdracht te plaatsen, de MBE verhoogt de zoekdiepte en probeert opnieuw. Dit kan maar zolang de zoekdiepte kleiner of gelijk is aan de maximale zoekdiepte van 4. We beginnen voor elke opdracht steeds te zoeken met een startdiepte van 1 en gaan tot maximaal 4 (volgens de instellingen in het optietabblad van de MBE).
Kruisje (‘X’): het is niet gelukt om de opdracht in het rooster te plaatsen, ook niet op de maximale zoekdiepte 4.

Enkele voorbeelden, telkens voor één opdracht die bijkomend in het rooster geplaatst wordt:

‘.’: de opdracht werd meteen in het rooster geplaatst met zoekdiepte 1.
‘!.’: de opdracht kon enkel geplaatst worden door de zoekdiepte te verhogen naar 2.
‘!!!.’: de opdracht kon enkel geplaatst worden door de zoekdiepte te verhogen naar 4.
‘!!!X’: de opdracht kon zelfs met zoekdiepte 4 niet geplaatst worden.

Merk op dat een ‘!’ een verhoging van de zoekdiepte weergeeft. Indien men in de MBE opties een diepte 4 met een startdiepte 3 zou opgegeven hebben dan zal een gefaalde opdracht aangeduid worden met ‘!X’. Hij begint op 3, doet één verhoging naar 4 en dan faalt hij.

Telt men het aantal puntjes dan heeft men het aantal geplaatste opdrachten, telt men het aantal kruisjes dan heeft men het aantal gefaalde opdrachten.

Na elke iteratie van het kennis vergaren toont de MBE hoeveel opdrachten hij met de gekozen instellingen in het rooster kon plaatsen. In het getoonde voorbeeld hebben we voor de 5de iteratie een score van 1.274/1.321, wat overeenkomt met 96,44 % van de opdrachten (zonder de vaste opdrachten). Vervolgens wordt er een aanduiding gegeven van het “Aantal Pogingen” die de MBE heeft moeten ondernemen om al deze opdrachten te plaatsen. In dit geval waren het er 532.307. Wat “Aantal Pogingen” juist betekent, wordt hier niet verder uitgelegd maar men kan onthouden dat het een maat van complexiteit is om het probleem op te lossen.

Tijdens het kennis vergaren wordt ook de logfile bijgewerkt. De 5de iteratie van het kennis vergaren werd hier rood omkaderd:

Voor elke iteratie zien we ook in de logfile het aantal geslaagde opdrachten, een percentage en het aantal pogingen.

Afsluiten van het kennis vergaren en opstarten van het echte zoekwerk via M2

In de opties hebben we 20 keer kennis vergaren gevraagd. De MBE gaat echter nog een 21ste run doen met een zoekdiepte van 5. Hier heeft men geen invloed op via de MBE opties. De MBE doet dus één extra run met één extra level in de zoekdiepte. Tijdens deze 21ste iteratie gaat de MBE de informatie van de eerste 20 iteraties nog eens combineren in de hoop een nog betere inschatting te kunnen maken van de complexiteit van elke opdracht. In de hier getoonde afbeelding van de logfile ziet men inderdaad dat die laatste iteratie wat langer duurt dan de vorige en dat ook het aantal pogingen veel hoger ligt. In totaal heeft het vergaren van kennis hier “0h 7m 58s” geduurd. De informatie over de complexiteit van de opdrachten werd in “POS\TT_20Kennis.pos” weggeschreven. Die informatie wordt vervolgens gebruikt voor het effectieve plannen via Methode 2.

Methode 2 wordt hier opgestart met een zoekdiepte van 4, een startdiepte van 1 en een extra zoekdiepte van 1. In het MBE scherm ziet het opstarten van Methode 2 er als volgt uit:

Bij Methode 2 (M2) wordt er heel anders gerapporteerd in zowel het scherm als in de logfile. Hierover dadelijk meer.

Het grote verschil tussen M2 en M1 is dat bij M2 het falen van een opdracht niet onmiddellijk definitief is. Als een opdracht faalt, wordt er geprobeerd om ze alsnog te plaatsen binnen de context van een kleinere set reeds geplaatste opdrachten die op hun beurt eventueel wat door elkaar geschud worden. Pas als die steeds kleiner wordende set aan geplaatste opdrachten, waar de MBE de gefaalde opdracht tracht aan toe te voegen, té klein wordt, wordt er beslist om de gefaalde opdracht definitief te verwijderen. Uitstel van executie kan eventueel bekomen worden door de extra recursiediepte van “1” te gebruiken. Als normaal beslist zou worden om de gefaalde opdracht definitief te verwijderen, maar er is nog een extra recursiediepte die gebruikt kan worden, dan zal de MBE dat ook doen. Standaard staat die extra op 1. Zet men die op bijvoorbeeld 2 dan kan een individuele opdracht tot +2 gaan om toch geplaatst te worden.

Terug naar het MBE scherm. We zien na “End Calculating Difficulties” dat de MBE weer begonnen is met het selecteren van opdrachten die hij nu via M2 moet plaatsten. Het zijn opnieuw diezelfde 1.356 opdrachten waarvan 35 vaste en 1.321 niet vaste die geplaatst moeten worden. Omdat ook bij M2 met prioriteiten rekening gehouden wordt, zullen eerst de 7 opdrachten met de hoogste prioriteit geplaatst worden. Het is subtiel, maar het sterretje (‘*’) onder de zin ‘1321 Atom rules selected out of 1356 Atom rules’ is de indicatie dat M2 afgelopen is voor die 7 opdrachten. Blijkbaar zonder dat er een faling opgetreden is en dit in de context van de vaste opdrachten die niet meegeteld worden. Telkens de MBE een set opdrachten via M2 moet plaatsen, zal na het einde ervan dit sterretje verschijnen. In het voorbeeld zijn er 2 sets, een van 7 opdrachten met prioriteit 1 en 1.314 met prioriteit 2. Een volgende set wordt steeds geplaatst in de context van de vorige set.

De eerste regel die de MBE toont is de volgende:

–200000519–260000519 -> (1, 0, 790)

Betekenis van deze lijn:

De eerste 2 lange cijfers zijn een identificatie van een blokje dat geplaatst moet worden in het rooster. Het eerste cijfer (begint met 20) stelt een opdracht (of deelopdracht, of venster) voor. Het tweede cijfer (begint met 26) stelt een elementaire opdracht (of blokje, of Atom Rule) voor dat geplaatst moet worden. Heeft men bijvoorbeeld een opdracht van 4 losse uren WIS dan hebben die allemaal hetzelfde ’20’ nummer maar alle 4 zullen ze een ander ’26’ nummer hebben. Deze identificatie wordt door Mondriaan toegekend en men kan deze identifiers in tal van bestanden terugvinden (de OUT file, log files, dump files, positie files, kennis files, etc). Merk op dat 1.321 te plaatsen opdrachten dus in feite te plaatsen blokjes zijn. We gebruiken de termen blokjes en opdrachten hier soms door elkaar, maar het verschil zal hopelijk wel duidelijk zijn.
De opdrachten die op het scherm verschijnen zijn hier, bij M2, gefaalde opdrachten (blokjes). Dit betekent niet dat ze definitief gefaald zijn. Dit betekent enkel dat ze opnieuw geprobeerd gaan worden binnen een kleinere context van geplaatste opdrachten.
Het 3de cijfer tussen haakjes (1, 0, 790) zegt dat de context, waarbinnen de opdracht gefaald is, 790 andere opdrachten bevatte. Dus, binnen een context van 790 reeds geplaatste opdrachten, kan deze er niet meer bij. Een volgende poging zal vertrekken van een kleinere set, eventueel gereorganiseerd, om de gefaalde toch geplaatst te krijgen.
Het 2de cijfer tussen haakjes (1, 0, 790) zegt dat de gefaalde opdracht nog geen “extra recursiediepte (of extra zoekdiepte)” toegewezen gekregen heeft toen het faalde. Dat cijfer zal voor deze opdracht pas ophogen als de kleinst aanvaardbare context geprobeerd werd. Per gefaalde opdracht worden deze extra dieptes toegekend. Op een bepaald moment, zie verder, kan deze extra diepte weer afgenomen worden.
Het 1ste cijfer tussen haakjes (1, 0, 790) zegt dat de gefaalde opdracht nog maar één keer gefaald is. telkens de opdracht faalt zal dit cijfer verhogen. Op een bepaald moment, zie verder, zal dit cijfer terug op 0 gezet worden.

Dus, de MBE is begonnen met het plaatsen van 1.314 opdrachten (lees blokjes) en heeft er zonder reorganisatie de eerste 790 kunnen plaatsen. Omdat de MBE verder opgeschoten is dan ooit (lees: méér opdrachten geplaatst dan bij de vorige faling) gaat hij een tussenresultaat wegschrijven. Dit wordt aangeduid door “Dumping Rules!”. Telkens dat gebeurt, zou Mondriaan dit tussenresultaat kunnen inlezen. Als men de MBE onderbreekt, gaat Mondriaan ook dit tussenresultaat inlezen en kan men in principe verder werken met dit tussenresultaat. Na “Dumping Rules!” (MBE is verder geraakt dan ooit) worden de eerste 2 cijfers tussen haakjes gereset.

Om verder te kunnen moet de MBE de gefaalde opdracht (200000519-260000519) binnen een gewijzigde, kleinere context trachten te plaatsen. Die context wordt bepaald en opnieuw hebben we een faling. Vanaf nu staat er voor elke opdracht die faalt extra info tussen haakjes:

(0-790-1314)-200000519–260000519 -> (1, 0, 749)

Betekenis van deze lijn:

Het 1ste cijfer tussen de haakjes (0-790-1314) zegt hoeveel opdrachten er tot nu toe definitief gefaald zijn. Met definitief bedoelen we echt uit het rooster gehaald: deze opdrachten zullen niet meer geplaatst worden in deze run van de MBE.
Het 2de cijfer tussen haakjes (0-790-1314) is het maximaal aantal opdrachten die de MBE tot nu toe tegelijk heeft kunnen plaatsen. Die 790 komt niet toevallig overeen met wat we eerder uitgelegd hebben over de eerste lijn.
Het 3de cijfer tussen haakjes (0-790-1314) is het aantal opdrachten (blokjes) dat nog in de running is. Als er geen opdrachten definitief falen, dan zal dit steeds 1.314 blijven. Als er echter wel zouden falen, dan zal dit cijfer zakken. De som van de definitief gefaalde opdrachten + de opdrachten die nog in de running zijn, blijft constant en is gelijk aan 1.314.
De gefaalde opdracht blijkt opnieuw dezelfde opdracht te zijn (200000519-260000519). De MBE is er niet in geslaagd deze te plaatsen in een kleinere, gewijzigde context. Die context bevatte ondertussen 749 opdrachten.

Een volgende poging is nodig om de gefaalde opdracht in een nog kleinere, gereorganiseerde context te plaatsen. De MBE doet dit en in de volgende lijnen rapporteert de MBE het volgende:

(0-790-1314)-200000264–260000264 -> (1, 0, 798)
Dumping Rules!
(0-798-1314)-…

Blijkbaar is het gelukt om opdracht (200000519-260000519) te plaatsen in een kleinere context, meer nog, na dit succes werden er nog een heel deel opdrachten bijgeplaatst tot we een context hadden van 798 geplaatste opdrachten. Het toevoegen van de volgende opdracht (200000264-260000264) was niet succesvol. Omdat de MBE verder geraakt is dan ooit zien we “Dumping Rules!”. Op de derde lijn wordt nu (0-798-1314) geschreven. Tot nu toe hebben we 798 van de 1.314 opdrachten kunnen plaatsen en er is nog geen enkele definitief gefaald. Opdracht (200000264-260000264) zal nu in een kleinere (<798) en gereorganiseerde context opnieuw geprobeerd worden. We zien hem eerst op 762 opnieuw falen, vervolgens op 757. Vervolgens, in een nog kleinere context van 722, faalt een andere opdracht (200000265-260000265). Na weer verdere reorganisatie om die er weer in te krijgen slaagt de MBE er in om naar 849 te evolueren. Hier zal dan weer een “Dumping Rules!” op volgen omdat hij nooit verder geraakt was.

In de logfile wordt dit ook gerapporteerd maar dan enkel wanneer de MBE “Dumping Rules!” doet en dus verder geraakt is dan ooit. We bekijken hetzelfde voorbeeld:

Telkens de MBE verder geraakt dan ooit wordt er een lijn geschreven. Deze komen overeen met wat we eerder in het MBE scherm zagen. In de logfile staat als identificatie van de gefaalde opdrachten enkel het ’20’ nummer. Om toch wat meer onmiddellijke duiding te geven, worden ook een aantal elementen van die opdracht getoond. Omdat de MBE vanuit Mondriaan niet enkel gevoed wordt met resources, vakken, etc. die de gebruiker opgeeft, maar ook met technische elementen die Mondriaan toevoegt, kan die opdracht er hier wel wat complex uitzien. Echter, de gebruiker die dit wenst te bekijken, zal zonder problemen zijn opdrachten herkennen.

De eerste 3 cijfers tussen haakjes komen overeen met wat we eerder zagen, maar de vorm is net iets anders.

(0, 790, 1314) (J: 0) gefaald O: 200000519 ENG LES SYS_SELECTIE VT_AV … F209
(0, 798, 1314) (J: 1) gefaald O: 200000264 LAT LES SYS_SELECTIE VT_AV … F117
(0, 849, 1314) (J: 3) gefaald O: 200000003 HHK_VOE LES PR_HHK_VOE … E1

Merk op dat we hier al bij de eerste gefaalde opdracht de 3 cijfers zien (0, 790, 1314). Maar ook deze weergave is correct.

Opdracht (200000519) faalt in de context van 790 geplaatste opdrachten.
Opdracht (200000264) faalt in de context van 798 geplaatste opdrachten.
Opdracht (200000003) faalt in de context van 849 geplaatste opdrachten.

Betekenis van (J: xxx) bij de gefaalde opdracht:

Telkens de MBE verder geraakt dan ooit schrijft hij een lijn weg in de logfile. Om verder te geraken dan ooit, heeft de MBE de gefaalde opdracht die in de vorige lijn gerapporteerd werd, moeten plaatsen door één of meerdere reorganisaties van de geplaatste context te doen. Bekijken we de 3de lijn in het voorbeeld. Die 3de lijn is er gekomen nadat de gefaalde opdracht uit lijn 2 (200000264) succesvol geplaatst werd en er daarna nog wat opdrachten bijgeplaatst werden, zonder de context nog te reorganiseren (lees: zonder dat er nog een opdracht faalde), en ook verder te geraken dan die 798 uit lijn 2. Blijkbaar ging de MBE dan meteen door tot 849 om daar een falende (200000003) tegen te komen. In lijn 3 zien we (J: 3) staan. Die 3 verwijst naar het aantal keer dat de MBE de context heeft moeten verkleinen (en reorganiseren) om alles geplaatst te krijgen.

Dus, vertrekkende van 798 geplaatste opdrachten in de context waarin opdracht (200000264) niet te plaatsen viel, heeft de MBE 3 reorganisaties van de context moeten doen (j: 3) om opdracht (200000264) geplaatst te krijgen en als bonus zijn er dan nog eens een deel bijgeplaatst om op 849 te stranden met de volgende faling. De indicatie (J: 3) in lijn 3 geeft dus weer hoe lastig het was om de gefaalde opdracht in lijn 2 te plaatsen.

Deze indicatie kan dus een hint zijn over de complexiteit van het plaatsen van de laatst gefaalde opdracht in de context die dan bestaat. Bekijk in de logfile het voorbeeld met (J: 134). Het is de opdracht die op 880 gefaald is (200001143) die ervoor gezorgd heeft dat er 134 reorganisaties nodig waren om hem te plaatsen.

Merk op dat het aantal reorganisaties die men ziet in (J: xxx) overeenkomt met het aantal lijnen dat men in het MBE scherm ziet (-1) tussen 2 “Dumping Rules!”.

Merk op dat in de logfile ‘gefaald O‘ verwijst naar een Opdracht en dat ‘gefaald V‘ verwijst naar een Venster.

Nog een paar voorbeelden:

We vertrekken van 1.067 als meest geplaatste opdrachten in de context. De MBE probeert de toen gefaalde opdracht te plaatsen. Door het reorganiseren en verkleinen van de context zal de MBE ook vaak opdrachten die al eerder geplaatst waren, opnieuw een plaats moeten geven. Zie bijvoorbeeld de poging om opdracht (200000411) te plaatsen in een steeds verder krimpende context. Plots heeft de MBE de oplossing gevonden en geraakt tot 1.073 waarna een “Dumping Rules!” volgt. In de logfile hieronder zie je dat (J: 439) bij deze “Dumping Rules!” hoort. Dus, om van 1.067 naar 1.073 te geraken heeft de MBE 439 reorganisaties moeten doen. Dat geeft een goed beeld van de complexiteit van de geel gemarkeerde opdracht in de context van die 1.067 geplaatste opdrachten. Het is opdracht (200001058) die faalt bij 1.073. Men ziet in het MBE scherm 7 lijnen tot hij geplaatst is op 1.077. In de logfile ziet men (J: 6) staan, wat inderdaad 7 – 1 is.

Files die geschreven worden bij “Dumping Rules!”:

Dump\lastdump.txt
POS\lastdump.pos, laatste POS\TT_22Result.pos

De grootte van de context waarin gewerkt wordt visueler maken voor M2 in het MBE scherm

Tijdens het plannen met M2 krijgt men een idee van de grootte van de geplaatste context, waarbinnen de MBE aan het werken is, door het laatste cijfer achteraan op de getoonde lijnen.

(0-790-1314)-200000519–260000519 -> (1, 0, 749)

Men kan die context ook visueler maken door tijdens het uitvoeren van de MBE op de letter ‘k’ te drukken. De verkleinde en gereorganiseerde context wordt dan als ‘+’ voorgesteld. Elke ‘+’ stelt een geplaatste opdracht voor in de context. In volgende lijn wordt aangegeven waar de [CONTEXT] verschijnt.

(0-790-1314)[CONTEXT]200000519–260000519 -> (1, 0, 749)

Daar waar de puntjes (‘.’) beginnen (na de ‘+’) plaatst de MBE weer opdrachten bij de geplaatste context. Dit gaat goed tot aan het liggende streepje (‘-‘). Op dat moment faalt de opdracht die dan ook getoond wordt.

Drukt men nogmaals op ‘k’ dan krijgt men het beeld zonder de ‘+’ en ziet men enkel de puntjes.

Drukt men vervolgens nog eens op ‘k’ dan verdwijnt de context weer uit het beeld en krijgt men het vertrouwde beeld weer terug.

In de logfile kan men ook zien dat de gebruiker op de ‘k’ drukt. ‘$$ Toggle Kruisjes Zetten’.

Dit heeft weinig toegevoegde waarde, maar weet dat het bestaat.

Dumpen in de logfile van lastige opdrachten die zich in de geplaatste context bevinden voor M2

Tijdens het uitvoeren van een M2 planning kan de gebruiker ervoor kiezen om een dump te doen van lastige opdrachten die zich in de huidige geplaatste context bevinden. Zolang de MBE niet stopt, betekent dit dat er opdrachten falen. Op het moment dat er een opdracht faalt, is dat in de context van geplaatste opdrachten. De gebruiker kan kiezen om op het volgende moment van faling een dump van de ‘lastige’ opdrachten te doen in de logfile.

Wat is een lastige opdracht in die geplaatste context? Een “lastige opdracht” hebben we vrij arbitrair bepaald als een opdracht waarvoor het aantal falingen > 9 is op het moment van de dump. In een poging om verder te geraken dan ervoor, is de MBE constant in de weer met het verkleinen, reorganiseren van de context en het plaatsen van opdrachten. Tussen 2 van dergelijke mijlpalen (“Dumping Rules!”) gaan dezelfde opdrachten veelvuldig kunnen falen. Het zijn de opdrachten die vaak falen, die als lastig aanzien worden. Meer dan 9 falingen is dus de drempel om in de logfile terecht te komen wanneer de gebruiker hier om vraagt.

Het aanvragen van een dump van lastige opdrachten kan op 2 manieren en de moment waarop de dump gemaakt wordt, is ook afhankelijk van de methode:

Ofwel eenmalig door in het MBE scherm op de knop ‘v’ te drukken. Bij de eerstvolgende faling wordt de dump gemaakt.
Ofwel continu door in het MBE scherm op de knop ‘c’ te drukken. Een tweede keer op ‘c’ drukken zal het dumpen doen stoppen. Dit is dus ook een ‘toggle‘ knop. Deze automatische dump wordt enkel gemaakt bij faling indien de MBE verder geraakt is dan ooit (Bij het “Dumping Rules!” moment dus).

Bekijken we een voorbeeld:

We drukken tijdens het plannen op ‘v’ voor een éénmalige aanvraag van een dump op het moment van de eerstvolgende faling. In het MBE scherm verschijnt ‘DUMP CLUSTER IN LOGFILE’.

In de logfile zien we volgende 2 lijnen verschijnen. Blijkbaar was er geen enkele opdracht in de context van 851 geplaatste opdrachten die meer dan 9 falingen had. Er wordt niets uitgeschreven.

Bij een volgende poging waren er wel lastige opdrachten in de geplaatste context. Ze worden allemaal in de logfile geschreven en gesorteerd op aantal keer faling van veel naar weinig. Deze cluster van lastige opdrachten zou een hint kunnen zijn die de gebruiker in staat kan stellen de nodige relaxaties te doen om het geheel meer zuurstof te geven.

De tweede methode (toggle AAN/AF via knop ‘c’) laat toe om gedurende een bepaalde periode bij elke mijlpaal (faling, maar verder geraakt dan ooit) een dump van de lastige opdrachten te doen.

In het MBE scherm ziet men het moment waarop men op de ‘c’ knop drukt. Vanaf nu staat het automatisch dumpen aan.

Het dumpen van lastige opdrachten in de logfile ziet men dan als volgt: bij elke mijlpaal wordt nu gekeken of er lastige opdrachten te dumpen zijn. De eerste keer was het er maar een, de drie volgende keren niets, de vijfde keer was het blijkbaar wel weer lastiger:

Merk hier op dat het opdracht (200001148) was die in de context van 1.093 geplaatste opdrachten erg moeilijk te plaatsen was. De indicatie (J: 5118) geeft aan dat er maar liefst 5.118 reorganisaties van de context nodig waren om deze ene opdracht erbij te krijgen (we zitten nu op 1.094) bij faling. Dat verklaart dan ook het aantal opdrachten die als lastig ervaren worden met falingen tot 33 keer. Om dit te illustreren hebben we de BT op een lage diepte (2) met M2 laten werken. Dat veroorzaakt extra veel falingen en reorganisaties.

Waarschuwing: de logfile kan erg groot worden als men dit de hele tijd laat aanstaan.

Definitief falen van een opdracht met M2

De MBE doet zijn best om binnen de gestelde parameters een oplossing te vinden voor alle opdrachten. Als na alle pogingen om de context te reorganiseren er toch niets uit de bus komt, dan zal er een opdracht opgeofferd worden die op dat moment als moeilijk ervaren wordt binnen de beperkte context waarbinnen op dat moment gewerkt wordt. In onderstaand beeld van de MBE zien we dat opdracht (200000733) binnen een context van slechts 15 andere opdrachten faalt. Deze opdracht is blijkbaar al heel wat keren gefaald. Hier al 15 keer. Ook zijn individuele zoekdiepte was al met 1 verhoogd. We zien het volgende staan:

(0-957-1314)-200000733–260000733 -> (15, 1, 15)X
(1-15-1313)-200000150-260000150 -> (1, 0, 18)
Dumping Rules!

De ‘X’ achteraan de eerste regel geeft weer dat de getoonde opdracht gefaald is. Op de tweede lijn zien we daar waar eerst een 0 stond nu een 1 staan, wat op 1 definitief gefaalde regel wijst. We zien ook dat het aantal te plaatsen opdrachten van 1.314 naar 1.313 gedaald is. We zien ook op de tweede regel dat de indicatie van hoever de MBE al ooit geraakt is, ook verlaagd werd van 957 tot 15. De MBE gaat verder in deze context.

In de logfile ziet de definitief gefaalde opdracht er als volgt uit:

Nog enkele weetjes over de definitief gefaalde opdrachten in andere bestanden:

In de file “\Dump\failed.txt” zullen alle definitief gefaalde opdrachten samengevoegd worden. Dit is zo voor zowel M1 als M2.
In de folder “\Dump” zal men per gefaalde opdracht ook een “Dump.txt” file vinden. De eerst gefaalde opdracht kan men in “Dump1.txt” vinden, de tweede in “Dump2.txt“, etc (komt overeen met het eerste cijfer in (1, 15, 1313) in de logfile). Elke dump-file bevat naast de gefaalde opdracht ook de context van de opdrachten die in de geplaatste context zaten op het moment van faling.

Handige tip: in de dump-files vindt men naast de geplaatste opdrachten in de context en de gefaalde opdracht ook een sectie “Member Statistieken”. Dit is een lijst van alle elementen (vakken, klassen, leerkrachten, lokalen, etc) met daarnaast een cijfer dat aangeeft in hoeveel van deze opdrachten (in de geplaatste context) het element voorkomt. Op basis van deze cijfers kan men zich een beeld vormen van met welke elementen er waarschijnlijk een probleem is.

Dumpen van alle opdrachten die zich in de geplaatste context bevinden in een apart bestand voor M2

Telkens men op het MBE-scherm “Dumping rules!” ziet is de MBE verder geraakt dan ooit en wordt de geplaatste context, de gefaalde opdracht en de “Member Statistieken” in de dumpfile “\Dump\lastdump.txt” geschreven. Indien het erg lang duurt vooraleer de MBE dit punt weer bereikt en de gebruiker toch inzicht wil krijgen in de huidige context waarmee de MBE werkt, kan hij op de knop ‘d’ drukken. Deze actie maakt dezelfde file aan maar dan wel op het moment van de eerstvolgende faling en met de naam “\Dump\ruledump.txt”

De informatie in beide files is op dezelfde manier opgebouwd.

Verhogen van de zoekdiepte van de laatst gefaalde opdracht voor M2

Wenst men manueel, tijdens het roosteren, de zoekdiepte van één bepaalde opdracht te verhogen dan kan dat door op de klop ‘w’ te drukken. Dan pauzeert de MBE en stelt de vraag ‘Increase Recursion? (y/n). De opdracht waarvoor die (y/n) vraag gesteld wordt, is de opdracht die in de lijn net boven die vraag getoond wordt. In dit voorbeeld gaat het over opdracht (200001256-260001323).

We hebben ‘y’ geantwoord en de MBE gaat weer verder. Iets verderop zien we deze opdracht terug falen en zien we ook dat zijn individuele zoekdiepte inderdaad verhoogd was (11, 1, 923).

Opmerkingen:

Men kan de zoekdiepte niet hoger maken dan wat als maximaal via de “Opties | Engine” ingesteld werd.
Gebruik van deze mogelijkheid is zeer uitzonderlijk en kan bij te vaak gebruiken, lijden tot ernstige vertragingen.
Gebruikt men dit, dan is de oplossing niet langer deterministisch omdat men bij een volgende run van de MBE onmogelijk op dat exact zelfde moment deze actie kan uitvoeren.
Dus, het is héél soms handig om iets uit te zoeken, maar zeker niet aan de orde bij normaal gebruik van Mondriaan.

Resetten van het aantal falingen voor alle opdrachten voor M2

Tijdens het verder zoeken van de MBE zien we het eerste cijfer tussen de haakjes achter de opdracht oplopen. Dit cijfer stelt het aantal falingen van die specifieke opdracht voor. De MBE gebruikt deze informatie voor het reorganiseren van de context. De knop ‘r’ doet onmiddellijk een reset van deze tellers en dat voor alle opdrachten.

in het voorbeeld zien we dat na het drukken op ‘r’ de tekst ‘Reset Jump Factors!’ verschijnt en dat vanaf dan de tellers weer gereset zijn.

Opmerkingen:

Gebruikt men dit, dan is de oplossing niet langer deterministisch omdat men bij een volgende run van de MBE onmogelijk op dat exact zelfde moment deze actie kan uitvoeren.
Dus, het is héél soms handig om iets uit te zoeken, maar zeker niet aan de orde bij normaal gebruik van Mondriaan.

MBE scherm voor Methode 1 bij incrementeel bijroosteren

Tot nu toe hebben we vooral M2 schermen gezien. M2 is de krachtigste methode van Mondriaan, vandaar ook de meeste mogelijkheden om in te grijpen. Voor M1, die ook bij kennis vergaren gebruikt wordt, willen we hier enkel nog even de betekenis van de uitroeptekens, puntjes en kruisjes verduidelijken. Om dit te doen, hebben we een M2 resultaat, die niet alle opdracht geplaatst had, gebruikt als startpunt om de niet geplaatste er via M1 incrementeel bij te roosteren. We hebben een erg hoge zoekdiepte van 6 gekozen men als startdiepte 1. Er moeten op deze manier 29 opdrachten geplaatst worden.

Voorbeelden:

‘!!!!!X’: de zoekdiepte werd tot 6 keer verhoogd, maar dat heeft niet geholpen.
‘!!!!!.’: de zoekdiepte werd 6 keer verhoogd en pas bij de laatste verhoging kon de MBE een oplossing vinden.
‘.’: al bij zoekdiepte 1 was er een oplossing.

Pauzeren en terug starten van de MBE via linker en rechter muisklik

Tijdens het uitvoeren van de MBE kan men in het MBE scherm klikken met de muis:

linkermuisklik: MBE pauzeert.
rechtermuisklik: MBE gaat verder.

Men kan aan volgende kenmerken zien dat de MBE gepauzeerd is:

Het woord “Select” staat bovenaan in de witte balk van het scherm.
Er staat ergens in het scherm een cursor te knipperen.

Soms gebeurt het dan men per ongeluk met de muis binnen dit scherm klikt en dan gaat de MBE onbedoeld in pauzeermodus.

Rekenen met Methode 2 afbreken en overschakelen op Methode 1 voor de nog niet geplaatste opdrachten

Soms kan het zijn dat men de MBE wenst af te breken tijdens het rekenen met Methode 2 (omdat het te lang duurt), maar tegelijk wenst men er toch nog een maximaal resultaat uit te halen om in te lezen in Mondriaan. Eerder hebben we al besproken hoe we op een eenvoudige manier de ganse MBE kunnen afbreken door een “Close window” te doen (zie “Onderbreken met recuperatie tussenresultaten“). De manier die we hier bespreken is iets anders:

We gaan de actieve Methode 2 run onderbreken zonder de MBE te stoppen.
We gaan met het resultaat dat tot dan bekomen was, verder gaan, maar dan met Methode 1 en gebruikmakende van dezelfde recursiedieptes als opgegeven voor Methode 2.
De commando’s die Mondriaan aan de MBE gegeven heeft, blijven vervolgens verder lopen zoals gepland.
De manier om die omschakeling van Methode 2 naar Methode 1 te doen, is via de knop “m” (de “M2 escape” knop).

(PS. dit is mogelijk vanaf versie BT19.00.09)

In dit voorbeeld is de MBE bezig met het plannen van een rooster via Methode 2. We tonen hier het beeld op het moment dat men op de “m” knop gedrukt heeft. Dit was op het moment dat de MBE reeds 815 van de 1130 opdrachten geplaatst had:

Om zeker te zijn dat de gebruiker Methode 2 wil stoppen, wordt nog een bevestiging gevraagd waarop met “y” of “n” geantwoord moet worden. Geeft men “n” in dan gaat de MBE gewoon verder met Methode 2. Geeft men “y” in dan zal men het volgende zien gebeuren:

De kruisjes stellen de 815 opdrachten voor die Methode 2 reeds een plaats gegeven had. Vanaf dan zien we het typische patroon van een Methode 1 berekening. De MBE probeert nu gewoon de rest van de niet geplaatste opdrachten zo goed mogelijk te plaatsen. Omdat het Methode 1 is, zal het meestal niet lukken maar een heel deel zal er toch nog bijgeroosterd geraken. Het eindigt hier dan met 1094 (van de 1130) geplaatste opdrachten. Dit resultaat wordt dan in Mondriaan ingelezen.

Merk op dat men een dergelijk resultaat (maar niet exact hetzelfde) ook zou kunnen bekomen door Methode 2 gewoon af te breken en vervolgens via Mondriaan incrementeel bij te roosteren via Methode 1.

Overzicht van alle gebruikersacties die effect hebben tijdens het uitvoeren van de MBE

actie	effect	methode
k	3 modi. Visueler maken van de werkcontext van de MBE. Wijzig modus door op ‘k’ te drukken.	M2
v	Dump lastige opdrachten in de logfile (“\Log\logfile.txt”)	M2
c	Aan/uit zetten van het automatisch dumpen van lastige opdrachten in de logfile.	M2
d	Dump van de geplaatste context op het moment van de laatst gefaalde opdracht. (“\Dump\ruledump.txt”)	M2
t	Via deze toggle kiest men ervoor om de opdrachten waarmee gerekend wordt al dan niet in het bestand “Dump\lastdump.txt” op te nemen. Standaard staat dit uit en staan enkel de “Member Statistieken” in dit bestand. (vanaf BT19.00.09)	M2
m	Via deze “M2 escape” knop kan men het rekenen met Methode 2 afbreken en verder gaan met Methode 1, gebruik makende van het tot dan toe beste resultaat en met de recursiedieptes die voor Methode 2 ingesteld waren. Dit zorgt ervoor dat we bij het afbreken er toch nog het maximale uithalen alvorens het resultaat in Mondriaan ingelezen wordt. (vanaf BT19.00.09)	M2
w	Verhoog individuele recursiediepte van de laatst gefaalde opdracht. ‘(y/n)’ vraag.	M2
r	Reset de tellers die per opdracht het aantal falingen bijhouden.	M2
linker muisklik	Pauzeer de MBE	M2/M1
rechter muisklik	Activeer de MBE als die gepauzeerd was.	M2/M1
venster sluiten	Door op het rode kruisje te klikken (rechtsboven) sluit men het MBE scherm.	M2/M1