Unit conversion error message for unitless attributes does not work for Angle conversions

[miltondean]

In Trick 17.4, I have an example of code that was generated with either (1) units or (--) units. Example: double attach_Units; // io (--) / double attach_Units1; // io (1) / double attach_Units2[5]; // io (--) / double attach_Units3[5]; // io (--) / When I try to use the trick.attach_units("feet",30.0), I get the following error message: ut_get_converter(): Units not convertible MemoryManager:ERROR:Can't convert "feet" to "1". ... Sim.Orion_1.Sys.State.attach_Units3[0] = trick.attach_units("feet",30.0) AttributeError: Units Conversion error in method swig_ref::setitem and trick terminates in IPPython.cpp:136 Which works as expected. Now if I use trick.attach_units("degree",30.0), I do not get any error message and the 30.0 is converted to radian value. I can also attach_units("arcminute",30.0) and it will also convert this value to radians. Python statements: Sim.Orion_1.Sys.State.attach_Units = trick.attach_units("degree",30.0) Sim.Orion_1.Sys.State.attach_Units1 = trick.attach_units("degree",30.0) Sim.Orion_1.Sys.State.attach_Units2[0] = trick.attach_units("degree",30.0) Sim.Orion_1.Sys.State.attach_Units2[1] = trick.attach_units("radian",30.0) Sim.Orion_1.Sys.State.attach_Units3[1] = trick.attach_units("arcminute",30.0) Trick_TV values: Sim.Orion_1.Sys.State.attach_Units 0.5235987755982988 -- Decimal Sim.Orion_1.Sys.State.attach_Units1 0.5235987755982988 1 Decimal Sim.Orion_1.Sys.State.attach_Units2[0] 0.5235987755982988 -- Decimal Sim.Orion_1.Sys.State.attach_Units2[1] 30.0 -- Decimal Sim.Orion_1.Sys.State.attach_Units2[2] 0.0 -- Decimal Sim.Orion_1.Sys.State.attach_Units2[3] 0.0 -- Decimal Sim.Orion_1.Sys.State.attach_Units2[4] 0.0 -- Decimal Sim.Orion_1.Sys.State.attach_Units3[0] 0.0 -- Decimal Sim.Orion_1.Sys.State.attach_Units3[1] 0.008726646259971648 -- Decimal Sim.Orion_1.Sys.State.attach_Units3[2] 0.0 -- Decimal Sim.Orion_1.Sys.State.attach_Units3[3] 0.0 -- Decimal Sim.Orion_1.Sys.State.attach_Units3[4] 0.0 -- Decimal

[dbankieris]

@alexlin0 I've confirmed this with a simple test case. I assume the problem is in units_attach.i, but that file is a mystery to me.

[dbankieris]

It turns out this behavior is correct because radians and degrees are dimensionless measures. See the first row of Table 3 and footnote b:

The radian and steradian are special names for the number one that may be used to convey information about the quantity concerned. In practice the symbols rad and sr are used where appropriate, but the symbol for the derived unit one is generally omitted in specifying the values of dimensionless quantities.

[miltondean]

If unit of (1) is also defined for radians, should trick be using (1) or something else like (--) as a default when trick smart comments are not defined/processed by ICG? Our issue occurred on the Trick13 to Trick17 upgrade. We had an attach_units(degree) value in python and the value it was updating had a smart comment defined as degree, but for some reason, Trick converted our degree value to radians. Upon further analysis, the class the attribute was defined in did not have the required trick header comments. In trick 13, that did not matter as trick still processed the smart comments from the header. In trick 17, that does not appear to be the case. Trick ignored the smart comments and instead assigned (1) to all of the attributes. I wrote https://github.com/nasa/trick/issues/808 to document this change.

Milton Dean All-Points Logistics LLC OrionSim Software Development milton.w.dean@lmco.commailto:milton.w.dean@lmco.com (281) 333 – 6070 (desk) (281) 235 – 5687 (cell)

From: dbankieris [mailto:notifications@github.com] Sent: Wednesday, June 12, 2019 9:50 AM To: nasa/trick trick@noreply.github.com Cc: Dean, Milton W (US N-ALL POINTS LOGISTICS) milton.w.dean@lmco.com; Author author@noreply.github.com Subject: EXTERNAL: Re: [nasa/trick] Unit conversion error message for unitless attributes does not work for Angle conversions (#807)

It turns out this behavior is correct because radians and degrees are dimensionless measures. See the first row of Table 3https://www.nist.gov/pml/special-publication-811/nist-guide-si-chapter-4-two-classes-si-units-and-si-prefixes and footnote b:

The radian and steradian are special names for the number one that may be used to convey information about the quantity concerned. In practice the symbols rad and sr are used where appropriate, but the symbol for the derived unit one is generally omitted in specifying the values of dimensionless quantities.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/nasa/trick/issues/807?email_source=notifications&email_token=AMIUPETTON7ROWA6FAY37ETP2EEJXA5CNFSM4HVSCQ22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXQV2NA#issuecomment-501308724, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMIUPEW3WHUOODORM2SBGDTP2EEJXANCNFSM4HVSCQ2Q.

[dbankieris]

Trick's unit conversion engine, udunits, does not support the concept of unitless quantities, which I think is what would be needed to prevent the unintended conversion you experienced. Every value has units, and when they aren't specified, they are assumed to be the dimensionless unit one. Unfortunately, that means you can assign all sorts of dimensionless units (degree, byte, ppm, grade, revolution) to variables lacking an explicit unit specification and get unexpected conversions.