Closed FelixMau closed 8 months ago
Thanks for pointing this out!
You are right oemof.solph attributes which are not adressed in corresponding facade class can not be read automatically.
Instead, such attributes must be handled by extra_fields
in Adapter
(which is faster in terms of coding cycles than adding them to Facade
).
When adding them in StorageAdapter
like this:
class StorageAdapter(Adapter):
"""
StorageAdapter
"""
type = "storage"
facade = facades.Storage
extra_fields = (
Field(name="name", type=str),
Field(name="type", type=str),
Field(name="region", type=str),
Field(name="year", type=int),
Field(name="invest_relation_output_capacity", type=list),
)
variable is written to datapackage file.
Unfortunately, as I just saw, periodic values are neglected therby (only first value is taken). This has to be handled within another issue.I will close this one, as behaviour is as expected...
When building a datapackage from data that contains a
solph argument
the argument is getting lost. For illistrating the issue there is a data mock for storage with asolph argument
as well as the corresponding datapackage with missing argument. This issue occours because theget_fields
function uses dataclass.fields and the oemof.solph components are not dataclasesI think we could solve this two ways:
accept we are loosing these arguments and not allowing them (adding them to the facade if necessary)
Adding all found additional values without checking on the facade. This would require that those arguments would not get lost on creation of the energysystem from datapackage. @nailend could you confirm if solph arguments can be used in a datapackage in tabular? If not I can check on that.
[ ] Check if tabular
from_datapackage
reads insolph arguments
[ ] Decide what to do