Battery Component profits from simultaneous in- and outflow

[j-brendel]

Because of the usage of niominal value in the P_max_in and P_max_out definitions, the battery can't be used for MPC Simulations.

Idea:
Silmlify with Nominal Value for MPC compliance.

For Coherence updated Component should have these properties:

• Discharge and Charge Symmetrical
  
  

• keep 100 % possible
  

• Same behaviour 1 min and 60 min interval time

[j-ti]

With the correct loss rate and efficientcy coefficients, eomof handels everything on its own and correctly.

The reason for the constant loading in #212 appears when -vac_in <= vac_out and -vac_in > variable grid cost, as it oemof does not distinguish between artificial or normal costs and makes profits from high inflow (negative cost) although outflow with equal vac as there is energy loss on in and out flow (e. g. 100 Ah * 0.95 * 0.95 = 90.25 Ah). As energy flowing out is less, than inflow, even equal +/-vac results in a net negative value.

=> vac_in and vac_out should always be below the grid costs.

[j-brendel]

With these changes, only one consistency criteroin is broken:
Charging and discharging are not symmetrical:

Could we modify max_power in battery component to:

    self.p_in_max = self.c_rate_charge * self.battery_capacity / self.efficiency_charge
    self.p_out_max = self.c_rate_discharge * self.battery_capacity * self.efficiency_discharge

This solves this issue, do you think it creates others?

I used these files to create plots for consistency checks:
example_Battery.zip

[j-ti]

The problem of simultaneous charging and discharging seen for MPC example #212 (comment) for specific variable artificial costs is a known issue within oemof, that is already resolved by introducing a custom constraint within version 0.4, which does not yet contain the piecewise linear transformer used by smooth.

Probably, this component will be merged within the next release, we could then use, but might still take some time. So, based on the oemof-code copy i was able to use the constraint functionality already for SMOOTH's current oemof version 0.3.3.

without flow count constraint

with flow count constraints

[j-ti]

PR #223 was merged containing the new maximum nominal power definition

[j-brendel]

Solved with #261