Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation - IEC tag usage and reference #286

Open
charlie9578 opened this issue Mar 26, 2024 · 4 comments
Open

Documentation - IEC tag usage and reference #286

charlie9578 opened this issue Mar 26, 2024 · 4 comments
Labels
enhancement on hold Something that, for a variety of reasons, might not be addressed in the short term. plant-data Relating to PlantData, PlantMetaData, or their underlying components.

Comments

@charlie9578
Copy link
Contributor

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.

@charlie9578
Copy link
Contributor Author

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()))

YAML mappings
image

Partially mapped SCADA columns
image

@RHammond2
Copy link
Collaborator

RHammond2 commented Apr 5, 2024

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.

@RHammond2 RHammond2 added enhancement plant-data Relating to PlantData, PlantMetaData, or their underlying components. labels Apr 5, 2024
@charlie9578
Copy link
Contributor Author

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.

@RHammond2
Copy link
Collaborator

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.

@RHammond2 RHammond2 added the on hold Something that, for a variety of reasons, might not be addressed in the short term. label Apr 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement on hold Something that, for a variety of reasons, might not be addressed in the short term. plant-data Relating to PlantData, PlantMetaData, or their underlying components.
Projects
None yet
Development

No branches or pull requests

2 participants