Multiplication of a invest decison value and timeseries data doesn't work

[nyashags]

Multiplying an invest decision value with a timeseries value returns an error because then the invest decision value or the timeseries is not recognized, but I think this would be a useful functionality to have.

For example, I have timeseries data with heat output per m2 for solar thermal and would like to multiply this with an invest decision for how many m2 of solar thermal should be built, and use this as the value for my solar thermal supply profile.

I can multiply either the decision variable or the timeseries data by a scalar like this:

    value: 2 * solar_thermal_heat_out_per_m2@hourly_data 
    value: 2 * solar_thermal_area_invest:value 

However multiplying the decision value by the timeseries data as i would like to doesnt work:

    value: solar_thermal_area_invest:value * solar_thermal_heat_out_per_m2@hourly_data

Example code for all the components:

components:
  # Supply: solar thermal and invest decision on m2
  solar_thermal:
    type: Profile
    mode: fixed
    carrier: heat
    node_to: grid_heat
    value: solar_thermal_area_invest:value * solar_thermal_heat_out_per_m2@hourly_data # multiply m2 built  by heat output per m2
  solar_thermal_area_invest: 
    type: Decision
    lb : 0  
    ub: 20  # m2
    cost: 10  # €/m2
    
  # Heat grid
  grid_heat:
    type: Node
    carrier: heat
  
  # Demand profile and extra destroy profile in case there is more solar thermal than demand
  demand: 
    type: Profile 
    carrier: heat
    node_from: grid_heat
    value: demand_heat@hourly_data
  destroy_heat_surplus:
    type: Profile
    carrier: heat
    mode: destroy
    node_from: grid_heat
    cost: 1e6    

[sstroemer]

Yea... that's a current limitation of the way we parse "strings in YAML" to what we internally call "expressions". There is a rework (and more related issues) in the internal GitLab (not linking here, but see merge request "# 23" there), but we currently do not have any proper solution for that here.

I'll keep this open as it is - maybe I'm able to include this into the currently open redesign in #20 (since then we could keep a few breaking changes in one take). But in the meanwhile, I'll post a "solution" in the next comment.

[sstroemer]

Workaround:

Since you actually allow for "getting rid of heat" (via destroy_heat_surplus), this could be seen as a curtailable solar thermal asset, right? If it the case that it is okay to not use the full available heat during each time step, then all of this (the curtailment, the investment, and the scaling) are better handled by a Unit (Profiles are not made for this type of thing).

The following could be a reformulation that should work:

  grid_heat:
    type: Node
    carrier: heat
  
  demand:
    type: Profile 
    carrier: heat
    node_from: grid_heat
    value: demand_heat@hourly_data

  solar_thermal:
    type: Unit
    outputs: {heat: grid_heat}
    conversion: ~ -> 1 heat
    capacity: solar_thermal_area_invest:value out:heat
    availability_factor: solar_thermal_heat_out_per_m2@hourly_data

  solar_thermal_area_invest: 
    type: Decision
    lb : 0  
    ub: 20
    cost: 10

Observe:

• The ~ -> 1 heat conversion, which just means "open input" (therefore also no inputs defined), which is just a convenience thing that we have especially for renewables: Generating energy, using a Unit, but - while there certainly is an "input primary energy" - not caring about the actual input use of energy.
• Curtailment does not induce costs now (1e6 previously), which may or may not be wanted - but that is an actual difference to your example.
• But if there are actual costs to consider they are (almost) definitely not 1000000 EUR per unit of heat, and should then be changed to a correct value (just pointing this out, since - depending on the other data - this 1e6 may be an unnecessary source for numerical problems).

Does that work for now?

[sstroemer]

This was fixed as part of #20, see this comment for details.

[sstroemer]

@nyashags Please report back whether this left any special case non-working or whether everything's fixed now.