Rebased to the actual master now. Had an old state. The test failures are deprecations in the master branch.

Instead of setting rateX=1 to specify the reference bus, how about specifying the reference bus explicitly, e.g. with

reference_bus="bus1"

That way, the rates have no implied meaning and users do not need to calculate the rates relative to one particular rate (one less calculation step that can be erroneous).

Say in your example you have the inputs and outputs of the process in absolute values, then you could plug these values directly (dummy values, with approx 5 MWh/t ammonia)

n.add(
    "Process",
    nodes,
    suffix=" Haber-Bosch",
    bus0=nodes,
    bus1=spatial.ammonia.nodes,
    bus2=nodes + " H2",
    p_nom_extendable=True,
    carrier="Haber-Bosch",
    rate0=-1.2,
    rate1=5,
    rate2=-5.5,
    reference_bus="bus1",
    capital_cost=costs.at["Haber-Bosch", "capital_cost"],
    marginal_cost=costs.at["Haber-Bosch", "VOM"],
    lifetime=costs.at["Haber-Bosch", "lifetime"],
)

Hi, @euronion, the reference_bus would then be for fixing the units for capital and marginal costs?

Efficiencies are already fully determined by the ratios of the rates. Not sure what this would then do? I think i fail to understand what would be the input data that would lead you to set

   rate0=-1.2,
   rate1=5,
   rate2=-5.5

do factsheets of a process not always report efficiencies as ratios between ports?

In your example, the process is producing 5 t of ammonia, by consuming 1.2 MWh of electricity and 5.5t H2. Did you mean that? And marginal costs are expected as Eur/5t ammonia or Eur/1.2MWhel.

Setting the reference bus to bus1 would then allow you to specify it as Eur/t ammonia, i guess.

Hi, @euronion, the reference_bus would then be for fixing the units for capital and marginal costs?

Efficiencies are already fully determined by the ratios of the rates. Not sure what this would then do? I think i fail to understand what would be the input data that would lead you to set

   rate0=-1.2,
   rate1=5,
   rate2=-5.5

do factsheets of a process not always report efficiencies as ratios between ports?

In your example, the process is producing 5 t of ammonia, by consuming 1.2 MWh of electricity and 5.5t H2. Did you mean that? And marginal costs are expected as Eur/5t ammonia or Eur/1.2MWhel.

Setting the reference bus to bus1 would then allow you to specify it as Eur/t ammonia, i guess.

Yes, you understood that correctly.
While there are some cases where technology data sheets are not normed, my suggestion primarily stems from the urge to not hide and imply the "reference_bus" information based on the rate_X=1 setting, but to make it explicit.

I'll wait for #1349 to land and then rebase on that.

Couple of TODOs in the code, @lkstrp Would you mind reviewing already, whether i made obvious mistakes (or fucked up any of your excellent component work)

I only skimmed this, not questioning the processes component, but you are adhering to the component architecture wonderfully 👍

Instead of reference_bus="bus0", we introduce relative_to="bus1" to make it explicit, to be provided as required argument.

Instead of reference_bus="bus0", we introduce relative_to="bus1" to make it explicit, to be provided as required argument.

@coroa I thought about it again: I imagine use cases where you have a process component with a reference unit, however the sector of that reference unit is not in the system (or not any more). For example you want to model haber-bosch without the explicit ammonia sector, just model the hydrogen and electricity consumption, potentially keeping the same dispatch of the HB asset from a previous run. In that case you would loose the flexibility to use the original rate data and have to convert all units to either hydrogen or electricity.

Therefore, the way I see it, most flexibility you gain with discarding the reference bus and allow for arbitrary rate values. The output of the process would contain a p (along with p0, p1, ...) which itself indicates the internal, reference operation of the process. If rate<n>=1 then p==p<n> . however the latter is not a requirement. Like this you allow for arbitrary selections of in- and outputs of your process while keeping the same input data. Does that make sense?

Instead of reference_bus="bus0", we introduce relative_to="bus1" to make it explicit, to be provided as required argument.

@coroa I thought about it again: I imagine use cases where you have a process component with a reference unit, however the sector of that reference unit is not in the system (or not any more). For example you want to model haber-bosch without the explicit ammonia sector, just model the hydrogen and electricity consumption, potentially keeping the same dispatch of the HB asset from a previous run. In that case you would loose the flexibility to use the original rate data and have to convert all units to either hydrogen or electricity.

Therefore, the way I see it, most flexibility you gain with discarding the reference bus and allow for arbitrary rate values. The output of the process would contain a p (along with p0, p1, ...) which itself indicates the internal, reference operation of the process. If rate<n>=1 then p==p<n> . however the latter is not a requirement. Like this you allow for arbitrary selections of in- and outputs of your process while keeping the same input data. Does that make sense?

well I agree with you, and this internal dispatch is also already in the code, since it made sense anyway, but that is not what was decided.

well I agree with you, and this internal dispatch is also already in the code, since it made sense anyway, but that is not what was decided.

I think this was not fully clear to the other (at least it wasn't to me). The flexibility would be very helpful and we should go for it. @lkstrp @brynpickering @euronion let's reconsider? perhaps @fneum also has a view on this

🚫 I'm still strongly in favour of making this information explicit, not implicit.

✔️ I do see the point that you are making for cases where the reference is not available or part of the system/process.

An option could be a compromise, where we allow overloading of relative_to to be either the reference bus (to avoid the user having to specify redundant values) or the reference rate explicitly:

relative_to: str | float = "bus1"
# or
relative_to: str | float = <p>

I took a stab at an implementation of relative_to today,

n.add(
    "Process",
    nodes,
    suffix=" Haber-Bosch",
    bus0=nodes,
    bus1=spatial.ammonia.nodes,
    bus2=nodes + " H2",
    p_nom_extendable=True,
    carrier="Haber-Bosch",
    rate0=-costs.at["Haber-Bosch", "electricity-input"],  # negative rate consumes
    rate1=1,   # positive rate produces; 1 sets the reference bus
    rate2=-costs.at["Haber-Bosch", "hydrogen-input"],
    capital_cost=costs.at["Haber-Bosch", "capital_cost"],
    marginal_cost=costs.at["Haber-Bosch", "VOM"],
    lifetime=costs.at["Haber-Bosch", "lifetime"],

    relative_to="bus2",
)

Ie. the internal dispatch variable is synced with the ammonia output; the relative_to is choosing the hydrogen input as the reference.

I think this means, that the marginal_cost should be in - x Eur/t hydrogen (minus sign, because of an input).

Does this mean that p_nom_opt is then expected in t hydrogen?

if so, i think that means i need to actually rescale all the rate variables internally by that rate2:
rateX_effective = rateX_nom / rate2.

An option could be a compromise, where we allow overloading of relative_to to be either the reference bus (to avoid the user having to specify redundant values) or the reference rate explicitly:

relative_to: str | float = "bus1"
# or
relative_to: str | float = <p>

That's a bit complicated by the fact that we are starting to allow also just the port numbers as integers as valid port signifiers, as introduced in #1386 .

If we tried to be consistent, then this would mean relative_to=2 would mean relative to rate2 and relative_to=2. would mean relative to a rate of 2.0.

I didn't know about the port and discussion in the other PR. Is it a good idea to allow just the port numbers as integers? I understand it is convenient, at the same time it reduces our degrees of freedom for future development (maybe?).

Having relative_to=2 and relative_to=2.0 behave differently seems like a bad idea to me.
If port is being used already anyways, what about reference_port = str | int?

Shall we revisit this discussion next Wednesday and collect the options and ideas again by then?

I think this was not fully clear to the other (at least it wasn't to me). The flexibility would be very helpful and we should go for it. @lkstrp @brynpickering @euronion let's reconsider? perhaps @fneum also has a view on this

I talked with both Fabians again, and @fneum is also very much in favor of keeping this implicit without the need for an extra attribute. Just bring one of your rates to 1 and all good. I think this is also more intuitive and simpler. I am also against any of those mixed solutions where reference_to could be optional. Since @coroa and @FabianHofmann see it the same way I guess the vote would have changed already anyway. Could still discuss that next week (again) if you think it's needed

After the arguments that @brynpickering shared about making it explict I was under the impression last time that explicit should be preferred.

But feel free to go ahead if that is the current majority vote.

thanks for being flexible @euronion on this (it's always a back and forth, isn't it). if we see there the interpretation is too complicated we still can add explicit things later

@lkstrp could you have a look at the multiports.py. I had to pull in some types to collect the shared functions, don't know how clean that is. also I am importing the Multiports from _types in descriptors.py (better avoided?)

@lkstrp @coroa I addressed all the open comments and closed them after addressing (otherwise I would have lost track). I will look out for the CI now, but otherwise this seems good to go

I would add one more test and "bug fix" that columns from attributes from additional port are appearing after there predecessor

The Process component looks very neat and elegant. Excellent!

I have one request for the finishing touches before merging:

The Process component is currently absent from the formulations in the user guide (i.e. subsequent sections of https://pypsa--1333.org.readthedocs.build/1333/user-guide/optimization/overview/). Could you complete this with the Process component everywhere? Some elements can probably be handled similarly jointly as Line and Transformer component.

The Process component looks very neat and elegant. Excellent!

I have one request for the finishing touches before merging:

The Process component is currently absent from the formulations in the user guide (i.e. subsequent sections of https://pypsa--1333.org.readthedocs.build/1333/user-guide/optimization/overview/). Could you complete this with the Process component everywhere? Some elements can probably be handled similarly jointly as Line and Transformer component.

good point! done