002_LV-mathematischerSolver_Rahmenvereinbarung_PR1283908.pdf

Leistungsbeschreibung für eine

Lizenzbeschaffung mathematischer High-Per-

formance-Solver für die Fraunhofer Gesellschaft

unter Nutzung der institutseigenen HPC-Infra-

strukturen

Inhalt

1. Beschreibung des Vorhabens 3
2. Inhaltliche Anforderungen 4
3. Ausarbeitung des Angebots 7
4. Leistungszeitraum 9 4.1 Geschätztes Volumen 9
5. Abnahme 9
6. Zahlungsbedingungen 9 7.Eignungskriterien 9
7. Zuschlagskriterien 10

1. Beschreibung des Vorhabens

Allgemeine Vorstellung der Organisation:

Die Fraunhofer-Gesellschaft mit Sitz in Deutschland ist eine der führenden Organisationen für anwendungsorientierte Forschung. Im Innovationsprozess spielt sie eine zentrale Rolle – mit For- schungsschwerpunkten in zukunftsrelevanten Schlüsseltechnologien und dem Transfer von For- schungsergebnissen in die Industrie zur Stärkung unseres Wirtschaftsstandorts und zum Wohle unserer Gesellschaft.

Die 1949 gegründete Organisation betreibt in Deutschland derzeit 76 Institute und Forschungs- einrichtungen. Die gegenwärtig knapp 32 000 Mitarbeitenden, überwiegend mit natur- oder in- genieurwissenschaftlicher Ausbildung, erarbeiten das jährliche Finanzvolumen von 3,4 Mrd. €. Davon fallen 3,0 Mrd. € auf den Bereich Vertragsforschung, der sich in drei Finanzierungssäulen gliedert: Einen Anteil davon erwirtschaftet Fraunhofer mit Aufträgen aus der Industrie und aus Lizenzerträgen, die sich auf insgesamt 836 Mio. € belaufen. Der hohe Anteil an Wirtschaftser- trägen ist das Fraunhofer-Alleinstellungsmerkmal in der deutschen Forschungslandschaft. Ein weiterer Teil aus dem Bereich Vertragsforschung stammt aus öffentlich finanzierten Forschungs- projekten. Bund und Länder komplettieren die Vertragsforschung durch die Grundfinanzierung. Damit ermöglichen die Zuwendungsgeber, dass die Institute schon heute Problemlösungen ent- wickeln können, die in einigen Jahren für Wirtschaft und Gesellschaft relevant werden.

Für das Thema „mathematischer High-Performance-Solver für die Fraunhofer-Gesellschaft unter der Nutzung der institutseigenen HPC-Infrastrukturen“ schreiben wir diese Rahmenvereinbarung zu untenstehender Leistung mit einem Rahmenvereinbarungspartner aus.

Konkrete Vorstellung des Vorhabens:

Die Zentrale der Fraunhofer-Gesellschaft möchte für Ihre Institute, den im Zuge steigender Anfor- derungen an datengetriebene Modellierung, Simulation und Optimierung in Forschung und Ent- wicklung entstehenden, institutsübergreifenden Bedarf nach einer leistungsfähigen Softwarelö- sung zur mathematischen Optimierung decken. Lineare, gemischt-ganzzahlige sowie nichtlineare Optimierungsverfahren werden in verschiedenen Anwendungsfeldern eingesetzt, insbesondere in der Energiesystemanalyse, Marktsimulation sowie im Netzbetrieb und in der Netzplanung.

Ziel der Ausschreibung ist die strukturierte und wirtschaftliche Beschaffung entsprechender Soft- warelösungen, um eine einheitliche und langfristig verfügbare Softwarebasis zu gewährleisten. Dabei soll jedes Institut die Möglichkeit haben, die Software für sich zu betreiben. Die Anwendung gliedert sich dabei in zwei Fälle:

◼ Fraunhofer-Institute, die mathematische Optimierung in einer Vielzahl von Entwicklungspro- jekten einsetzen und bis zu 4000 Parallelisierungen laufen lassen. ◼ Fraunhofer-Institute, die mathematische Optimierung nun in wenigen Projekten einsetzen und daher einen geringen oder sogar gar keinen Bedarf an Parallelisierung haben.

2. Inhaltliche Anforderungen

Im Folgenden sind eingangs die grundsätzlichen Muss-Anforderungen und die weitergehenden inhaltlichen Anforderungen zusätzlich zur Kriterientabelle (Anlage) informativ beschrieben. In der Kriterientabelle wird klar zwischen F = Forderungskriterium (Muss-Anforderung) und B = Bewer- tungskriterium (Mindestforderung muss erfüllt sein; darüberhinausgehende Eigenschaften wer- den positiv bewertet) unterschieden. Bindend ist die Kriterientabelle. Die Fraunhofer-Gesellschaft verpflichtet sich zu keiner Abnahme der oben genannten inhaltlichen Anforderungen.

a) Anwendungsbereiche und Einsatzkontext (Muss-Anforderung)

Der Solver wird in Forschungs- und Entwicklungsprojekten mit Bezug zur Transformation von Energie- und Infrastruktursystemen eingesetzt. Typische Anwendungsfelder umfassen insbeson- dere (nicht abschließend):

◼ großskalige Energiesystemplanungsmodelle (z. B. Ausbau- und Transformationspfade), ◼ entscheidungsunterstützende Anwendungen im (nahezu) Echtzeitbetrieb von Energiesyste- men, ◼ Optimal-Power-Flow-Probleme bei Netzplanung und -Betrieb, ◼ Analysen und Studien zu flexibilitätsorientierten Marktdesigns, ◼ Portfolio- und Einsatzoptimierung in großskaligen Systemen.

Darüber hinaus werden die Solver im Rahmen fortgeschrittener algorithmischer Ansätze einge- setzt, insbesondere:

◼ verteilte Optimierungsverfahren (z. B. Progressive Hedging, ADMM-basierte Verfahren), ◼ Optimierung unter Unsicherheit (z. B. szenariobasierte Verfahren, Ensemble-basierte Progno- seintegration, mehrstufige Verfahren wie stochastische dynamische Programmierung), ◼ Gleichgewichts- und hierarchische Optimierungsmodelle, z. B. Mathematical Programs with Equilibrium Constraints (MPEC) sowie Equilibrium Problems with Equilibrium Constraints (EPEC).

b) Modellkomplexität und operative Anforderungen (Muss-Anforde-

rung)

Die zu lösenden Optimierungsmodelle weisen eine hohe strukturelle und numerische Komplexität auf. Daraus ergeben sich folgende Anforderungen:

◼ Verarbeitung sehr großer Modelle mit Variablen- und Nebenbedingungenumfängen von mehr als einer Million, ◼ Unterstützung zeitlich gekoppelter Optimierungsansätze (Multi-Period Coupling), ◼ Abbildung Szenario basierter Unsicherheiten sowie mehrstufiger Entscheidungsprozesse, ◼ Unterstützung von Modellstrukturen, die aus Dekompositions- und verteilten Lösungsverfah- ren resultieren (z. B. Teilprobleme mit Kopplungsrestriktionen), ◼ Eignung zur Integration in iterative Lösungsframeworks für Verfahren wie Progressive Hedging oder ADMM, ◼ Unterstützung gemischt diskret-kontinuierlicher Entscheidungsstrukturen, ◼ Verarbeitung quadratischer, bilinearer sowie allgemeiner nichtlinearer Modellbestandteile, ◼ Fähigkeit zur Behandlung von Modellen mit Gleichgewichtsbedingungen bzw. komplemen- taritätsbasierten Formulierungen (z. B. MPEC/EPEC, ggf. über geeignete Reformulierungen),

◼ Eignung für zeitkritische Anwendungen sowie für Dekompositionsverfahren bei sehr großen Instanzen, wie denen mit über 1 Million Variablen- und Nebenbedingungsumfängen, ◼ effiziente Nutzung von Parallelisierung und Hochleistungsrechenumgebungen (HPC).

c) Unterstützte Optimierungsproblemklassen (Kriterien Tabelle - 1.)

Die Lösung muss ein breites Spektrum konvexer und nichtkonvexer Optimierungsproblemklassen unterstützen, mindestens:

◼ Lineare Optimierung (LP), einschließlich sehr großskalige, dünn besetzte Probleminstanzen, ◼ Gemischt-ganzzahlige lineare Optimierung (MILP), ◼ Quadratische Optimierung (QP), konvex und nichtkonvex, ◼ Gemischt-ganzzahlige quadratische Optimierung (MIQP), konvex und nichtkonvex, ◼ Quadratisch restringierte Optimierung (QCP), konvex und nichtkonvex, ◼ Gemischt-ganzzahlige quadratisch restringierte Optimierung (MIQCP), konvex und nichtkon- vex, ◼ Second-Order Cone Programming (SOCP), ◼ Allgemeine nichtlineare Optimierung (NLP/MINLP): Algorithmen für lokale und globale Opti- malität und/oder unterstützende Workflows (Approximationen), soweit Problemklassen Ap- proximationen zulassen.

d) Deployment, Infrastruktur und Betriebsanforderungen (Kriterien

Tabelle - 2.)

Einsatzumgebung

◼ Primärer Einsatz in institutsbetriebener lokaler Hochleistungsrechenumgebungen (HPC), diese wird entweder inhouse betrieben oder als Kollokation bei einem RZ-Dienstleister (Inter- facing durch das Institut selbst, der RZ-Betreiber stellt nur Platz, Strom und einen Internet- Anschluss), ◼ Unterstützung eingeschränkter Netzwerkumgebungen (inkl. Offline- bzw. air-gapped-Be- trieb), ◼ keine zwingende Abhängigkeit von durch den Anbieter betriebenen Cloud-Diensten für Li- zenzierung, Nutzungskontrolle oder Betrieb.

Abgrenzung

Externes Hosting oder Software-as-a-Service (SaaS) ist nicht Bestandteil des Leistungsumfangs.

e) Skalierung, Parallelisierung und Lizenzmodell (Kriterien Tabelle - 3.)

Gleichzeitigkeit: Das Lizenzmodell muss die Durchführung von mindestens 4000 gleichzeitigen Solver-Läufen innerhalb eines einzelnen Instituts ermöglichen. Bei kleineren Anwendungsfällen muss auch die Möglichkeit gegeben sein, dass nur ein oder zwei Solver-Läufe zur selben Zeit möglich sind. Die Steuerung erfolgt über einen lokal betriebenen Lizenz- bzw. Token-Server, um die Leistung an einer Stelle zuteilen zu können.

Parallelität: Mehrkern- bzw. Multi-Thread-Fähigkeit pro Rechenlauf ist erforderlich. Die konkrete Ausprägung wird im Rahmen der technischen Bewertung berücksichtigt.

f) Schnittstellen und Integrationsanforderungen (Kriterien Tabelle -

4.)

Programmierschnittstellen: Es müssen APIs für folgende Programmiersprachen verfügbar sein: Py- thon, Java, C/C++, .NET, R, MATLAB.

Daten- und modellorientierte Workflows (mindestens innerhalb der Python-API): Die Lösung muss effiziente, matrixorientierte Modellierungsansätze zum effizienten Aufbau mathematischer Mo- delle auf matrixbasierten Objekten unterstützen.

Modellaustauschformate: Unterstützung etablierter Austauschformate (z. B. LP/MPS) sowie Funk- tionen zum Import und Export von Modellen (auch in anonymisierter Form) für die Zusammenar- beit im Hinblick auf Laufzeitminimierung und zur Sicherstellung reproduzierbarer Ergebnisse.

g) Solver-Funktionalitäten (Kriterien Tabelle - 5.)

Die Lösung muss folgende Funktionen bereitstellen:

◼ Unterstützung von Rückruffunktionen (Callbacks) sowie strukturierter Protokollierung (Log- ging), ◼ Export und Import von Solver-Parametern sowie Funktionen für systematisches Parametertu- ning, ◼ Unterstützung von Warmstarts, soweit anwendbar, ◼ Export von Lösungen in maschinenlesbaren Formaten, ◼ Bereitstellung eines Lösungspools bzw. mehrerer zulässiger Lösungen, soweit anwendbar, ◼ gleichzeitige Berechnung von verschiedenen Szenarien in einem Optimierungslauf, ◼ systematische Analyse und Vorschläge zur Auflösung von Unzulässigkeiten (Infeasibilities) im Optimierungsmodell.

h) Lizenzgrenzen und Nutzungsrechte (Kriterien Tabelle - 6.)

Lizenzobjekt pro Institut: Separates License Agreement pro Institut (je Institut mindestens eine Lizenz). Jedes Institut betreibt einen eigenen, lokal installierten Lizenz- bzw. Token-Server auf in- stitutseigener Infrastruktur (inkl. Kollokation bei einem RZ-Dienstleister). Eine gemeinsame Nut- zung von Lizenzservern oder Lizenzkontingenten über mehrere Institute hinweg darf keine Vo- raussetzung sein.

Nutzermodell: Die Nutzungsberechtigung wird begrenzt auf namentlich benannte Nutzer, affiliiert zum Institut.

Vertraulichkeit und Datenhandhabung: Der Betrieb mit vertraulichen Projekt- und Kundendaten auf institutseigener Infrastruktur (inkl. Kollokation bei einem RZ-Dienstleister) muss uneinge- schränkt möglich sein. Es darf keine verpflichtende Übertragung von Modelldaten, Instanzen, Pa- rametern oder Protokollen (Logs) an durch den Anbieter betriebene Systeme erfolgen.

i) Reproduzierbarkeit und Nachvollziehbarkeit (Kriterien Tabelle - 7.)

Die Lösung muss Funktionen zur Sicherstellung der Reproduzierbarkeit und Nachvollziehbarkeit von Optimierungsergebnissen bereitstellen, insbesondere:

◼ Deterministisches Lösungsverhalten, einschließlich deterministisches Verhalten unter Multi- Threading, soweit technisch möglich, ◼ eindeutige Identifikation der eingesetzten Softwareversion (z. B. Version, Build-Information) über APIs und/oder in Protokollen, ◼ Export und Import von Solver-Parametern zur Reproduktion identischer Konfigurationen, ◼ eindeutige Identifikation von Modellen bzw. Instanzen (z. B. durch Fingerprints oder ver- gleichbare Mechanismen), ◼ Export von Lösungen sowie Protokollen (Logs) in maschinenlesbaren Formaten zur externen Analyse und Überprüfung.

Die Fraunhofer-Gesellschaft verpflichtet sich zu keiner Abnahme der oben genannten inhaltli- chen Anforderungen.

3. Ausarbeitung des Angebots

Bieter müssen für die Kriterien Tabelle (Anlage), kurze Nachweise und Erläuterungen beifügen. Dabei wird zwischen F = Forderungskriterium (Muss-Anforderung) und B = Bewertungskriterium (Mindestforderung muss erfüllt sein; darüberhinausgehende Eigenschaften werden positiv be- wertet) unterschieden. Zusätzlich müssen die Eignungskriterien unter Punkt 7 mit entsprechen- den Referenzen und ausführlichen Nachweisen belegt werden.

Der Bieter hat im Angebot alle für den Betrieb relevanten technischen Lizenzierungs-, Aktivie- rungs- und Nutzungsbeschränkungen vollständig und nachvollziehbar darzustellen. Dabei sind insbesondere deren Auswirkungen auf den Offline- bzw. Air-Gapped-Betrieb, den Betrieb des lokalen Lizenz- bzw. Token-Servers sowie auf die jeweils angebotene Anzahl gleichzeitig zulässi- ger Solver-Läufe anzugeben. Soweit keine entsprechenden Beschränkungen bestehen, ist dies ausdrücklich zu bestätigen.

Außerdem erwarten wir:

◼ Fixer Preis, jährlich pauschal pro Institut ◼ Explizite Angabe der Leistungen welche im jährlich pauschalen Preis enthalten sind: ◼ Kommerzielle/Industrial-Research Nutzungsrechte innerhalb des Instituts ◼ Upgrades und neue Versionen während der Vertragslaufzeit

◼ Der Bieter beschreibt in seinem Angebot den im jährlichen Pauschalpreis enthaltenen Standard-Support. Dabei sind mindestens anzugeben: Die Angaben des bezuschlagten Bieters werden Bestandteil der Rahmenvereinbarung und der auf ihrer Grundlage geschlossenen Einzelaufträge. Soweit einzelne Angaben nicht für alle Institute oder Leistungsvarianten einheitlich gelten, sind die jeweiligen Ab- weichungen eindeutig darzustellen.

o verfügbare Supportkanäle und Möglichkeiten zur Nachverfolgung,

o Annahme- und Servicezeiten unter Angabe der maßgeblichen Zeitzone und etwaiger Fei- ertagsregelungen, o angebotene Supportsprachen, o Kriterien für die Einstufung und Priorisierung von Störungen und Anfragen, o Reaktionszeiten je Prioritätsstufe, o der Umfang der verfügbaren technischen Wissensressourcen.

◼ Umgang Personenbezug (wissenschaftliche Mitarbeiter und Studenten des Institutes), ein- deutige Zuordnung über die institutseigene E-Mail-Adresse. ◼ Wie Muss-Kriterien erfüllt werden. ◼ Optionale Leistungen (nicht Teil der Bewertung, müssen nicht angegeben werden) ◼ optionale KI-gestützte Support-Funktionen (LLM-gestützt), sofern angeboten, ohne dass vertrauliche Kunden-/Projektdaten übertragen werden müssen

◼ GPU-Unterstützung: Der Bieter hat anzugeben, ob und in welchem Umfang GPU-be- schleunigte Verfahren für die Lösung von LPs und MILPs unterstützt werden. Einschrän- kungen sowie notwendige Hardwarevoraussetzungen sind darzustellen. Die Bewertung erfolgt im Rahmen der technischen Eignung.

◼ Auf Wunsch des Auftraggebers erbringt der Bieter kostenlose Hilfe via Remote Installati- ons-Assistenz. Bieter benennen etwaige angemessene Einschränkungen transparent. ◼ Zusätzliche Schulungstage, inkl. beschreiben verfügbare Trainingsformate ◼ Generell: Bieter geben hier zusätzlich an welche Leistungen frei verfügbar, welche kosten- frei auf Anfrage und welche kostenpflichtig sind. Bieter geben in letzteren Fall einen ver- bindlichen Preis an.

Die Fraunhofer-Gesellschaft bittet um ein – dem oben genannten Bedarf entsprechendem – An- gebot:

◼ Die Angabe einer konkreten Ansprechperson inkl. Kontaktdaten, welche für die Ausschrei- bung verantwortlich ist. ◼ Ausfüllen der Tabelle Merkmal/Funktion ◼ Preis und Explizite Angabe der Leistungen ◼ Optionale Leistungen

Bieter reichen ein als PDF folgende Dateien ein:

◼ Die Angabe einer konkreten Ansprechperson inkl. Kontaktdaten, welche für die Ausschrei- bung verantwortlich ist. ◼ Ausgefüllter Kriterienkatalog bzw. entsprechende Nachweise (siehe Anlage) ◼ Zusammenfassung der Nutzungsrechte (1–2 Seiten) in verständlicher Sprache: Explizite An- gabe der Leistungen, welche im jährlich pauschalen Preis enthalten sind ◼ Ausgefülltes Preisblatt (Vorlage) ◼ Mindestabnahmepreis für die Fraunhofergesellschaft pro Jahr für 5 Institute (EUR/Jahr) ◼ Pauschalpreis pro Institut und Jahr (EUR/Jahr) für bis zu 4000 parallele Berechnungen ◼ Pauschalpreis pro Institut und Jahr (EUR/Jahr) für bis zu 2 parallele Berechnungen ◼ Optionale Leistungen (Trennung zwischen kostenlos und inkludiert, kostenlos auf An- frage, kostenpflichtig mit verbindlicher Preisangabe) o optionale KI-gestützte Support-Funktionen (optional, auf Wunsch): EUR zusätzli- che Lizenzkosten o Remote-Installationsunterstützung (optional, auf Wunsch): EUR zusätzliche Li- zenzkosten o Tagessatz für zusätzliche Schulungstage (EUR/Tag) ◼ Hinweise/Einschränkungen (falls vorhanden) ◼ Technische Dokumentation und Nachweise gemäß Eignungskriterien (Abschnitt 7).

4. Leistungszeitraum

1. Oktober 2026 für 3 Jahre, Vertragsende: 30. September 2029

Optional: Späterer Beginn für Institute, welche den Vertrag aufgrund noch laufender Lizenzen späterer abschließen, mit entsprechend um die kürzere Laufzeit reduzierten Preis.

4.1 Geschätztes Volumen

Das maximale Abrufvolumen des Vertrags umfasst 1.000.000 € für 3 Jahre. Alle Einzelabrufe bzw. Einzelverträge beginnen zu dem im jeweiligen Abruf festgelegten Zeit- punkt und enden einheitlich mit Ablauf der Rahmenvereinbarung am 30. September 2029. Bei einem unterjährigen Beginn verkürzt sich die Laufzeit entsprechend; der jährliche Pauschalpreis ist zeitanteilig zu berechnen. Eine über die Laufzeit der Rahmenvereinbarung hinausgehende Vertragsbindung entsteht nicht.

5. Abnahme

Lieferung:

◼ Installer/Binaries für lokale Hochleistungsrechenumgebung (HPC) Bereitstellung ◼ User- und Administrator-Dokumentation ◼ Beispiele und Sample Code für unterstützte APIs ◼ Lokaler Token- bzw. Lizenzserver Software ◼ Admin Guide für Setup und Betrieb des Token-/Lizenzservers

Abnahme der Lieferung erfolgt, wenn:

◼ erfolgreiche Installation auf institutseigener Infrastruktur (inkl. Kollokation bei einem RZ- Dienstleister), und ◼ Lokaler Token- bzw. Lizenzserver installiert, konfiguriert und operational ist (validiert durch erfolgreichen Client-Lizenzabruf/Nutzung).

6. Zahlungsbedingungen

Die Zahlung wird in Jahresscheiben gezahlt und hat ein Zahlungsziel von 30 Tagen netto nach Rechnungseingang.

7.Eignungskriterien

Bieter müssen vorlegen:

8. Zuschlagskriterien

◼ Preis: 50% o Preis jährlich pauschal pro Institut für mindestens 4000 parallele Berechnungen ohne Optionen ◼ Technische Qualität / Leistungsfähigkeit: 50% o Auswertung der Bewertungskriterien B der Kriterientabelle