Error when using additional constrains in solph 0.5.0

I am modelling a pv system that could feed both a battery and the main demand. So the system has a pv SInk and a Transformer with two outputs: 1 for the BESS electricity bus and other for the main electricity bus. I want that the quantity of flow in the transformer is the same as out of the Transformer. For that I decided to use either the additional constraint “equate_flows” (so the sum of both out is the same as the one in) or the additional constrain "limit_active_flow_count (only one output flow can be active). I am aware that they do different this but they are both quite valid at this stage of my model.
I am, with both of them, encountering this error “‘EnergySystem’ object has no attribute ‘TIMESTEPS’”, EnergySystem being a solph.EnergySystem object. I am using solph 0.5.0, but I have tried it with 0.5.1dev2, as I have seen in here Releases · oemof/oemof-solph · GitHub that this might have been fixed. But with either version, I run in that error for both constraints. Is anyone aware of the issue or has encounter it before, and could you help me? Thanks in advance :slight_smile:

Hi @pebasantaf,

I have two questions:

  1. Does the energy system solve without without the additional constraints?
  2. (If yes:) Could you please provide a sketch of the graph or the code?

Hi @pschoen ,

  1. The system solves without the additional constrains, yes.
  2. You can find the code below. Essentially, I want the output of the pv_converter to go either to the main electricity bus “electricity” or to the battery bus “electricity_bess”. For what I saw and understood, the way converters act, the sum of the flows in is not automatically equal to the sum of the flows out. That has to be set with the conversion factors “conv_efficiency”. My issue is that then this output flows are fixed in their % to the input, and I’d like the optimizer to decide the optimal distribution.
    The **inputs[0] are just the solar generation and the capacity.
bpv = solph.Bus(label='electricity_pv')
pv = solph.components.Source(
            outputs={bpv: solph.Flow(**inputs[0])})
conv_outputs= {esystem.groups['electricity']: solph.Flow(),
               esystem.groups['electricity_bess']: solph.Flow()}
conv_efficiency = {esystem.groups['electricity']: 0.495, #efficiency towards the main electricity
                   esystem.groups['electricity_bess']: 0.5} #efficiency towards battery. We set 1, as the bess istelf already considers the efficiency

pv_converter = solph.components.Transformer(
            inputs={bpv: solph.Flow()},

esystem.add(bpv, pv, pv_converter)

Therefore, I decided to add this constraint (esystem is the energy system object and “electricity_pv” is the bus to which the solar Sink give its energy):

                flows1=[esystem.flows()[(esystem.groups['electricity_pv'],esystem.groups['pv_converter'] )]],
                flows2=[esystem.flows()[(esystem.groups['pv_converter'],esystem.groups['electricity_bess'] )],
                        esystem.flows()[(esystem.groups['pv_converter'],esystem.groups['electricity'] )]],

And when I add that, I get the error I mentioned.

Hi @pebasantaf,

The code you shared will give the following constraints.

For the Transformer:

0.495 * P(bpv -> pv_converter) = P (pv_converter -> electricity)
0.5 * P(bpv -> pv_converter) = P (pv_converter -> electricity_bess)

For the additional constraint:

0.96 * P(electricity_pv -> pv_converter)
= P(pv_converter -> electricity_bess) + P(pv_converter -> electricity)

So, in total you have 0.495 + 0.5 = 0.96, which is infeasible.

If you want an either/or decision, you cannot use just one Transformer (or Converter) as it has a constant proportionality between all inputs and outputs. Instead, you need to define to Converters with different efficiencies. So, the graph will look like this:

          | -> conv_pv_el -> electricity
pv -> bpv | 
          | -> conv_pv_el_bess -> el_bess

When setting a power for the PV panels, the total power of the inverter(s) will automatically be limited.

Hi @pschoen ,

Thanks a lot. The either/or logic is just what a was looking for.