Activity

1. FBumann

   assigned

   baumbude

   ,

   PStange

   and

   FBumann

   on Apr 6, 2025
2. FBumann commented on Apr 6, 2025

   

   FBumann

   on Apr 6, 2025

   Last edited by FBumann

   MemberAuthor

   More actions

   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
3. baumbude commented on Apr 8, 2025

   

   baumbude

   on Apr 8, 2025

   Last edited by baumbude

   Collaborator

   More actions

   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.
4. FBumann commented on Apr 8, 2025

   

   FBumann

   on Apr 8, 2025

   Last edited by FBumann

   MemberAuthor

   More actions

   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
5. FBumann commented on Apr 8, 2025

   

   FBumann

   on Apr 8, 2025

   Last edited by FBumann

   MemberAuthor

   More actions

   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).
6. baumbude commented on Apr 9, 2025

   

   baumbude

   on Apr 9, 2025

   Last edited by baumbude

   Collaborator

   More actions

   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
7. FBumann commented on Apr 10, 2025

   

   FBumann

   on Apr 10, 2025

   MemberAuthor

   More actions

   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?
8. FBumann

   added the

   Feature

   issue type on Jun 23, 2025
9. FBumann

   added

   New functionalityAdd entirely new functionalityAdd entirely new functionality

   on Jun 23, 2025
10. FBumann

    linked a pull request that will close this issueV3.0.0/invest #294on Sep 11, 2025
11. FBumann commented on Oct 13, 2025

    

    FBumann

    on Oct 13, 2025

    MemberAuthor

    More actions

    Closed by #348
12. FBumann

    closed this as completedon Oct 13, 2025