15 Replies Latest reply on Jan 26, 2018 8:43 AM by Roger Palmen

    Why does AF assign a UOM that i don't want?

    Roger Palmen

      Hunting down an issue i found that when i subtract two temperatures using UOM "degrees C" in AF Analytics (AF2017SP2), the output receives the UOM "Delta degrees C". But i need degrees, not a delta as now my output is not written anymore due to mismatch in UOM.


      I don't want that. I never asked for it and it's wrong! And there are no functions in AF to get rid of an UOM, at least i have not found a way yet.

        • Re: Why does AF assign a UOM that i don't want?
          Roger Palmen

          Found a statement that seems to relate in the 2017SP2 release notes:



          A new property, DeltaUOM, has been added to the UOM object to allow applications to determine the appropriate unit for measuring the differences between two values.  For example, temperature units typically have a different unit to represent deltas because of the offset present in the conversion factors.


          I think that this is in general a good idea, but it still goes to far to then for analytics automatically switch the UOM... at least not without the means to reverse that! If AF can switch from UOM Temperature to Delta Temperature, the Convert function should allow the same at least...

          AND on top of that, this property is not exposed in PSE so the only way to break the magical bond between degrees and delta degrees is to remove the delta UOM class?

          • Re: Why does AF assign a UOM that i don't want?
            Gerhard Polenz

            The Convert function allows to assign a UOM to the result of an expression. Have you attempted to address the problem by using that function to force a particular UOM to the result of your expression ?

            • Re: Why does AF assign a UOM that i don't want?
              Roger Palmen

              Contact with techsupport learned that a workitem to remediate the unintended consequences is being considered. Fo the time being, a slightly nicer workaround was presented to use a multiplication with 1 to get rid of the UOM.


              Let me repost the feedback i got from Wojciech Pribula:


              So far I would like to offer one workaround which may be easier than your workarounds.


              Multiplying by 1 you will remove UOM from the number and then you can convert it to any of units or just write to an attribute with units.

              • Re: Why does AF assign a UOM that i don't want?
                Rick Davin

                Hi Roger,


                Chiming in late, but it is well known that Analytics is not very UOM-aware.  That is to say we do not yet have Dimensional Analytics.  Current implementation is quite limited; in fact the only time UOM's are supported if you perform an operation on 2 values with the same UOM.  But if those 2 values have different UOM's, but belong to the same UOMClass, the UOM is lost.  Consider this example:


                2018-01-22 09_01_01-__DESKTOP-L6P2PBN_Analytics Tests - PI System Explorer (Administrator).png


                Sum1 lacks a UOM.  Doesn't matter if that should be 10 mi or 10 km because either answer is wrong.  It should not be 10 anything.


                But the example shows 2 things:

                1. Adding (operating upon) 2 values with different UOM's returns a value without a UOM
                2. Adding (operating upon) 2 values with the same UOM returns a value with a UOM.


                In general, the resultant UOM is the same as the inputs.  But there is a special exception for Temperature.  Back in 2009, I bristled at the Delta Temperature class.  After my initial reaction, I accepted that it makes sense from an engineering perspective.  I began to accept the Delta Temp class by relating to a well-established analogy: DateTime and TimeSpan.  After all, a DateTime minus another DateTime does not produce another DateTime; rather it produces a TimeSpan.  Likewise, I can add or subtract a TimeSpan with a DateTime to produce another DateTime.


                With that said, what I feel is wrong about your example is that most likely your Temp1 should not be °C but rather should be delta °C.  Then by subtracting Temp1 from Temp2, you would output the correct UOM of °C.

                  • Re: Why does AF assign a UOM that i don't want?
                    Roger Palmen



                    I really appreciate your in-depth response. But then i can't really make the step to accept this from my (electrical) engineering perspective. In engineering analogies are king, so when this applies to temperature, why not to every other UOM class?


                    My mind just keeps refusing to accept this and comes up with all kinds of reasons:

                    • While you rightly state that you can't calculate easily with km and mi, i disagree. You can perform the calculation in the canonical UOM, and then the user can cast this back to the desired UOM, or just keep it canonical.
                    • You could do exactly the same with length. Why not have a delta distance when subtracting two lengths? Same reasoning could apply
                    • DateTime and Timespan are different beasts. Not all timespans are created equal when you add the timestamp to the mix. Timezones, DST, calendars, leap seconds and the likes explain that there is not an easy answer to resolve the time difference between two timestamps. That is why a timestamp is something used to mark a spot on the time line, while time is a base unit found in the Metric system. So where a timespan is a construction to determine the amount of time between two timestamps, this is NOT an operation that can be compared to subtracting two lengths or two temperatures. That analogy won't hold up. You are probably quite well aware of the limitations of time arithmetic in PI (and everywhere for that matter), while within the metric system eveything holds op very well.


                    But i think we're stuck with the deltaT, we just need to find a graceful way to deal with it. And i hope this thread raises some awareness about this particular behaviour.


                    And did some testing, yes, doing arithmetic with DeltaT does indeed work and produces a Temperature again.

                      • Re: Why does AF assign a UOM that i don't want?
                        Rick Davin

                        Hi Roger,


                        There is absolutely no need for a Delta Length class.  The UOM's there are defined by established definitions by physics, engineering, and mathematics.


                        Length - Length = Length

                        If you travel 5 miles due east and then travel 2 miles due west, how far away are you from where you first started?  The answer is 3 miles, not 3 delta miles.


                        Length + Length = Length

                        If you travel 5 miles due east, rest, and then travel another 2 miles due east, how far away are you from where you first started.  Answer: 7 miles, not 7 delta miles.


                        Length * Length = Area

                        This operation results in a UOM from a different UOMClass.  If you walk 5 miles due east and then 5 miles due north, what's the area defined?  25 square miles.


                        Length / Length = unitless (or Percent)

                        This operation could result in a null UOM, but one could also argue it could be Percent from the Ratio class.


                        A lifetime ago I tutored college kids in math.  I remember explaining to them that given a long equation that it's important that the operations be applied to the units as well as the quantities.

                        Sometimes we take the shortcut but forget the work involved.  Here's a quick example.  Let's define "day" as a standard 24 hour day.  How many seconds are there in a day?


                        60 X 60 X 24 = 86400


                        But really you must not forget the units and apply the operations to them.  Luckily most of them cancel out:


                        60 seconds/minute  X  60 minutes/hour  X  24 hours/day = 86400 seconds/day


                        Yet we do have units remaining and we can't simply ignore them.  They are an integral part of the math.


                        Now let's turn to some basic truths that we teach kids in primary school.  The freezing point of water is defined as 0 °C or 32 °F.  The boiling point of water is defined as 100 °C or 212 °F.  I don't expect you to argue over the fact that 0 °C = 32 °F.  Let's see why we need a Delta Temperature class by setting Temp1 equal to Temp2 and finding the difference:


                        100 °C - 100 °C  =  212 °F - 212 °F


                        If we don't use a Delta Temperature class, we immediately get this contradiction:


                        0 °C  =  0 °F    (caution: the universe may explode)


                        Again, the math must work for units as well as quantities.  This can only be rectified by understanding the need for a special delta temp class


                        0 delta °C  =  0 delta °F   


                        When subtracting 2 temperatures and the difference is 0, that 0 difference should be 0 regardless of temperature scale and not be 0 in Celsius but magically become more than 0 (32 specifically) in Fahrenheit.

                        1 of 1 people found this helpful
                          • Re: Why does AF assign a UOM that i don't want?
                            Roger Palmen

                            Good writeup, and i really understand your point. But i think one key thing is missed here: this is only caused by the fact that fahrenheit and Celcius are not to be compared 1:1. Fahrenheit is not a metric unit and thus a special conversion must take place.

                            • The definition: Celcius = (Fahrenheit - 32) * (5/9)
                            • So 100 °C - 100 °C  =  212 °F - 212 °F
                            • should be written as 100 °C - 100 °C  =  (212 °F - 212 °F) - 32 * 5/9
                            • And that is still 0 = -32 * 5/9 = -17.78  which makes this equation still false

                            At least we are currently (speaking AF2017R2) in a situation that AF says "True" to the equation: 0 °C  =  0 °F (and my AF server did not explode). So in any case where we are at is not where we should be.



                            Now on to the delta. While 0 Delta °C  =  0 Delta °F (and AF agrees on that), this is not true for anything else than 0. A 9 degree increase if Fahrenheit is only a 5 degree increase in Celcius, so 5 Delta °C  =  9 Delta °F. Not saying that Wikipedia is always true, but this is the definition of the delta: "A temperature interval of 1 °F is equal to an interval of 59 degrees Celsius". source: Fahrenheit - Wikipedia

                            But here AF does not agree: 5 Delta °C  =  9 Delta °F resolves to false, while 5 Delta °C  =  5 Delta °F resolves to true, while this is not the same difference in temperature. When doing calculations using the Delta and Temperature classes, the results are only correct when they are in the same UOM. My idea is that a delta is either linked to the specific unit, or completely unitless and thus only the mathematical difference. The delta class does nothing to solve the complexities when dealing with UOMs


                            So in my point of view, the delta class is unnecessary and badly implemented.



                            PS: The day example is simplfied by getting rid of all the complexities of times and durations defined in anything else than a second, the base unit. Not all minutes have 60 seconds, not all days have 24 hours. For a lot of cases this simplified concept of time is detailed enough, but that is something different than mathematically correct.


                            PS2: Just read on wikipedia that Fahrenheit was a Dutchman... My ancestors are partly to blame

                          • Re: Why does AF assign a UOM that i don't want?
                            David Pugal

                            Hi Roger,


                            Thank you for the discussion and the end-user perspective. It is true that handling the units in Expression and EF analyses is far from perfect for now. However, the reason for those minor enhancements was to allow propagating units for non-ambiguous cases (e.g. in 1[] + 2[km] it is natural to assume that the unit is [km], whereas in 1[] + 2[km] + 3[mi], the unit for the first operand cannot be implied, therefore the units will be discarded) to reduce the excessive use of Convert function.


                            Roger Palmen wrote:


                            • While you rightly state that you can't calculate easily with km and mi, i disagree. You can perform the calculation in the canonical UOM, and then the user can cast this back to the desired UOM, or just keep it canonical.

                            We actually solved this problem for Rollup. For example, it can have a mix of miles and kilometers for inputs and if an output attribute has a UOM from the same class the canonical UOM will be used in the calculation. We're still thinking how and to what extent can we support the same logic for Expression and EF analyses. The challenge is that a single expression does not necessarily translate into an output, but can be also used as an intermediate variable in subsequent expressions. In those cases, we want to avoid breaking existing calculations by changing the numeric evaluation result of that expression due to the unit conversion.

                              • Re: Why does AF assign a UOM that i don't want?
                                Roger Palmen

                                Hi David,

                                Thanks for chiming in!


                                I understand the challenge, and i generally like the way the formula DR works. If you don't specify anything different, the output is assumed to have the UOM of the attribute. Because it is either tricky to determine the output UOM of an expression, or the business rules are not intuitive for all users.


                                So my idea would be like:

                                For each analysis expression you should also be able to specify the output UOM (without using the convert), and then it is up to the user to create an expression that produces the output in the UOM stated.

                                And by default you could set the output UOM of an expression to the current logic. That keeps the simplicity for the expressions that are not too complex, but allows for full user control when UOM really comes into play.


                                This feedback item: Define UOMs for outputs – Customer Feedback for OSIsoft & the PI System  tried to address that, but might have missed sufficient detail.

                                This KB article shows this is a problem, but the KB is a bit limited to just one expression, while we must also do this for every expression, even if not mapped to an output.