Periodic value deserialization

[nailend]

close #115

if multi-period approach is taken (periods resource exists):

• facade parameters are checked if list and length equals number of periods
• a full time series is generated with period specific values

This is only possible for certain parameters, otherwise building the energy system fails.

• warning is raised every time periodic values are converted to a timeseries

Attention:

The investment parameters work differently. One period specific value is enough, and a whole timeseries is not necessary. Check here

e.g. "fixed_costs" "capacity_costs"

These period values are handled differently:

• no timeseries is created
• only list of values for every period are passed

[nailend]

Change in oemof.solph issue 983 might have an effect on this

[nailend]

@henhuy not sure what's happening here and why the tests fail. Locally, there is no error ... Could you please check locally as well?

[henhuy]

I could reproduce error with latest python version 3.9.18 - in 3.9.16 error did not occur. Could not figure out what has been changed in between those versions, though. Error comes up, as Flow component "has" an attribute _in_edges, but for some reasons the attribute cannot be accessed and therefor throws an error: https://github.com/oemof/oemof-solph/blob/f02297ea7db0134bfff12c3ff6c7c909ca4405ed/src/oemof/solph/processing.py#L515-L532 Fix could be to reverse checking:

attrs = [
    i
    for i in dir(com)
    if not (i.startswith(exclusions) or callable(getattr(com, i)))
]

We could implement this fix in oemof.solph - but first we would have to add a failing test to show and explain what's happening.

[nailend]

Strange... python version 3.9.18 is from August'23 and was also already used in this CI run which wasn't failing.

[nailend]

I found it. It's caused by changes in oemof.network apparently version 0.5.0a1 was still working. This might be of interest to you, @p-snft ?

[p-snft]

Unfortunately, network has some untested and undocumented parts. I did a release that did not really change anything to the "official" API.

I already reversed the checks that @henhuy mentioned in dev branch of solph: https://github.com/oemof/oemof-solph/commit/559c6811d33c5f34d0363071539742b37686153e. Probably, a release makes sense as well.

[p-snft]

There now is oemof.solph 0.5.2.dev0 that should fix the issue.