Documentation - IEC tag usage and reference
Opened this issue · 4 comments
I think in the documentation we should refer explicitly to the IEC tags and where to find them. As when editing the inputs to allow the Cubico data to run on the SYE analysis, I wasn't sure what I should be labelling the nacelle position as.
A follow up...
I would have expected when I create a yaml file all mappings would be used, not just the ones that have been defined specifically in OpenOA. Why I'm thinking this is important is because if I have some variables mapped to the IEC tags using the yaml, but have to do the others manually, I'll have to do the job twice, or otherwise have some variables mapped and others not.
A work around is to add these two lines, but its not clean, and I'm not sure including the full IEC tag list is best either, but would force consistency.
Any thoughts on what we can do?
mappings = yaml.safe_load(Path("data/kelmarsh/plant_meta.yml").read_text())
project.scada = project.scada.rename(columns=dict((v, k) for k, v in mappings["scada"].items()))
Thanks for flagging this, @charlie9578! The main issue here is that the remapping of columns is done through the metadata classes col_map
and col_map_reversed
like in SCADAMetaData
. Essentially to avoid confusion with other variables present we defined the col_map
that will be used to determine which columns to check and transform.
However, this does raise a good case where there should be the ability to define further columns for checking and converting. I don't think we'll have a fix for this in the near term, but you will want to ensure you're skipping the fields: name
, frequency
, dtypes
, units
, col_map
, and col_map_reversed
in your renaming (can't remember if it'll fail with nonexistent keys).
For now, I'd recommend using a custom version that expands the metadata classes you're using if you're aiming to avoid the extra read and map steps.
Thanks Rob. For now I've done the IEC mappings within the Cubico project setup, which does mean mappings are lost in the PlantData, but seemed easier for now. Once I've settled on the signals I'll add them to the SCADAMetaData.
Glad you were able to get this working on your end, and I'll keep this open until we implement a long-term solution to use cases like this.