Skip to content

Conversation

@ela-kotulska-frequenz
Copy link
Contributor

No description provided.

@ela-kotulska-frequenz ela-kotulska-frequenz added the type:enhancement New feature or enhancement visitble to users label Oct 14, 2024
@ela-kotulska-frequenz ela-kotulska-frequenz self-assigned this Oct 14, 2024
@ela-kotulska-frequenz ela-kotulska-frequenz requested a review from a team as a code owner October 14, 2024 05:57
@github-actions github-actions bot added part:docs Affects the documentation part:tests Affects the unit, integration and performance (benchmarks) tests part:code Affects the code in general labels Oct 14, 2024
@ela-kotulska-frequenz
Copy link
Contributor Author

@llucax
Pylint is falling with error:
tests/test_quantities.py:1:0: C0302: Too many lines in module (1092/1000) (too-many-lines)
I can either:

  1. ignore this error : pylint disable too-many-lines
  2. separate tests into: test_quantities_base, test_power, test_frequency itd... This also means separating methods like test_zero - which checks if all quantities zero() method.

I think 1) is ok, because the tests seems descriptive and readable now, and I don't see reason to repeat the same function definitions in every file.

What do you prefer?

@llucax
Copy link
Contributor

llucax commented Oct 14, 2024

Ideally I would prefer, now what each quantity lives in its own file, to have one test file per quantity, but I think it was very difficult to split the test as it is structured now. I don't think it is worth investing a lot of time on this, at least for now, so based on how complicated you see the split (maybe you could try to ask ChatGPT to do the split, for these types of things I think it can be pretty effective) or just add an ignore.

Copy link
Contributor

@llucax llucax left a comment

Choose a reason for hiding this comment

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

I'm assuming the code is mostly a copy&paste from Power, so not reviewing much in details. I think things get complicated with multiplication and division. From a quick search I find mentions of VAh and VARh as the units for energy coming from apparent and reactive power respectively. I'm not sure if we should introduce also ApparentEnergy and ReactiveEnergy 😬

Maybe @tiyash-basu-frequenz @matthias-wende-frequenz or @cwasicki know better?


## Summary

This is the initial release, extracted from the [SDK v1.0.0rc601](https://github.com/frequenz-floss/frequenz-sdk-python/releases/tag/v1.0.0-rc601).
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here, I wouldn't remove this until 1.0 final.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@cwasicki
Copy link

I'm not sure if we should introduce also ApparentEnergy and ReactiveEnergy

At least atm I am not aware of a use-case for this.

@llucax
Copy link
Contributor

llucax commented Oct 14, 2024

At least atm I am not aware of a use-case for this.

You mean you won't need to get energy from reactive or apparent power? If we don't have uses cases for this and we are not sure what to return when multiplying by time, I would not implement the multiplication by time for these 2 new units for now, we can add them later when we have more clarity, as adding will be a non-breaking change but removing or changing will.

@cwasicki
Copy link

Just saying that I don't know of an app which is using this currently, so adding it later sounds reasonable to me.

@ela-kotulska-frequenz
Copy link
Contributor Author

ela-kotulska-frequenz commented Oct 15, 2024

  • We need reactive power for the new formula GridReactivePowerFormula
  • The problem with current quantity Power is that it will print 100W instead of 100VAR. The same for ApparentPower : it will print 100W instead 100VA. It is misleading.

@ela-kotulska-frequenz ela-kotulska-frequenz marked this pull request as draft October 15, 2024 13:17
Signed-off-by: Elzbieta Kotulska <[email protected]>
Signed-off-by: Elzbieta Kotulska <[email protected]>
Signed-off-by: Elzbieta Kotulska <[email protected]>
This file looks like for now.
If number of quantities increase then we should consider
separating this file into many quantities.

Signed-off-by: Elzbieta Kotulska <[email protected]>
If necessary, they can be added later.

Signed-off-by: Elzbieta Kotulska <[email protected]>
@ela-kotulska-frequenz ela-kotulska-frequenz added this pull request to the merge queue Oct 16, 2024
Merged via the queue into frequenz-floss:v1.x.x with commit d0f9a28 Oct 16, 2024
14 checks passed
@llucax
Copy link
Contributor

llucax commented Oct 17, 2024

@shsms @ela-kotulska-frequenz do we really need to use __mul__ with timedelta now for these new quantities? Otherwise I strongly suggest removing those. We introduced an asymmetry with this: REACTIVE POWER * TIME / TIME = POWER (not reactive).

I think this is not good, and if we really need this we should think about it more. Let's discuss before a release with these new quantities.

@ela-kotulska-frequenz
Copy link
Contributor Author

ela-kotulska-frequenz commented Oct 17, 2024

@llucax __mul__ with timedelta has been removed. We don't use it in new quantities.

Please look at last commit in this PR, "Remove the Energy interactions for ReactivePower and ApparentPower"

@Marenz
Copy link
Contributor

Marenz commented Oct 17, 2024

I am not sure if it s out of scope for this PR/repo, but an explanation or at least a link to what Reactive/Apparent power is in the first place would be nice, no?

@ela-kotulska-frequenz
Copy link
Contributor Author

ela-kotulska-frequenz commented Oct 17, 2024

@Marenz
The definitions of Reactive and Apparent power are well defined physical quantities.
I don't think we need definitions in code, as we also don't need them for other quantities here like: Frequency or Current or Power.

But if I am wrong, I can write something in follow up PR

@Marenz
Copy link
Contributor

Marenz commented Oct 17, 2024

Maybe they are well defined, but isn't our target audience not a non-hard-core programmer than can do python stuff and supposedly doesn't have and education in physics? (I never heard of those quantities before I started here for example and actually still don't know what they are).
Or why they justify a whole own unit, each..

If we expect our target audience to know this, then of course I withdraw my point :)

@tiyash-basu-frequenz
Copy link

Documenting active/reactive power is a good thought, but it open up further issues, I feed. Then we need to document every other electrical metric, and we need to document them every time they are used or mentioned.

Maybe it is better to look into adding the definition of these terms to our glossary (in a separate issue).

but isn't our target audience not a non-hard-core programmer than can do python stuff and supposedly doesn't have and education in physics?

I thought the audience was just novice-programmer. Non-physics-educated sounds new to me. I would have thought that the audience needs to have some knowledge of electricity-related physics, otherwise they would anyway have zero idea of what to do here.

@Marenz
Copy link
Contributor

Marenz commented Oct 17, 2024

I mean, I was able to string a long pretty far without knowing those two things :P
The other stuff (Currency, Power, Frequency) is a lot more common imo, not sure how many people even heard of apparent/reactive power

@llucax
Copy link
Contributor

llucax commented Oct 18, 2024

@llucax __mul__ with timedelta has been removed. We don't use it in new quantities.

Please look at last commit in this PR, "Remove the Energy interactions for ReactivePower and ApparentPower"

Ah, great, sorry for the noise, I must have been looking at an old state of the PR.

@llucax
Copy link
Contributor

llucax commented Oct 18, 2024

About documenting what each quantity is, I think a link to Wikipedia should be enough, no? Very low effort and useful enough for the people that don't know and want to learn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

part:code Affects the code in general part:docs Affects the documentation part:tests Affects the unit, integration and performance (benchmarks) tests type:enhancement New feature or enhancement visitble to users

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants