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

Feature/planning/schedule sensor with different units #1128

Conversation

victorgarcia98
Copy link
Contributor

@victorgarcia98 victorgarcia98 commented Jul 24, 2024

Description

This PR opens the door for scheduling in any power units, for example, in kW. Two changes were introduced for this purpose:

  1. Transform the output of the solver from MW to the units of the power sensor.
  2. Support defining the soc-min, soc-max and soc-at-start in arbitrary energy units.

Pending tasks

  • Add examples to the documentation
  • Add a changelog entry

Related Items

Closes #386


  • I agree to contribute to the project under Apache 2 License.
  • To the best of my knowledge, the proposed patch is not based on code under GPL or other license that is incompatible with FlexMeasures

Signed-off-by: Victor Garcia Reolid <victor@seita.nl>
…ower sensor.

Signed-off-by: Victor Garcia Reolid <victor@seita.nl>
… and soc-min, soc-max and soc-at-start in kWh and MWh.

Signed-off-by: Victor Garcia Reolid <victor@seita.nl>
@victorgarcia98 victorgarcia98 self-assigned this Jul 24, 2024
@victorgarcia98 victorgarcia98 marked this pull request as ready for review July 24, 2024 15:30
Copy link
Contributor

@Flix6x Flix6x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My preliminary advice would be to keep/adapt your tests, but to use my revisions of the QuantityField in #1127 as a basis for the desired feature we both worked on. Up for discussion, of course.

data_key="soc-min",
default_src_unit="MWh",
to_unit="MWh",
validate=validate.Range(min=0),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The validator is used on the deserialized value, which I believe would fail in case a string quantity definition has been deserialized to a quantity object, and is then compared to zero.

Comment on lines +295 to +297
NB any validators passed are only applied to Quantities.
For example, validate=validate.Range(min=0) will raise a ValidationError in case of negative quantities,
but will let pass any sensor that has recorded negative values.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy pasted without being adapted.

super().__init__(*args, **kwargs)
if _validate is not None:
# Insert validation into self.validators so that multiple errors can be stored.
validator = RepurposeValidatorToIgnoreSensors(_validate)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which sensors?!

@Flix6x
Copy link
Contributor

Flix6x commented Jul 25, 2024

Transform the output of the solver from MW to the units of the power sensor.

Actually, my PR doesn't address this, so this is something extra worth cherry-picking from your PR.

@victorgarcia98
Copy link
Contributor Author

victorgarcia98 commented Jul 30, 2024

After including the missing pieces from this PR to #1127, we can close this PR and finalize the work on PR #1127 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Scheduling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Schedule non-MW sensors
3 participants