[JAVA] Leistungsüberprüfung der Red Hat Decision Manager-Planoptimierung

Autor: Hitachi Solutions Co., Ltd. Akihiro Yanagimura Aufsicht: Hitachi, Ltd.

Einführung

Bei der Planoptimierung wird der beste Plan (Kombinationsplan) mit begrenzten Ressourcen unter Berücksichtigung der zu beachtenden Einschränkungen und Effizienz formuliert.

Wenn hier der Umfang des Zielplans (z. B. im Fall eines Personalschichtplans, die Anzahl des Zielpersonals und die Anzahl der zuzuweisenden Schichtplätze) zunimmt, nimmt auch die Anzahl der Kombinationen zu und die Zeit, bis ein guter Plan erstellt werden kann, nimmt ebenfalls zu. Wird steigen. Daher ist es bei der Durchführung der Planoptimierung erforderlich, die folgenden Inhalte zu berücksichtigen.

――Wie groß ist die Optimierung? ――Wie viel Rechenzeit können Sie verbringen? ――Wie viele Maschinenspezifikationen benötigen Sie?

In diesem Artikel stellen wir die Leistungsüberprüfung vor, mit der der Plan mithilfe von Red Hat Decision Manager für den Modellfall der täglichen Schichtplanung des Personals optimiert wird. Wir hoffen, dass dieser Artikel in den folgenden Punkten nützlich sein wird.

In den folgenden Artikeln finden Sie eine Übersicht über die Planungsoptimierung mit Red Hat Decision Manager und ein Bild seiner Verwendung. Planoptimierung mit KI, die den Grund für das Ergebnis versteht Planoptimierung "Nutzungsbild" mit KI, die den Grund für das Ergebnis versteht

Modellkoffer

Umriss des Plans

Entwickeln Sie einen täglichen Schichtplan für Mitarbeiter mit mehreren Aufgaben in einem Arbeitsbereich. Insbesondere werden wir Personal für die Ausführung der Arbeiten für jeden Schichtschlitz unter Berücksichtigung von Einschränkungen und Effizienz einsetzen.

Das Bild der Erstellung von Schichtdaten (Schichtrahmen nach Personalzuweisung) ist unten dargestellt. システム概要_イメージ.png In diesem Modellfall wird angenommen, dass es die folgenden drei Muster von Personal- und Schichtschlitzen gibt.

# Anzahl der Mitarbeiter Anzahl der Shift-Frames
1 1000 4212
2 500 2106
3 250 1053

Einschränkungsregel

In diesem Modellfall werden die folgenden Einschränkungsregeln festgelegt.

# Einschränkungsregel Einschränkungstyp Beschreibung des Einschränkungstyps level
1 Stellen Sie sicher, dass dem Schichtrahmen Personal zugewiesen ist. Absolute Einschränkung Einschränkungsregeln, die beachtet werden müssen. Hard
2 Weisen Sie nicht dasselbe Schichtpersonal während derselben Arbeitszeit mehreren Schichtplätzen zu.
3 Beachten Sie die Arbeitszeiten jeder Person (vorzeitige Abreise, keine Überstunden). Überlegungen zu Einschränkungen Einschränkungsregeln, die so weit wie möglich eingehalten werden.
Es gibt jedoch Fälle, in denen dies aufgrund des Gleichgewichts mit anderen Einschränkungsregeln und Bewertungsindizes nicht beobachtet wird. 		Soft
4 Weisen Sie dem Personal die erforderlichen Fähigkeiten für die Arbeit zu.
5 Weisen Sie Personen mit hohem Qualifikationsniveau kein Personal mit hohem Qualifikationsniveau zu.
6 Personal mit derselben OJT-Gruppe (Ausbilder und Neuankömmling) muss die gleichen Arbeitszeiten + den gleichen Arbeitsplatz haben.
7 Personen mit derselben Ausschlussgruppe für Schichtrahmen (z. B. Personen, die nicht übereinstimmen) sollten nicht an derselben Arbeitszeit + am selben Arbeitsplatz untergebracht werden.
8 Reduzieren Sie die Anzahl der Bewegungen im Arbeitsbereich. Bewertungsindex Einschränkungsregel zur Berechnung besserer Kombinationen.
9 Gleicht die Arbeitszeit des Personals aus.

Modellfallgröße (Suchraumgröße) und Zielpunktzahl

Die Punktzahl ist ein Indexwert, der die Optimierungsberechnung auswertet. In diesem Modellfall ist 0 (0 hart / 0 weich) die beste Punktzahl, da alle Einschränkungsregeln der Punktzahl einen Strafwert (negativen Wert) geben. Angesichts der begrenzten Ressourcen (Anzahl der Mitarbeiter, Anzahl der Schichtplätze) und der Zeit, die für die Planung aufgewendet werden kann, legen wir die Zielpunktzahl fest, wie viel wir optimieren sollten.

Die Zielpunktzahl für die in diesem Modellfall festgelegte Skala (Suchraumgröße) lautet wie folgt.

# Skalieren (Größe des Suchraums) Zielpunktzahl
Anzahl der Mitarbeiter Anzahl der Shift-Frames
1 1000 4212 0hard/-69000soft
2 500 2106 0hard/-34500soft
3 250 1053 0hard/-17250soft

Die Idee der Zielpunktzahl ist wie folgt.

Einschränkungstyp Zielpunktzahl Berechnungsformel für die Zielpunktzahl
Absolute Einschränkung 0 ―
Überlegungen Einschränkungen 0 ―
Bewertungsindex In diesem Modellfall mit den folgenden Zielen minimieren.
  1. Anzahl der Arbeitsbereichsbewegungen: Nicht mehr als 2 Mal pro Person.
  2. Arbeitsnivellierung: Innerhalb von ± 7% der durchschnittlichen Schichtbeschäftigungsquote.
  1. 2 [Zeiten / Person] x Anzahl der Personen x Strafwert (Gewicht) (-10)
  2. 7 2 [%] × Anzahl der Mitarbeiter × Strafwert (Gewicht) (-1)
Insgesamt 0 hart / - (69 x Anzahl Mitarbeiter) weich

Suchraumgröße

Die Größe des Suchraums ist die Anzahl der möglichen Kombinationen für den Plan. Je größer der Suchraum ist, desto länger ist die Berechnungszeit. Die Größe des Suchraums in diesem Modellfall ist die Potenz von "Anzahl der Mitarbeiter" zu "Anzahl der Schichtrahmen".

# Anzahl der Mitarbeiter Anzahl der Shift-Frames Suchraumgröße
1 250 1053 2501053 ≧ 102525
2 500 2106 5002106 ≧ 105684
3 1000 4212 10004212 ≧ 1012636

Die Angabe zur Größe des Red Hat Decision Manager-Suchbereichs finden Sie im OptaPlanner-Benutzerhandbuch Suchbereichsgröße. Bitte nehmen Sie Bezug darauf. Berücksichtigen Sie die Größe dieses Suchbereichs sorgfältig, wenn Sie die Überprüfungsergebnisse in diesem Dokument als Referenzwerte verwenden.

Überprüfungsumgebung

Bei dieser Überprüfung wurde die Überprüfung unter Verwendung der folgenden Überprüfungsumgebung durchgeführt.

** Maschinenumgebung **

Elemente Wert
Betriebssystemname Microsoft Windows10 Pro
Prozessor Intel® Core ™ i7-6700-CPU bei 3,40 GHz, 3408 MHz, 4 Kerne, 8 logische Prozessoren
Physischer Speicher 16GB
** Software-Informationen **
Name der Software Version
Red Hat Decision Manager 7.6.0
OpenJDK 1.8.0

** Einstellungsinformationen **

Elemente Wert
Java-Anfangsheapgröße 4096 MB
Maximale Java-Heap-Größe 4096 MB
Anzahl der verwendeten Threads 6
Bei der optimierten Berechnung von Red Hat Decision Manager gibt es eine Funktion namens Multithread-Inkrementallösung, mit der die Berechnungsgeschwindigkeit durch Verwendung mehrerer CPU-Threads verbessert werden kann. Sie können es verwenden, indem Sie den Parameter moveThreadCount hinzufügen und die Anzahl der Threads angeben, die Sie verwenden möchten. Wenn Sie diese Funktion verwenden, können Sie die Berechnung in mehrere Threads aufteilen und die Optimierungsberechnung durchführen. Beachten Sie jedoch, dass die Verwendung von n Threads die Berechnungsgeschwindigkeit nicht einfach um das n-fache erhöht.

Eine detaillierte Beschreibung der inkrementellen Multithread-Lösung finden Sie unter Inkrementelle Lösung mit mehreren Threads im OptaPlanner-Benutzerhandbuch (https://docs.optaplanner.org/7.30.0.Final/optaplanner-docs/html_single/#multithreadedIncrementalSolving).

Überprüfungsmethode

Optimierungsalgorithmus und Optimierungsparameter

Red Hat Decision Manager unterstützt eine Vielzahl von Optimierungsalgorithmen. Die zum Erreichen der Zielpunktzahl erforderliche Berechnungszeit hängt vom ausgewählten Optimierungsalgorithmus und den angegebenen Werten der Abstimmungsparameter dieses Algorithmus ab.

Bei dieser Überprüfung wird die Überprüfung unter Verwendung der folgenden drei häufig verwendeten Optimierungsalgorithmen durchgeführt.

Wenn Sie die detaillierten Spezifikationen des Algorithmus und anderer Alligorismen in Red Hat Decision Manager kennen möchten, wenden Sie sich bitte an das [OptaPlanner-Benutzerhandbuch](https://docs.optaplanner.org/7.30.0.Final/optaplanner-docs/html_single]. /)Bitte beziehen Sie sich auf.

Darüber hinaus verfügt Red Hat Decision Manager über eine Benchmark-Funktion, mit der die Optimierungsberechnungsergebnisse von Algorithmen und Parametern in einem Bericht ausgegeben werden können. Durch Verwendung der Benchmark-Funktion und Vergleichen der Konfiguration jedes Algorithmus und Parameters kann die Parameteroptimierung effizient gefördert werden. Detaillierte Spezifikationen der Benchmark-Funktion finden Sie unter Benchmarking und Optimierung im OptaPlanner-Benutzerhandbuch.

Beendigungsbedingung der Optimierungsberechnung

Bei dieser Überprüfung wird die Endbedingung der Optimierungsberechnung so eingestellt, dass sie endet, wenn eine der beiden folgenden Bedingungen erfüllt ist.

Sie können auch die Endbedingung "Erreichen der Zielpunktzahl" festlegen, aber ich wollte überprüfen, um wie viel sich die Punktzahl erhöhen würde, also habe ich die obige Endbedingung verwendet. Selbst in einem tatsächlichen System denke ich, dass die oben genannten Beendigungsbedingungen häufig so festgelegt sind, dass innerhalb einer akzeptablen Zeit bessere Ergebnisse erzielt werden können, anstatt die Berechnung zu beenden, sobald die Zielpunktzahl erreicht ist.

Bewertungspunkte

Die folgenden Ergebnisse sind in dieser Überprüfung zusammengefasst.

  1. Zeit, um die Zielpunktzahl zu erreichen
  2. Beste Punktzahl nach 30 Minuten
  3. Beste Punktzahl nach 60 Minuten (250 Personen haben nur bis zu 30 Minuten verifiziert, sodass nur 500 Personen und 1000 Personen aufgelistet sind)

Bei Optimierungsberechnungen im kleinen Maßstab wie 250 Personen wird das Erreichen der Zielpunktzahl so schnell wie möglich als Bewertungspunkt Nummer eins angesehen und mit 1 bewertet (bewertet). Bei umfangreichen Optimierungsberechnungen wie 500 oder 1000 Personen ist die Zeit bis zum Erreichen der Zielpunktzahl ebenfalls ein wichtiger Bewertungspunkt. Es wird jedoch davon ausgegangen, dass der wichtigste Bewertungspunkt darin besteht, die optimale Lösung in einer begrenzten Zeit abzuleiten. , 2 zu bewerten (Rang).

Prüfergebnis

Da es so viele verifizierte Muster gibt, werden wir die besten Verifizierungsergebnisse vorstellen. Die Zahl in Klammern am unteren Rand der Spalte "Beste Punktzahl nach 30 Minuten / 60 Minuten" gibt die Zeit (Sekunden) an, zu der die Endbedingung "Beste Punktzahl wurde 5 Minuten lang nicht aktualisiert" erfüllt ist und die Optimierungsberechnung abgeschlossen ist. Ich werde. Der fettgedruckte Teil in der Spalte "Zeit bis zum Erreichen der Zielpunktzahl [Sekunden]" ist die Zeit bis zum Erreichen der Zielpunktzahl in jedem Überprüfungsmuster am schnellsten.

1000 Personen (Zielpunktzahl: 0hard / -69000soft)

Tabu Search

Rang Parameter Zeit bis zum Erreichen der Zielpunktzahl
[Sekunden]
Beste Punktzahl nach 30 Minuten
Beste Punktzahl nach 60 Minuten
entityTabuSize acceptedCountLimit
1 9 4000 602 0hard/-55780soft 0hard / -53928soft
(3559 [Sekunden])
2 9 2000 687 0hard/-57125soft 0hard / -56419soft
(2545 [Sekunden])
3 5 4000 668 0hard/-57476soft 0hard/-55623soft
4 7 2000 1154 0hard/-57586soft 0hard / -57208soft
(2317 [Sekunden])

Late Acceptance

Rang Parameter Zeit bis zum Erreichen der Zielpunktzahl
[Sekunden]
Beste Punktzahl nach 30 Minuten
Beste Punktzahl nach 60 Minuten
lateAcceptanceSize acceptedCountLimit
1 3 1 731 0hard/-51909soft 0hard/-50175soft
2 1 1 306 0hard/-53840soft 0hard/-52862soft
3 5 1 1239 0hard/-54752soft 0hard/-51532soft
4 1 4 1270 0hard/-55282soft 0hard/-53976soft

Simulated Annealing

Rang Parameter Zeit bis zum Erreichen der Zielpunktzahl
[Sekunden]
Beste Punktzahl nach 30 Minuten
Beste Punktzahl nach 60 Minuten
simulatedAnnealing
StartingTemperature		 acceptedCountLimit
1 0hard/10soft 4 348 0hard/-53457soft 0hard/-52426soft
2 0hard/5soft 4 1113 0hard/-55198soft 0hard/-53803soft
3 0hard/50soft 4 477 0hard/-55700soft 0hard/-52170soft
4 0hard/100soft 4 1210 0hard/-58192soft 0hard/-51499soft

Mit Daten von 1000 Personen wurde die Zielpunktzahl in 306 Sekunden am schnellsten erreicht. Darüber hinaus wurde die beste Punktzahl durch Durchführen einer Optimierungsberechnung auch nach Erreichen der Zielpunktzahl aktualisiert.

Unten ist der Soft Score-Übergang Nr. 1 für jeden Algorithmus in der obigen Tabelle aufgeführt. 1000人_01.png Der Startpunkt jedes Algorithmus ist der Punkt, an dem die harte Punktzahl 0 hart wird. Das simulierte Tempern konvergierte am schnellsten gegen 0, wie in ① gezeigt.

Unten ist eine vergrößerte Ansicht von ②. 1000人_02.png Der schnellste Algorithmus zum Erreichen der Zielpunktzahl war das simulierte Tempern. Bis zu etwa 1000 Sekunden hat Simulated Annealing die beste Punktzahl, danach hat Late Acceptance die beste Punktzahl. In Bezug auf die Erhöhung der Punktzahl von 3000 Sekunden in ① bis zum Ende der Optimierungsberechnung hat jeder Algorithmus ungefähr mehrere Hundert, und es wird angenommen, dass keine signifikante Verbesserung der Punktzahl erwartet wird, selbst wenn die Optimierungsberechnung nicht mehr durchgeführt wird.

500 Personen (Zielpunktzahl: 0hard / -34500soft)

Tabu Search

Rang Parameter Zeit bis zum Erreichen der Zielpunktzahl
[Sekunden]
Beste Punktzahl nach 30 Minuten
Beste Punktzahl nach 60 Minuten
entityTabuSize acceptedCountLimit
1 7 2000 436 0hard/-27506soft 0hard / -27506soft
(2027 [Sekunden])
2 5 4000 263 0hard/-28082soft 0hard / -27701soft
(2584 [Sekunden])
3 7 4000 464 0hard/-28222soft 0hard / -27649soft
(3237 [Sekunden])
4 9 2000 170 0hard / -28585soft
(1129 [Sekunden]) 		―

Late Acceptance

Rang Parameter Zeit bis zum Erreichen der Zielpunktzahl
[Sekunden]
Beste Punktzahl nach 30 Minuten
Beste Punktzahl nach 60 Minuten
lateAcceptanceSize acceptedCountLimit
1 5 1 188 0hard/-24991soft 0hard/-24621soft
2 3 1 153 0hard/-25755soft 0hard / -25625soft
(2712 [Sekunden])
3 100 4 517 0hard/-25983soft 0hard/-25213soft
4 50 4 284 0hard/-26562soft 0hard/-26196soft

Simulated Annealing

Rang Parameter Zeit bis zum Erreichen der Zielpunktzahl
[Sekunden]
Beste Punktzahl nach 30 Minuten
Beste Punktzahl nach 60 Minuten
simulatedAnnealing
StartingTemperature		 acceptedCountLimit
1 0hard/5soft 4 244 0hard/-26071soft 0hard/-25384soft
2 0hard/10soft 4 685 0hard/-26438soft 0hard/-25791soft
3 0hard/5soft 1 468 0hard/-27423soft 0hard/-26365soft
4 0hard/50soft 4 151 0hard/-27932soft 0hard/-26146soft
Mit Daten von 500 Personen wurde die Zielpunktzahl in 151 Sekunden am schnellsten erreicht. Darüber hinaus wurde die beste Punktzahl durch Durchführen einer Optimierungsberechnung auch nach Erreichen der Zielpunktzahl aktualisiert.

Unten ist der Soft Score-Übergang Nr. 1 für jeden Algorithmus in der obigen Tabelle aufgeführt. 500人_01.png Der Startpunkt jedes Algorithmus ist der Punkt, an dem die harte Punktzahl 0 hart wird. Das simulierte Tempern konvergierte am schnellsten gegen 0, wie in ① gezeigt.

Unten ist eine vergrößerte Ansicht von ②. 500人_02.png Der schnellste Algorithmus zum Erreichen der Zielpunktzahl war die späte Akzeptanz. Von 250 Sekunden bis 700 Sekunden hat Simulated Annealing die beste Punktzahl, aber danach hat Late Acceptance die beste Punktzahl. In Bezug auf die Erhöhung der Punktzahl von 1800 Sekunden in (1) bis zum Ende der Optimierungsberechnung hat jeder Algorithmus ungefähr mehrere Hundert, und es wird angenommen, dass keine signifikante Verbesserung der Punktzahl erwartet wird, selbst wenn die Optimierungsberechnung nicht mehr durchgeführt wird. In Bezug auf die Tabu-Suche wurde die Optimierungsberechnung ohne Verbesserung der Punktzahl in etwa 2000 Sekunden abgeschlossen.

250 Personen (Zielpunktzahl: 0hard / -17250soft)

Tabu Search

Rang Parameter Zeit bis zum Erreichen der Zielpunktzahl
[Sekunden]
Beste Punktzahl nach 30 Minuten
Beste Punktzahl nach 60 Minuten
entityTabuSize acceptedCountLimit
1 11 2000 167 0hard / -15400soft
(1378 [Sekunden]) 		ー
2 9 2000 224 0hard / -15265soft
(1722 [Sekunden]) 		ー
3 5 1000 244 0hard / -16190soft
(686 [Sekunden]) 		ー
4 7 4000 262 0hard/-15850soft ―

Late Acceptance

Rang Parameter Zeit bis zum Erreichen der Zielpunktzahl
[Sekunden]
Beste Punktzahl nach 30 Minuten
Beste Punktzahl nach 60 Minuten
lateAcceptanceSize acceptedCountLimit
1 5 1 98 0hard / -14755soft
(1775 [Sekunden]) 		ー
2 20 1 182 0hard/-14681soft ー
3 10 1 216 0hard / -14534soft
(1739 [Sekunden]) 		ー
4 10 4 248 0hard / -15118soft
(1499 [Sekunden]) 		ー
**Simulated Annealing**
Rang Parameter Zeit bis zum Erreichen der Zielpunktzahl
[Sekunden]
Beste Punktzahl nach 30 Minuten
Beste Punktzahl nach 60 Minuten
simulatedAnnealing
StartingTemperature		 acceptedCountLimit
1 0hard/5soft 4 193 0hard / -15151soft
(1159 [Sekunden]) 		ー
2 0hard/100soft 4 325 0hard/-14977soft ー
3 0hard/50soft 1 1215 0hard/-14584soft ー
4 0hard/500soft 4 1355 0hard/-15122soft ー

Mit Daten von 250 Personen wurde die Zielpunktzahl in 98 Sekunden am schnellsten erreicht. Darüber hinaus wurde die beste Punktzahl durch Durchführen einer Optimierungsberechnung auch nach Erreichen der Zielpunktzahl aktualisiert.

Unten ist der Soft Score-Übergang Nr. 1 für jeden Algorithmus in der obigen Tabelle aufgeführt. 250人_01.png Der Startpunkt jedes Algorithmus ist der Punkt, an dem die harte Punktzahl 0 hart wird. Das simulierte Tempern konvergierte am schnellsten gegen 0, wie in ① gezeigt.

Unten ist eine vergrößerte Ansicht von ②. 250人_02.png Der schnellste Algorithmus zum Erreichen der Zielpunktzahl war die späte Akzeptanz. Die späte Akzeptanz ergab von Anfang bis Ende die beste Punktzahl. In Bezug auf die Erhöhung der Punktzahl von 300 Sekunden in (1) bis zum Ende der Optimierungsberechnung hat jeder Algorithmus ungefähr mehrere Hundert, und es wird angenommen, dass keine signifikante Verbesserung der Punktzahl erwartet wird, selbst wenn die Optimierungsberechnung nicht mehr durchgeführt wird.

Erwägung

Bei dieser Überprüfung konnten wir bestätigen, dass Red Hat Decision Manager innerhalb eines realistischen Zeitraums eine Planungsoptimierung auf einer Skala von 1000 Personen erreichen kann. Hier werden wir betrachten, was wir aus der Überprüfung sehen können.

Berechnungszeit und Score-Eigenschaften jedes Algorithmus

Im Modellfall, Skalierungs- (Größe des Suchraums) und Einschränkungsregel-Gewichtswerten dieser Überprüfung wurde das Merkmal (Tendenz) der Bewertung der Berechnungszeit jedes Algorithmus nicht gefunden.

Einfache Abstimmung jedes Algorithmus

# Optimierungsalgorithmus Merkmale aus der Überprüfung Berücksichtigung der Überprüfungsergebnisse
1 Tabu Search Der Bereich der Tuning-Parameterwerte ist groß. Wenn Sie viele Parameter überprüfen und einstellen, ist es sehr wahrscheinlich, dass Sie die höchste Punktzahl erhalten.
Da die Eingabedaten jedoch nicht jedes Mal gleich sind, wird davon ausgegangen, dass eine allgemeine Anpassung schwierig ist.
2 Late Acceptance Der Bereich der Abstimmparameterwerte ist relativ eng. Die Tendenz zur Verbesserung / Verschlechterung der Punktzahl aufgrund der Änderung des -Parameters ist leicht zu erkennen, und es wird angenommen, dass es am einfachsten ist, die drei in dieser Überprüfung verwendeten Algorithmen anzupassen.
3 Simulated Annealing Im Überprüfungsergebnis dieser Überprüfung ist der Bereich der Abstimmparameterwerte relativ eng.
Da der Optimierungsparameter "simulatedAnnealingStartingTemperature" jedoch den "Anfangswert des Bewertungswerts angibt, der die Akzeptanz ermöglicht", hängt er vom Gewichtungswert der Einschränkungsregel ab. Es ist notwendig, nicht nur die 		-Skala (die Größe des Suchraums), sondern auch den Gewichtungswert der Einschränkungsregel zu berücksichtigen, und es wird angenommen, dass die Anpassung schwieriger ist als die späte Akzeptanz.

So passen Sie die Tuning-Parameter an

# Optimierungsalgorithmus Optimierungsparameter Angegebener Bereich
1 Tabu Search entityTabuSize 5～12
2 acceptedCountLimit 1000～4000
3 Late Acceptance lateAcceptanceSize 1～600
4 acceptedCountLimit 1 oder 4
5 Simulated Annealing simulatedAnnealingStartingTemperature (Hängt vom Gewichtungswert der Einschränkungsregel ab.)
6 acceptedCountLimit 1 oder 4
**#3,#5 :** Dieser Parameter wird entsprechend der Skala (Größe des Suchraums) angepasst. Es wird angenommen, dass der Wert umso kleiner ist, je größer der Maßstab (die Größe des Suchraums) ist.
Wenn der angegebene Wert groß ist, ist die Anzahl der auszuwertenden Kombinationen groß und die Zeit zur Lösung des Problems lang, aber die maximale Punktzahl ist hoch.
Wenn der angegebene Wert klein ist, ist die Anzahl der auszuwertenden Kombinationen gering und die Zeit zur Lösung des Problems kurz, aber die maximale Punktzahl ist niedrig. **#1 :** Der Trend ist nicht klar, aber wenn 7 und 9 relativ gut sind und der Maßstab (die Größe des Suchraums) klein ist, gehen wir davon aus, dass Sie den Wert erhöhen sollten. **#2,#4,#6 :** Es wird empfohlen, tatsächlich zu messen, da die Tendenz unbekannt ist.

Ich habe den angegebenen Bereich von entityTabuSize mit Tabu-Größe im Bereich von 5 bis 11 überprüft, aber auf der folgenden Website wurde angegeben, dass "ein Wert von 5 bis 12 gut ist". https://ja.wikipedia.org/wiki/%E3%82%BF%E3%83%96%E3%83%BC%E3%82%B5%E3%83%BC%E3%83%81

Bei allen Algorithmen kann das Ändern der Abstimmungsparameter einen großen Unterschied in den Ergebnissen bewirken. Wir haben jedoch festgestellt, dass die Anpassungen gute Ergebnisse liefern. Ich habe vorgestellt, wie die Abstimmungsparameter jedes Algorithmus angepasst werden, aber ich hatte das Gefühl, dass die späte Akzeptanz einfacher anzupassen ist als andere Algorithmen. Wenn Sie nicht genügend Zeit haben, um tatsächlich zu messen, ist es daher eine gute Idee, die Einstellung von Late Acceptance zu übernehmen.

Parameter, die als Grundwerte für jede Skala verwendet werden können (Größe des Suchraums)

Bei dieser Überprüfung wurden ungefähr 60 Muster auf jeder Skala verifiziert. Wenn Optimierungsberechnungen mit ähnlichen Modellfällen, Skalierung (Größe des Suchraums) und Gewichtungswerten von Einschränkungsregeln durchgeführt werden, ist es effizient, die Parameter aus dem Bereich der Kombinationen von Optimierungsalgorithmen und Parametern unten abzustimmen. Ich nehme an, Sie können stimmen.

Skalieren
(Größe des Suchraums) 		Optimierungsalgorithmus Parameter
Anzahl der Mitarbeiter Shift
Anzahl der Frames
1000 4212 Tabu Search entityTabuSize : 7～9
acceptedCountLimit : 1000～4000
Late Acceptance lateAcceptanceSize : 1～10
acceptedCountLimit : 1
Simulated Annealing simulatedAnnealingStartingTemperature : 0hard/5soft～0hard/100soft
acceptedCountLimit : 4
500 2106 Tabu Search entityTabuSize : 5～9
acceptedCountLimit : 1000～4000
Late Acceptance lateAcceptanceSize : 3～10
acceptedCountLimit : 1
lateAcceptanceSize : 30～100
acceptedCountLimit : 4
Simulated Annealing simulatedAnnealingStartingTemperature : 0hard/5soft～0hard/100soft
acceptedCountLimit : 4
250 1053 Tabu Search entityTabuSize : 11
acceptedCountLimit : 1000～4000
Late Acceptance lateAcceptanceSize : 5～20
acceptedCountLimit : 1
Simulated Annealing simulatedAnnealingStartingTemperature : 0hard/5soft
acceptedCountLimit : 4

abschließend

In diesem Artikel haben wir die Ergebnisse der Leistungsüberprüfung für die geplante Optimierung von 250, 500 und 1000 Personen vorgestellt. Ich denke, dass Red Hat Decision Manager einfacher zu verwenden ist, wenn Sie sich auf die eingeführte Methode zur Anpassung der Optimierungsparameter und die Parameter beziehen, die als Grundwerte verwendet werden können. Versuchen Sie es also bitte.

Recommended Posts

Leistungsüberprüfung der Red Hat Decision Manager-Planoptimierung
Überprüfung der Auswirkungen auf die Leistung bei Verwendung von Java Volatile