Office: Solvereffizienz erhöhen

Hallo ihr Helfer,

ich habe ein komplizierteres Problem, was aber denke ich auf eine recht einfache Frage hinausläuft und hoffe ihr könnt helfen.

Ich arbeite gerade an einem persönlichen Projekt und muss dabei wohl den Solver nutzen, weil ich mit VBA bisher keine Erfahrung habe.
Da das Problem aber anscheinend zu unüberschaubar groß wird (144 Variabeln), muss ich irgendetwas tun, damit der Aufwand eingeschränkt wird und der Solver das handhaben kann.

Ich geb mal ein vereinfachtes Beispiel:



und



Die türkisen Felder sind später das, was im Solver veränderbar ist. Dabei ist der obere Teil einfach nur ein binärer An- und Ausschalter (also quasi: "Wer hat sich überhaupt für was eingetragen") und der untere Teil dann die konkrete Anzahl. -> Diese Aufspaltung muss für mich leider sein, weil in meinem echten Problem nämlich durch den schieren Eintrag in eine der Kategorien sowas wie Zusatzkosten entstehen und das extra berechnet werden muss.

Die zweite Tabelle kontrolliert einfach, ob auch nur dort etwas 'mitgebracht' wurde, wo sich derjenige vorher auch eingetragen hat. Neben "Monsieur B" steht deswegen die rote 1, weil er einfach so 5 Brötchen mitgebracht hat, ohne das vorher anzumelden. :-)
Das ist also schonmal eine Solverbedingung, dass da rechts in der zweiten Tabelle die Summe auf 0 bleibt.

Die anderen Nebenbedingungen sind ganz einfach, dass der Gesamtaufwand pro Person vorbestimmt ist (genau so und so viel 'Dinge' pro Person sind Pflicht) und dass nicht mehr von einem bestimmten Ding mitgebracht wird als vorher bestimmt, sondern immer nur weniger oder genauso viel (ist wohl ein Weightwatchers Picknick )
Das sind weitere 3+4=7 Nebenbedingungen

Dann hab ich im Solver auch das erste und zweite türkise Feld der ersten Tabelle jeweils als einmal binär und beim anderen ganzzahlig gekennzeichnet, was auch noch zwei Nebenbedingungen sind.

Zu minimieren wäre übrigens die Gesamtanzahl der mitgebrachten Dinge (steht oben direkt neben den einzelnen Mengen).


Soweit bin ich momentan, aber selbst in diesem stark vereinfachten Beispiel, kann mir der Solver keine sinnvolle Lösung generieren, obwohl da gleich sehr viele auf der Hand liegen. Wenn man etwa Mr. A vier Brötchen mitbringen ließe, dann müssten die anderen jeweils 3 von entweder Salami oder Getränk heranschaffen + noch einmal Käse.
Jeder hätte in dem Fall das Soll von 4 Dingen mitgebracht und die maximal geforderten Mengen wären eingehalten worden (und wenn schön brav auch die Aktivierungs-Einser in den ersten Teil geschrieben wurden, dann gibts auch keine Probleme mit der Überprüfungstabelle 2).

Der Solver kriegt das offenbar deswegen nicht hin, weil diese Einser-Aktivierung gleichzeitig ein veränderbares Feld ist, wie die tatsächlichen Werte, die aber erst möglich werden, wenn auch oben alles stimmt.
Durch die Abhängigkeiten untereinander multipliziert sich die Anzahl der Möglichkeiten exponentiell, ganz so als würde man bei zehn Würfeln sagen, dass der letzte Würfel erst gezählt wird, wenn alle neun davor zufällig gleichzeitig eine 6 zeigen... . Dadurch kommt es so selten zu einer vernünftigen Auswertung, dass, tja, eigentlich gar nichts mehr funktioniert, auch wenn ich Millionen Iterationen verlangen könnte.


Darum liegt es auf der Hand, dass ich diese untereinander existierende Abhängigkeit irgendwie durchbrechen muss, aber leider habe ich nur eine vage Vorstellung wie. Z.B. wäre es schonmal eine extreme Rechenminimierung, wenn ich dem Solver einfach sagen könnte erst dann(!) anzufangen unten Werte einzutragen, wenn er gerade eine 1 oben aktiviert hat. Momentan ist es ja tatsächlich so, dass er z.B. bei Feld "Mr.A Brötchen-oben" eine 1 aktiviert und dann aber nur ein Feld ("Mr.A Brötchen-unten") zur Auswahl hätte, damit kein Fehler erzeugt wird, dagegen aber die vollen 11 anderen Felder, die in dem Fall sofort einen Fehler produzieren. Das ergibt ein Baumdiagramm, in dem nur lächerlich wenig Wege in eine richtige Richtung führen und wenn man bedenkt, dass mehrere solcher Schritte für die Ergebnisfindung hintereinander gestaffelt notwendig sind, dann ist es schlichtweg unmöglich zu packen.
Wenn ich da also schonmal die Äste vorgeben könnte, indem ich den Solver irgendwie per Trick in einer "erst wenn das, dann das"-Kategorie arbeiten lasse, dann würde sich der Aufwand erheblich reduzieren.
Das ist enetwa so, als würde man bei den zehn Würfeln von vornherein sagen, erst dann die Bedingungen zu überprüfen, wenn die 9 ersten Würfel vorher schon auf 6 festgesetzt sind, anstatt darauf zu warten, bis aus allen 6^10 Möglichkeiten die einzigen 6 relevanten herausgefunden wurden.

Das ist das Problem im Kern, deswegen ist meine finale Frage eigentlich die:
Kann ich den Solver (wahrscheinlich indirekt) anweisen nach diesem "erst wenn dies, dann das" Schema vorzugehen und damit diese ungeheure Lösungswegverästelung vermeiden (und damit quasi gleich meine Überprüfungstabelle 2 einsparen/ in die Rechnung direkt implementieren)?
Oder wie ungefähr müsste ich diese Tabellen schematisch umbauen, damit gar nicht erst so ein Problem entsteht?

Gut, ich hoffe ihr könnt mir dabei helfen, obwohl das Problem wirklich schwierig ist. :-?


P.S: Ich habe übrigens auch schon einen anderen Solver, "What's Best", ausprobiert, aber auch der war überlastet, was mich nicht überrascht.
Außerdem weiß ich auch schon, dass es bei der Einstellung auf Binär oder Ganzzahlig zu einem Genauigkeitsfehler kommt, was ich in meiner Originaldatei schon mit Runden in einer Extratabelle berücksichtige.

 

Ok, weil wahrscheinlich doch einiges unklar ist, habe ich mal eine schematische Übersicht von dem Solvervorgang gemacht:


Man sieht hier, dass es quasi erst innerhalb von drei Stufen zu einer Lösung kommen kann. Zuerst wird als allererster Schritt mit einer 1 oder 0 die Berechtigung gegeben Punkte in dem unteren Teil der Tabelle 1 zu verteilen (Ring "Aktivierung"). Dann wird überprüft, ob auch nur in den Feldern unten Werte eingetragen wurden, die vorher oben auch mit der 1 aktiviert waren (Ring "Werteintrag" - Das ist die Kontrolle der ersten Nebenbedingung). Erst zum Schluss findet das eigentliche übliche Solververfahren statt, bei dem wirklich verschiedene Werte in die Matrix eingesetzt werden und dann überprüft wird, wann dabei die Nebenbedingungen mit den Maximas etc. erfüllt sind ("Genauer Wert" - Hier werden die 3 + 4 eigentlichen Nebenbedingungen kontrolliert).

Mein Problem dabei ist, dass bevor es zu diesem eigentlichen Solverproblem am Ende, mit den richtigen Werten kommt, diese Aktivierungsbedingung mit der 1 oder 0 zu einer ungeheuren Multiplikation der Möglichkeiten führt (man sieht ja an der Grafik die Unmengen an Verzweigungen, die da noch existieren müssten, bevor wirklich die 7 Nebenbedingungen im letzten Schritt überprüft werden können). Es wird quasi erst auf der Spitze des Berges wirklich gerechnet, wo das Programm wegen der Vorausscheidung aber nur sehr selten hinkommt, also kann auch keine Lösung gefunden werden (solange man keinen Supercomputer hat). Das liegt vor allem Dingen daran, dass auch jeder Pfad, der eigentlich in der Grafik beim Schritt "Werteintrag" schon als rot=falsch identifiziert wurde, trotzdem noch in seiner ganzen nummerischen Bandbreite im dritten Ring überprüft wird, obwohl es eigentlich eh schon aus wäre ... der Solver bricht ja auch nicht vorher ab. Dadurch werden in meinem Beispiel 11 von 12 Pfaden sinnloser Weise überprüft, obwohl sie schon vorher rausgefallen wären.

Vielleicht versteht es jetzt jemand mit Hilfe der Grafik besser. Die Lösung, die ich an dem Problem zunächst mal sehen kann, ist diese beiden inneren Ringe verschmelzen zu lassen, sodass da nicht unsinnig vorher gerechnet werden muss, bevor mal eine zufällige Konfiguration gefunden ist, mit der man dann die letzten Nebenbedingungen überprüfen kann (und man bräuchte ja hunderte...).
Die beiden inneren Ringe verschmelzen zu lassen, heißt sinnvoll, dass der Solver erst dann anfängt Felder im unteren Teil von Tabelle 1 zu manipulieren, wenn er im oberen Teil eine 1 erzeugt hat - auf diese Weise würden Millionen von Falschlösungen schonmal ausgeschlossen werden (die sonst eine multiplikative Basis für das höhere Problem bilden würden - Millionen*Millionen :roll: ).

Kann man das in Excel irgendwie realisieren?

 

Hallo,

Du schreibst in etwa sinngemäß, dass Du dem Solver folgende Nebenbedingungen aufs Computer-Auge gedrückt hast:
1) Er muss die binären Ein/Ausschalter generieren
2) Er muss (eigentlich unabhängig davon) die Mengenfelder beschicken (mit insgesamt erlaubten Werten)
3) Er muss überprüfen, dass tatsächlich Mengen nur in eingeschalteten Feldern stehen.

... erst dann darf der Solver mit dem Optimieren beginnen (unter den so erlaubten Kombinationen).

Kann man das nicht einfach umdrehen? Und zwar folgendermaßen:
1) Man lasse den Solver erlaubte Mengen in den Mengenfeldern generieren (wie vorhin unter Punkt 2).
2) Überall dort, wo er Mengen generiert hat, schalte man den binären Schalter auf 1, um so die Zusatzkosten der Inanspruchnahme der Ressource berechnen zu können (wie immer diese in der komplexeren, hier nicht vorgestellten Variante erfolgt).

Auf diese Weise wäre der Hindernislauf des Solvers durch die Nebenbedingungen auf alle Fälle verringert, denn er braucht hier "nur" erlaubte Mengenkombinationen generieren. Den binären Ressourcenschalter kann man ja durch eine einfache Funktion (zB. Signum-Funktion) realisieren, womit somit der Solver nicht belastet wäre.

 

Uh, das klingt gut. :shock: Unglaublich wie einfach manchmal die Lösungen sein können :-o . Ich melde mich mal später noch, ob es so geklappt hat.

 

Nochmal zurück. Ich konnte das jetzt leider nicht erfolgreich testen, weil aus Gründen, die ich nicht sehen kann, der Solver nicht richtig anspringt.

Ich hab hier mal ein noch einfacheres Beispiel gemacht, wo diesmal aber diese angedeuteten Zusatzkostenfelder mit drin sind:

	E	F	G	H	I	J
59				0	0
60	0	0		0	0
61	0	0		6	6	12
62	0	0	0	2
63	0	0	0	8
64	0	0
65	6	6

Zelle	Formel
H59	=WENN(E60=1;2;0)
I59	=WENN(F60=1;1;0)
E60	=WENN(RUNDEN(E62;0)<>0;1;0)
F60	=WENN(RUNDEN(F62;0)<>0;1;0)
H60	=WENN(E61=1;1;0)
I60	=WENN(F61=1;3;0)
E61	=WENN(RUNDEN(E63;0)<>0;1;0)
F61	=WENN(RUNDEN(F63;0)<>0;1;0)
H61	=SUMME(H59:H60)+6
I61	=SUMME(I59:I60)+6
J61	=SUMME(H61:I61)
G62	=RUNDEN(E62;0)+RUNDEN(F62;0)
G63	=RUNDEN(E63;0)+RUNDEN(F63;0)
E64	=RUNDEN(E62;0)+RUNDEN(E63;0)
F64	=RUNDEN(F62;0)+RUNDEN(F63;0)
E65	=H61
F65	=I61

E60:F61 sind die Felder, wo die 1 angeht, wenn unten etwas steht - das sind natürlich die veränderbaren Zellen E62:F63. Darunter kommen zwei Felder mit Summen, die dafür da sind mit den dann ganz unten in E und F65 stehenden Werten verglichen zu werden (<=). Das ist nur die Kopie von H61 und I61
In G62 und 63 müssen die Summen dagegen ganz genau dem Wert rechts daneben entsprechen.
Über H59:I60 werden die Zusatzkosten aktiviert und darunter einfach deren Summen + ein Basiswert. (eleganterweise hätte man das natürlich auch gleich auf E60:F61 anwenden können, aber naja)
In J61 steht der Wert, der zu minimieren ist, die Gesamtsumme.

Hier nochmal übersichtlicher in Farbe:


Gut, viel erklärt aber das Problem ist wahrscheinlich simpel. Aus irgendeinem Grund bekommt der Solver jetzt selbst die einfachsten Vorgaben nicht gelöst.
Beispielsweise gebe ich allein die Nebenbedingung G62=H62 ein, der Solver wird also nur gezwungen zwei Punkte in der ersten Zeile irgendwie zu verteilen. Die beste Wahl dafür ist beide Punkte in F62 zu stecken, da die 'Aktivierung' dieses Feldes nur einen Punkt kostet, die von E62 hingegen zwei (und bei gleichmäßiger Verteilung natürlich zusammen gleich 3 Punkte Extrakosten...). Das heißt, das Minimum ist 15, sieht man sofort mit dem bloßen Auge.
Aber der Solver sagt, er könne keine Lösung finden... . Liegt wohl an den Einstellungen.
Die sehen momentan so aus:



Was habe ich da falsch gemacht? Ist übrigens das erste mal, dass ich den Solver wirklich benutze, obwohl ich mit ziemlich ähnlichen Dingen vertraut bin.

/// Das Modell an sich muss auf diese Weise aber stimmen, da bin ich mir nun sicher. Fragt sich nur, ob es dann auch in dem großen Format (72 Variabeln) funktionieren wird, das ich brauche und wo die überwiegende Anzahl der Werte wohl Nullen sein sollten. Aber das muss ich erst dann testen.

 

Grüezi Vokalmatador

Du machst dir graphisch und textlich unglaublich viel Mühe - IMO aber ist dieser Weg nicht sehr effizient.

Stelle doch eine adäquate Demo-Mappe zusammen und diese als Link zum Download zur Verfügung. Das wäre effizienter wenn wir nicht noch jedesmal von den Bildchen die Daten erstellen müssten.
Und das Solver-Modell wäre dann auch gleich mit drin.

 

Hallo,

im Folgenden habe ich das Modell aus Deinem Posting übernommen - allerdings war ich erst erfolgreich damit, als ich die Formeln in G62:G63 und E64:F64 modifizierte auf meine SUMME(..)-Formeln: Offenbar benötigt der Solver für nicht angezeigte Zwischenwerte eine Trendinformation, die er durch die SUMME(..)-Formeln erhält, die ihm aber mit den RUNDEN(..;0)+RUNDEN(..;0) Formeln genommen werden (zumindest ist das mein Erklärungsversuch für dieses Phänomen).

	D	E	F	G	H	I	J	K
57
58
59					0	1
60		FALSCH	WAHR		0	3
61		FALSCH	WAHR		6	10	16
62		0	2	2	2
63		0	8	8	8
64		0	10
65		6	10
66

Zelle	Formel
H59	=WENN(E60;2;0)
I59	=WENN(F60;1;0)
E60	=RUNDEN(E62;0)<>0
F60	=RUNDEN(F62;0)<>0
H60	=WENN(E61;1;0)
I60	=WENN(F61;3;0)
E61	=RUNDEN(E63;0)<>0
F61	=RUNDEN(F63;0)<>0
H61	=SUMME(H59:H60)+6
I61	=SUMME(I59:I60)+6
J61	=SUMME(H61:I61)
G62	=SUMME(E62:F62)
G63	=SUMME(E63:F63)
E64	=SUMME(E62:E63)
F64	=SUMME(F62:F63)
E65	=H61
F65	=I61

Ferner habe ich zum Teil abweichend von Dir folgende SOLVER-Einstellungen verwendet:

SOLVER-Parameter:
Zielzelle:	$J$61
Zielwert:	Min
Veränderliche Zellen:	$E$62:$F$63
Nebenbedingungen:	$E$62:$F$63=ganzzahlig
	$E$64<=$E$65
	$F$64<=$F$65
	$G$62=$H$62
	$G$63=$H$63
Optionen:
Höchstzeit:	100
Iterationen:	2000
Genauigkeit:	0,1
Toleranz:	80
Konvergenz:	0,1
Lineares Modell voraussetzen:	ok
Nicht-Negativ vorraussetzen	ok
Schätzung:	Linear
Differenz:	Vorwärts
Suchen:	Newton

Insbesondere dürften da die 3 Parameter Genauigkeit, Toleranz und Konvergenz eine bedeutende Rolle spielen. Ich habe sie durch Ausprobieren ermittelt. Und ferner habe ich das lineare Modell vorausgesetzt.
Eine gewisse Heimtücke dürfte ferner noch darin bestehen, dass die beiden Teilzielwerte in H61:I61 wiederum als einschränkende Nebenbedingungen in E65:F65 auftreten. Dadurch kann es manchmal vorkommen, dass der Solver eine Lösung präsentiert, die aber plötzlich nicht diesen Nebenbedingungen genügt. Durch nochmaliges Weiterrechnen kommt er dann auf eine gültige Lösung.

 

Hallo,

ich füge als Ergänzung noch meine Datei an:

 

Ah, vielen Dank, dass du das nochmal so erstellt hast.

Also das Problem, das durch Runden entstanden ist, wäre damit vom Tisch, dafür taucht jetzt aber wieder etwas neues auf :roll: . Der Solver findet nämlich nur Lösungen, die einfach die Nebenbedingungen erfüllen, schert sich aber kein bisschen um die tatsächliche Minimafindung.
Ich hab nochmal die Mappe angehangen; mit einer Umstellung auf die Werte 4 und 4 bei den Bedingungen ganz rechts. (außerdem hab ich die redundante Zusatztabelle jetzt entfernt)
Der Solver präsentiert wieder eine Verteilung von Punkten nur auf der zweiten Spalte, was zu den Zusatzkosten 1+3 führt. Eine optimale Lösung wäre aber gewesen genau 4 Punkte oben rechts und 4 Punkte unten links zu plazieren, was nur Zusatzkosten von 1+1 erzeugt hätte... .
Aber irgendwie kommt der nicht darauf, sondern scheint nur allein auf die Einhaltung der Nebenbedingungen zu achten.

 

Grüezi Vokalmatador

Du verwechselst hier zwei grundlegende Betrachtungsweisen.

Der Solver findet (wenn vorhanden) eine Lösung, die den Nebenbedingungen entspricht, und ein Minimum darstellt.
Dieses Minimum ist aber nicht zwingend das globale oder absolute Minimum, sondern stets ein lokales (von denen je nach Modell eben mehrere vorhanden sein können). Die Lage dieses Minimums hängt immer von den Vorgabewerten in den veränderbaren Zellen ab. Ein zweiter/dritter Lauf kann daher andere/weitere Ergebnisse liefern.

Bei 0-en als Ausganswerte habe ich diese Situation der Lösung erreicht.

Du hast ja auch die Optionen so eingestellt, dass das möglich wird.
Eine Toleranz von 80 wie sie im Modell eingestellt ist heisst, dass die Nebenbedingung um bis zu 80% von der Vorgabe abweichen darf.
Auch die Vergaben für die Genauigkeit und vor allem der Konvergenz sind meiner Ansicht nach viel zu gross gewählt. Der Solver gibt sich dann mit einer ungenaueren Lösung bereits zufrieden (das hast Du ihm da ja so erlaubt).

Wenn Du also alleine mal die Toleranz auf 5% zurück setzt sollte das schon etwas anders aussehen.

 

Hallo,

also ich habe ein bisschen mit den Optionen herumgespielt und bin so langsam etwas schlauer was die Funktionsweise des Solvers angeht. Konvergenz und Toleranz ließen sich dabei wirklich deutlich absenken, weil das bei so hoher Unschärfe wahrscheinlich zu schnell in die offensichtlichen Täler führt, die vlt. gar nicht die tiefsten sind. Wenn die Genauigkeit aber nicht mindestens 0,1 groß ist, kommt es zu überhaupt gar keiner Lösung, sondern nur zu der Fehlermeldung "Die Linearitätsbedingung wurde nicht eingehalten.". Warum das jetzt so ist, kann ich nicht sofort sehen, aber gut (Kann es sein, dass eigentlich "Genauigkeit für die Toleranz bei den Nebenbedingungen zuständig ist, neben der namentlichen 'Toleranz'? - zumindest indirekt, wenn also etwa 6 bei 0,1 eigentlich heißen würde 'gerundet 5-7'?").

Das der Excel Solver eine scharfe Grenze hat, wenn er nur lokale Minima finden kann, ist mir erst jetzt so aufgefallen, als ich das mit der Newton Methode erst realisiert habe. Dadurch geht der ja immer in eine Richtung vor und findet nur noch in seltenen Ausnahmefällen Aufhänger für eine vielleicht bessere Lösung.

Ja, stimmt. Ich bekommen nun auch bei jedem dieser einfacheren Probleme die beste Lösung heraus. Allerdings funktioniert das ab dem Moment nicht mehr, wo diese Zusatzkosten unbedingt notwendig sind, um eine Lösung zu finden, da sie die maximal mögliche Verteilungsmenge in der Vertikalen erhöhen. (also immer dann, wenn die Summe der Punkte in den Nebenbedingungen rechts größer ist, als die Punktesumme der Nebenbedingungen unten)
In dem Fall macht der Solver ein paar Iterationen, weiß dann aber bald nicht weiter und meldet wieder dieses "Linearitätsbedingung nicht eingehalten".
In dem angehangenen Dokument hab ich mal zwei Konstellationen aufgestellt, wo auch gleich jeweils eine optimale Lösung eingesetzt ist. Ersetzt man die aber durch Nullen und lässt den Solver rechnen, kommt er nicht mehr drauf.

Wenn ich das lineare Modell hingegen abschalte, kommen ganz und gar sinnlose Lösungen heraus, die sich nichtmal darum kümmern ein lokales Minimum zu finden. Wenn der Solver z.B. während einer Iteration sieht, wie die Gesamtsumme durch einen Eintrag in einem Feld unsinnig angewachsen ist, obwohl auch schon vorher die Nebenbedingungen erfüllt waren, dann versucht er nicht mal den Schritt umzukehren (obgleich die Richtung eindeutig "bergauf" war). Heraus kommt bei so einem Vorgehen natürlicherweise immer eine gleichmäßige Verteilung aller Punkte über alle Felder, also eigentlich das absolute Maximum... . Falscher ginge es gar nicht.


Irgendwie glaube ich so langsam, dass ich mit dem Solver bei diesem Problem nicht zurande kommen werde. Dadurch, dass jetzt schematisch der obere Tabellenteil nicht mehr zum Solver gehört, sondern nur reagiert, ist zwar der Verwirrungsgrad des Problems gesunken. Dafür ist dem Solver jetzt aber auch die Null als Eintrag wesentlich unwichtiger, als es jetzt ein funktionierendes 50-50 An-Aus Modell geschafft hätte. Ohne viele 'mutige' Nullen, also gelegentliche starke Wertveränderungen, kommt der Solver aber nicht mehr so leicht zu den absoluten Minimas und kann auch das Problem mit den für eine Lösung notwendigen Mehrkosten nicht so leicht bewältigen.
Das scheint mich leider auf den Ausgangspunkt zurückzuwerfen, wo ich noch diese Bedingung gebraucht habe, dass erst unten etwas eingetragen wird, wenn der Solver oben etwas aktiviert hat. Er würde dadurch nämlich mehr zum Springen neigen und somit mehr alternative Möglichkeiten abtasten. Diese Option, sowas im Solver einfach mit einzustellen, fehlt offenbar wenn da nur Newtonsche Methode möglich ist, also könnte man das vielleicht so irgendwie ertricksen?

Zum besseren Verständnis ein Bild von der Theorie:

Das rote Lot ist der Punkt, wo man sich in der momentanen Iteration befindet. Der grüne Bereich darum kennzeichnet die höchste Varianz bei der nächsten Iteration, egal ob nun wirklich per Zufallsstreuung oder per Newton (wobei es dann wohl nur die halbe Seite wäre, wo es auch wirklich abwärts geht).
Weil die Varianz so beschränkt ist und das nächste existierende und tatsächlich bessere Minimum gar nicht 'gesehen' werden kann, kommt man klassisch auch nie dorthin, wenn man das Lot nicht gewaltsam verrückt (andere Starwerte). Diese klassische Methode funktioniert leider nur sehr stark nach dem Prinzip des Steins, den man auf irgendeine Stelle eines Hügels ablegt und der dann einfach nur abwärts rutscht.
Deswegen benutzt man z.B. bei evolutionären Zufallsstreualgorithmen die Methode bei jeder Iteration immer ein paar extreme Ausreißer zu generieren, die dabei vielleicht Zonen entdecken, in denen es tatsächlich tiefer ist als im momentanen Optimum (in dem Bild die blauen Punkte). So wird der absolute Extremwert leichter gefunden (bzw. überhaupt erst richtig gesucht je nach Problem).

Auch wenn der Solver sowas leider nicht kann, könnte man ihm dieses Verhalten eventuell antricksen, wenn die Werte schon durch eine gewisse Bedingungsverknüpfung zum gelegentlichen Springen neigen würden. Und das wäre mit einer funktionierenden An-Aus Tendenz gegeben... .


Klingt bestimmt verwirrend, aber ich bekomme es irgendwie nicht klarer hin.
Was meint ihr dazu? Lässt sich meine ursprüngliche Idee noch irgendwie im Solver verwirklichen, oder wonach soll ich andernfalls noch suchen, um so ein Problem noch effektiv angehen zu können?

 

Grüezi Vokalmatador

Ab xl2010 steht ein erweiterter Solver zur Verfügung, der auch globale Minima/Maxima findet. Die Nebenbedingungen sind dann etwas restriktiver zu setzen, doch dann sucht dieser Solver erweitert nach den globalen Werten. Die Berechnung dauert dann auch um so länger.....

Im aktuellen Fall kannst Du vielleicht das Berechnungsproblem an sich so verändern/anpassen, dass Du auch mit der momentanen Version des Solvers besser an dein Ziel kommst.

Ich verwende in der Firma den Solver auf xl2003 für äusserst komplexe und umfangreiche Strömungsberechnungen mit gutem Erfolg.


Noch eine Bitte für dein vereinfachtes Modell:
Bezeichne was wo warum verändert werden soll, welches die Zellen für die Zusatzkosten sind und woher diese bezogen werden.
Im Moment ist es für mich recht undurchsichtig was die Beziehungen der Zellen untereinander bedeuten.

 

So, ich habe das Blatt nochmal zum besseren Verständnis umgestellt. Der Solverbereich ist jetzt komplett beschriftet und sortiert, während ich aus meinem Originalproblem mal etwas in die Mappe reinkopiert habe. Ich habe alles sehr genau kommentiert, sodass ihr sehen könnt, woher diese ganzen ominösen Werte nun eigentlich kommen.
Ich schätze ich kann es aber auch nicht noch besser beschreiben, weil das schon das absolute Original ist. Vorher hab ich schon versucht das Problem mit Metaphern wie Logistik, Lagern u.ä. zu beschreiben, aber diese Darstellungen hinken alle ein bisschen. Tatsache ist: das Problem ist rein mathematischen Ursprungs und daher ziemlich abstrakt und schwer mit irgendetwas zu vergleichen. Es ist genau so, wie es jetzt in der Datei steht.