Voltage Modifications

[rjs5327]

I am not a fan of how we have ElecticalPotential, ElecticalPotentialAC, ElecticalPotentialDC

This creates a issue, i see where it may be good to lock the voltage to a Frequency of 0, like if you were doing a calculation that was only good for AC this would prevent the DC voltage to be applied. However take V=IR it doesnt matter if there is AC or DC. If you define a item as ElecticalPotentialAC then the calculation would be locked to only AC or DC. I think we should be looking at this type of unit as a interface or inherited class. Inheritance is really what we want since the conversions are the same just there is a ability to prevent usage if you use the child class opposed to the parent class.

That being said more functions can be created. But i think just change

public readonly partial struct ElectricPotentialAc :
    IArithmeticQuantity<ElectricPotentialAc, ElectricPotentialAcUnit, double>,
    IComparable,
    IComparable<ElectricPotentialAc>,
    IConvertible,
    IEquatable<ElectricPotentialAc>,
    IFormattable

to

public readonly partial struct ElectricPotentialAc : ElectricPotential

I am not versed well enough on the backend of this code to know why that was decided. Only thing i can see is the custom code section *.extra.cs items.

I am in process of using the Electrical Potential in a Project and this is a sticking point for me. At the moment i am defining everything as Potential without the AC/DC designator. I start the conversation since i think the idea is great to separate them but i think implementation needs to be different.

Another Note:
With AC power there almost needs to be a Frequency value that goes with it. Since if you are dealing with 50 vs 60Hz that can cause a issue or some custom frequency. Since that is a part of compatibility in AC potential. I dont have a idea on that at moment, but that is how i am dealing with it in my project by defining frequency and voltage. Then using frequency as a comparison to evaluate compatibility with voltage potential.

For me this is not a hold up i worked around it but wanted to start a thread on it to discuss. Since i dont really see the point in the differentiation if the above is not addressed.

Thoughts?

[lipchev]

public readonly partial struct ElectricPotentialAc : ElectricPotential

Unfortunately what you're suggesting (extending a base class) isn't possible with the struct types.

With AC power there almost needs to be a Frequency value

I'm not sure if that fits with the IQuantity definition, which is restricted to the {Value, Unit} tuple, with everything from constructions, conversion, parsing, serialization etc. all assuming that no other information is required.

There is already a similar case in the ReferencePressure but I personally feel like (although I'm by no means an expert in the field) that such extensions / wrappers should be left to the end-users to implement (unless there is a strong consensus on the usability of the "wrapper/helper").

Not sure if that would work for you, but I expect that in v6 you should be able to use the UnitConverter to define a conversion between the two electric potentials (AC/DC), which should allow you to easily switch from one to the other, however I don't think that would work with an extra field.

[angularsen]

Related discussion with a conclusion here:
#1296 (comment)

I think the current support for electrical units in UnitsNet needs improvement, and either simplified (don't distinguish AC/DC) or taken further to be more feature complete and useful, but this sounds to me like a separate library that may or may not build on top of UnitsNet.

At any rate, to move this along, someone with a good understanding of the domain AND a real need to get this improved in UnitsNet needs to step up and do some pull requests. I'm happy to help make things fit into UnitsNet, but I don't have time to pursue this myself.

[McNeight]

The problem I ran into, simply put, is rapid scope creep.

For example, there is ElectricalCurrent class which is measured in Amperes. As a base unit of the standard units of measurement defined by the International System of Units (SI) for the seven base quantities of what is now known as the International System of Quantities: it is notably a basic set from which all other SI units can be derived.

All of that (copied and pasted from Wikipedia) to say that a unit like ElectricCurrent should be considered foundational to a library like UnitsNet, and generally shouldn't be tinkered with.

Then, along comes a practical distinction between alternating current (AC) and direct current (DC). The cost of the war fought over a century ago between Westinghouse/Tesla and Edison, with casualties measured in elephants, is that now we have to suffer with both. ElectricCurrentDC is a constant over time, making both measurement and mathematical representation fairly simple. ElectricCurrentAC, by definition, varies over time. Now there are not only multiple ways to measure how often that variation happens (either frequency such as UnitsNet.Frequency() or period such as System.TimeSpan()), but multiple ways to measure how much of that variation occurs (peak current, peak to peak current, root mean square (RMS), or instantaneous). This introduces various mathematical conversions between those measurements of variation (peak-to-peak ElectricCurrentAC = 2.828 x RMS ElectricCurrentAC; 0.707 peak ElectricCurrentAC = ElectricCurrentAC RMS).

Now where my brain started breaking was when, as part of the project I was working on, I attempted to include three-phase AC. In three-phase power, the voltage on each wire is 120 degrees phase shifted relative to each of the other wires. And my brain broke long before I got to the imaginary number measurements like reactance and complex numbers like impedance.

So let me sum up to this point. In order to fully describe an alternating current power source, you now have a C# ElectricCurrentAC class that needs to define:

• Current in Amperes
  • Method of measurement of current (peak, RMS, etc.)
  • DC offset (can't assume that a wave always oscillates around 0) in Amperes
• Frequency in Hertz / Period in seconds
• Quantity of Phases
  • One and three are most popular, but there is no law against two or twenty.
• Phase Angles in degrees / radians
  • Angle in reference to what? First to second phases? First to third phases? Second to twentieth phases?
• Waveform (could be a sine wave or a square wave or a sawtooth wave or...)

As well as have a way to mathematically interact with the following classes:

• ElectricImpedance, a complex number measured in ohms, comprised of:
  • ElectricResistance, the real component.
  • ElectricReactance, the imaginary component, consisting of:
    • Capacitive ElectricReactance, and
    • Inductive ElectricReactance
• ElectricAdmittance, a complex number measured in Siemens or mho (ohms spelled backwards), comprised of:
  • ElectricConductance, the real component.
  • ElectricSusceptance, the imaginary component, consisting of:
    • Capacitive ElectricSusceptance.
    • Inductive ElectricSusceptance.
• ElectricPotentialAC
  • With the same parameters as ElectricCurrentAC, as well as interactions with all of the above classes
• ElectricPowerAC, containing one ElectricCurrentAC variable, one ElectricPotentialAC variable, and the calculations for:
  • Active power, or real power, in watts (W)
  • Reactive power in volt-ampere reactive (var)
  • Complex power in volt-amperes (VA)
  • Apparent power, the absolute value of complex power, in volt-amperes (VA)
  • Phase of voltage relative to current, in degrees or radians

By the time you implement, test, bug fix, and deploy all of that, you have an electrical engineering library. And that's great, if you want to put that kind of time and effort into developing and maintaining an electrical engineering library. But UnitsNet is not an electrical engineering library, nor should it try to be.

I see the UnitsNet library as a C# tool to help prevent unit conversion accidents like the Gimli Glider or the Mars Climate Orbiter (OK, maybe not that important...). Maintaining descriptions of units of measure such as volts and amperes, and converting between those units of measure, should be about as deep as the UnitsNet library should go. Even implementing something as simple and universal as Ohm's Law (ElectricPotential * ElectricCurrent = Power) would mean that someone writing a program involving complex power might not get a correct answer directly from the library.

This is why I finally came up with the solution that I did. An individual developer can take the UnitsNet library and keep it simple with a named Tuple:

(ElectricPotential v, Frequency f) potentialAC = (ElectricPotential.FromVolts(120), Frequency.FromHertz(60));
Console.WriteLine($"Tuple with elements {potentialAC.v} and {potentialAC.f}.");

or make it as complicated as it's own class:

public static class ElectricPotentialAC(ElectricPotential voltage, MethodEnum Method.RMS, ElectricPotential offset, Frequency f, int phases, Angle[] phaseAngles, WaveformEnum Waveform.Sine)

@angularsen if you need help with marking the AC/DC functions as obsolete and simplifying things to just ElectricPotential and ElectricCurrent, then I'll try and make some time for it.

Thanks for coming to my TED Talk.

Edit: only now, hours later, do I notice that the formula I wrote down for Ohm's Law is, in fact, not Ohm's Law. If I were an electrical engineer, I would be ashamed of myself.

[angularsen]

Wow, intense read 😅 but thanks for a good writeup of the complexity involved.

Yes, I am convinced we should rip out all the AC parts for now, and if anyone ever wants to reattempt it they will be directed to read your post.

Yes please, if you could:

1. Create PR on release/v6 branch to make the breaking changes you propose
2. Create PR on master branch to obsolete things that will be removed/changed. You can mark quantities and units as obsolete via ObsoleteText field on either quantity or unit in JSON definitions and then regenerate code: https://github.com/search?q=repo%3Aangularsen%2FUnitsNet+obsoletetext+language%3AJSON&type=code&l=JSON

[rjs5327]

Agree completely.   The creep of this the of project is very easy to happen.  Also fully agree that the engineering library is a different project.  The issue becomes even more complex if you add mechanical to it tooSent from my iPhoneOn Dec 9, 2024, at 2:02 AM, Andreas Gullberg Larsen ***@***.***> wrote: Wow, intense read 😅 but thanks for a good writeup of the complexity involved. Yes, I am convinced we should rip out all the AC parts for now, and if anyone ever wants to reattempt it they will be directed to read your post. Yes please, if you could: Create PR on release/v6 branch to make the breaking changes you propose Create PR on master branch to obsolete things that will be removed/changed. You can marke quantities and units as obsolete via ObsoleteText field on either quantity or unit in JSON definitions: https://github.com/search?q=repo%3Aangularsen%2FUnitsNet+obsoletetext+language%3AJSON&type=code&l=JSON —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>