Investment per Scenario

[FBumann]

In the currently planned update #212 , to add scenarios to flixOpt, the Investment decisions are not yet integrated on a scenario basis.
All related variables (size, optional, ...) are still a single scalar, which effectively equalizes the size in all scenarios.
This Issue is meant to provide a place to discuss thoughts on what could/should be possible regarding the size through multiple scenarios.

Currently existing variables and constraints in Investment

Variables

• size
• optional (is the investment taken or not

Constraints

• min/max size bounds
• Shares from size and optional

[FBumann]

Investments

Current state

$$ \beta_{\text{invest}} \cdot \text{max}(\epsilon, \text V^{\text L}) \leq V \leq \beta_{\text{invest}} \cdot \text V^{\text U} $$

With:

• $V$ = size
• $V^{\text L}$ = minimum size
• $V^{\text U}$ = maximum size
• $\epsilon$ = epsilon, a small number (such as $1e^{-5}$)
• $\beta_{invest} \in {0,1}$ = wether the size is invested or not

Please edit the use cases as needed

Quickfix 1: Optimize the single best size overall

Single variable

This is already possible and should be, as this is a needed use case
An additional factor to when the size is actually available might me practical (Which indicates the (fixed) time of investment)

Math

$$ V(p) = V * a(p) $$

with:

• $V$ = size
• $a(p)$ = factor for availlability per period

Factor $a(p)$ is simply multiplied with relative minimum or maximum(t). This is already possible by doing this yourself.
Effectively, the relative minimum or maximum are altered before using the same constraiints as before.
THis might lead to some issues regariding minimum_load factor, or others, as the size is not 0 in a scenario where the component cant produce.
**Therefore this might not be the best choice. See (#Variable per Scenario)

Variable per Scenario

• size and invest as a variable per period $V(s)$ and $\beta_{invest}(s)$

Usecase 1: Optimize the size for each Scenario independently

No changes needed. This could be the default behaviour.

Usecase 2: Optimize ONE size for ALL scenarios

The size is the same globally, but not a scalar, but a variable per scenario $V(s)$

Math

$$ V(s) = V(s') \quad \forall s,s' \in S $$

With:

• $V(s)$ and $V(s')$ = size
• $S$ = set of scenarios

This could be the default behaviour. (which would be consistent with other variables)

Usecase 3: Find the best scenario to increment the size (Timing of the investment)

The size can only increment once (based on a starting point). This allows to optimize the timing of an investment.

Math

Treat $\beta_{invest}$ like an ON/OFF variable, and introduce a SwitchOn, that can only be active once.

Thoughts:

• Treating $\beta_{invest}$ like an ON/OFF variable suggest using the already presentconstraints linked to On/OffModel
• The timing could be constraint to be first in scenario x, or last in scenario y
• Restrict the number of consecutive scenarios
  THis might needs the OnOffModel to be more generic (HOURS). Further, the span between scenarios needs to be weighted (like dt_in_hours), or the scenarios need to be measureable (integers)

Others

Usecase 4: Only increase/decrease the size

Start from a certain size. For each scenario, the size can increase, but never decrease. (Or the other way around).
This would mean that a size expansion is possible,

Usecase 5: Restrict the increment in size per scenario

Restrict how much the size can increase/decrease for in scenario, based on the prior scenario.

Many more are possible

[baumbude]

Es gibt etwas, für das ich aktuell Investment nutze: Leistungspreise! Diese werden monatsweise, quartalsweise oder Jahresweise erhoben.
D.h. da müsste es eine used_size_in_period geben, die man dann mit dem Leistungspreis also effective_costs_per_used_size_in_period kombiniert. Ggf. ist das eine etwas anders gelagerte Fragestellung, aber es geht eben auch um periodenabhängige (hier wirklich Perioden) Definition von Kosten.
Ziel müsste aber eben sein, dass ich beides, Investition und Leistungspreise, gleichzeitig nutzen kann.

[FBumann]

Es gibt etwas, für das ich aktuell Investment nutze: Leistungspreise! Diese werden monatsweise, quartalsweise oder Jahresweise erhoben.
D.h. da müsste es eine used_size_in_period geben, die man dann mit dem Leistungspreis also effective_costs_per_used_size_in_period kombiniert. Ggf. ist das eine etwas anders gelagerte Fragestellung, aber es geht eben auch um periodenabhängige (hier wirklich Perioden) Definition von Kosten.
Ziel müsste aber eben sein, dass ich beides, Investition und Leistungspreise, gleichzeitig nutzen kann.

Kannst du das etwas präzisieren?

Wenn beides von der gleichen variable abhängt (size), dann kannst das über 2 Effekte abbilden, oder direkt aufsummieren.

Oder willst du eine globale size und eine "sub-size"?
Wie integriert sich das in die anderen Bereiche?
Und ist das eine generelle Neuerung oder nur für die scenarien?
@baumbude

[FBumann]

Das gabze würde m.M.n. Bedeuten, dass man eine extra variable $v$ braucht mit size $s$ und es gilt v <= s

Zusätzlich gilt noch (mit der flow_rate $p$)
v >= p(t) for t in T

Wenn das je scenario ist wäre das einfach, da bekannt ist über welchen zeitbereich T das gilt.
Wenn man das ohne scenarien machen will ist's schwieriger dass allgemeingültig zu machen.
Da muss man entweder angeben in welcher Auflösung man das haben will, oder es gibt mehrere Optionen direkt (monthly, Daily, yearly,...)

Die entsprechende Zeitreihe hätte dann jedoch eine andere Auflösung als die normalen TimeSeries.
Das kollidiert beim indexieren (active timesteps).

[baumbude]

Ja, genau. Könnte dann derart aussehen:

# spezifischer Preis: 
costs_per_used_size = [23, 24] €/kW, Preissteigerung 1 €

# Periods
periods = [Period(from_1,to_1), Period(from_2,to_2)]
# oder:
periods = getPeriods(timesteps, delta='monthly')

# Parameter
effective_costs_per_used_size_in_period = (periods , costs_per_used_size)

und selbst eine separate Variable used_size über den ganzen Zeitbereich kann Sinn machen, wenn die size beispielsweise des Elektroanschlusses durch die Nennleistung der Maschine fest definiert, aber die real abgerufene Leistung used_size dann kleiner ist.

Ich mache das Thema auf, weil es ja ggf. Schnittmengen mit den Scenarios gäbe. Noch nicht zu Ende gedachte Gedanken dazu:

1. abbildung über subscenarios (scenarios wäre dann ggf. der Falsche Begriff)
2. Zeichnen sich die Scenarios, Periods oder was auch immer nicht einfach nur dadurch aus, dass zwischen angrenzenden "Scenarios" ein Cut für verschiedene Funktionalitäten gemacht wird, also z.B. Speicherzustand, switch_on_total_max, used_size? Demnach könnte man "Scenarios" eher als "Abschnitte" bezeichnen. "Abschnitte könnten dann so verwendet werden, wie du willst als Scenarios" aber eben auch für andere Cuts. Es könnte dann auch für verschiedene Funktionalitäten unterschiedliche Abschnittsdefinitionen, die sich auch überlagern können, z.B.:

Funktionalität	Abschnittsdefinition
switch_on_total_max	monthly
speicherzustand, effects_sum, ...	scenarios
used_size	quarterly

Im postprocessing müsste man dann schauen, dass man eine Funktionalität baut, die die Daten eben auch beliebig in eine dieser Abschnittsdefinition umstrukturieren kann.

-> Und ja, man müsste schauen, wie man das pragmatisch und robust mit den active_timesteps umsetzt

[FBumann]

Hmmm.
Ist an sich ne gute Sache.
Folgende Ideen hätte ich dazu:

1. für die Abschnittte/Periods würde ich pd.Index Objekte nehmen. Das ist deutlich generischer und robuster.
2. Das ganze ist m.M.n. völlig unabhängig von den Szenarien einfach eine neue funktionalität/variable, die es dann auch je scenario gibt
   Ich sehe folgende Probleme:
3. Korrespondierende Effekte haben keine Auflösung "timesteps", sonder eine neue. Das führt zu Problemen bei der Auswertung bei der Formulierung und der Auswertung. (Share zum invest oder zur operation? Zum total oder je Periode?. Da würde bedeuten jeder Effekt braucht noch eine weitere auflösung/index

Kannst du das mal umsetzten und schauen wies sich macht?