Plan en Plan selectie

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

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:

Nuttige informatie over analyseren opdrachten:

Inhoud

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:

  1. BLANCO: 100% geplaatst, alle resources in de opdracht zijn actief, alle resources zijn geplaatst. (vb: ID37)
  2. 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%.)
  3. 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.)
  4. 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.)
  5. 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<x>.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<x>.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<x>.txt” bestanden in één scherm.

Log Folder

Er staan 2 types bestanden in deze folder:

  • “logfile <datum tijd>.txt“: in dit bestand schrijft de MBE de voortgang van de stappen die de MBE op vraag van Mondriaan moet uitvoeren.
  • “anafile <datum tijd>.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<xxx>.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<datum>.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
Print Friendly, PDF & Email

Didn't find your answer? Contact Us

  

  

Veelgezochte termen:Outputrooster, Volgordespreiding, Partitie