This help page provides additional discussion and guidance relative to two particular scenarios, calculations involving:
Temperature and temperature-related Units.
Frequency, both frequency with Units of Hz (or similar), or 1/s (or similar), as well as angular frequency with Units of rad/s (or similar).
Calculations with either of these types of quantities can be a bit tricky relative to Units. For temperature calculations involving Celsius or Fahrenheit, the issue of affine or non-affine conversion is present. For calculations involving frequency and angular frequency, the issue of a 2*pi factor is present. Kornucopia offers methodology for both types of issues so that you can use clear equations and calculations.
The two sections below are:
Please note that there are links to tutorial examples at the end of each section to further explore and understand the given topic.
If you stick with temperature Units of kelvin and/or rankine, both of which are absolute temperature Units, then everything is clean and easy. This is because these forms of temperature Units obey all the laws of multiplicative Units, including raising them to arbitrary powers (such as T^4 where T is a temperature in the Units of kelvin or rankine). The problem/complexity occurs when you utilize Units of Celsius and Fahrenheit because these temperature Units are potentially affine.
In the real word, nearly all disciplines (engineers, scientists, etc) commonly use Celsius or Fahrenheit at either the beginning or end (output) of their calculations. One exception are Physicists; they tend to commonly use kelvin throughout their entire calculations (and they should be applauded for this!). The unfortunate use of Celsius or Fahrenheit in many approaches often leads to mistakes caused by incorrect manual Units conversions, or very bad practices like curve-fitting a response as a function of temperature in Units like Celsius and then reporting some second-order polynomial results as a function of Celsius temperature. If you want to do such a curve fit, it should be done with absolute temperature Units such as kelvin or rankine. Kornucopia's features are designed to allow you to easily work with Units of Celsius and Fahrenheit while at the same time it attempts to prevent you from doing bad things like the polynomial curve fit described above, or like trying to use a Celsius temperature directly in a radiation problem, where temperature is raised to the 4th power.
This section of help describes how Kornucopia provides robust methods and features to help you work confidently with temperature and related Units. One particular area of importance is the issue of affine and non-affine conversions when working with Celsius or Fahrenheit temperatures.
When a temperature defined in terms of Celsius or Fahrenheit is NOT representing a change in temperature (so called delta temperature), the relationship between Celsius and Fahrenheit is defined by the equation of a line (meaning a multiplication factor plus an offset). The same is true between either of these temperature Units and either of the absolute temperature Units of kelvin or rankine. This affine case must be handled with special care as it does not obey the typical multiplicative Units conversion rules. Kornucopia has internal tracking logic to help you with this.
When a temperature defined in terms of Celsius or Fahrenheit IS representing a change in temperature (so called delta temperature), the relationship between Celsius and Fahrenheit is defined by only a multiplicative conversion factor (just like all other units such as m, in, N, lbf, etc.). The same is true between either of these temperature Units and either of the absolute temperature Units of kelvin or rankine. This non-affine case is handled with the typical multiplicative Units conversion rules. Kornucopia has internal tracking logic to help here also.
Consider the scenario below:
Given: T1 = 100*degC.
What is T1 in terms of K (kelvin) and also what is T1 in terms of degF (Fahrenheit)?
The answer to this simple question is not obvious because we do not know if T1 is representing a change in temperature (so called delta temperature) or not.
If T1 represents a change in temperature, then the Kornucopia calculations and answers are:
T1.convert('K',
'affine', 'off')
ans = 100*K
T1.convert('degF', 'affine', 'off')
ans = 180*degF
If T1 does NOT represents a change in temperature, then the Kornucopia calculations and answers are:
T1.convert('K',
'affine', 'on')
ans = 373.15*K
T1.convert('degF', 'affine', 'on')
ans = 212*degF
As shown above, the solution to the ambiguity of the potentially affine nature of Celsius and Fahrenheit Units is solved by using the optional ADV argument 'affine' with the the k_units data type method convert. This approach also works with the function k_unitsConvert.
A few important notes:
If you attempt to perform a Unit's conversion starting with or converting to a Unit of Celsius or Fahrenheit and you do not specify the ADV setting of 'affine', then in nearly all cases an appropriate error message will be returned instructing you to add this to your command. The only exception to this is converting between the same Unit, say °C to degC, for which no affine ADV is needed (if one is applied, it is ignored).
Kornucopia performs extra internal tracking of temperature Units to robustly handle potentially affine nature of Celsius and Fahrenheit. Because of this, you will always see an absolute temperature (K or R), as well as both degC and degF Units in all Units Preferences.
Tutorial: Working with Temperature - This is the best way to understand how to compute with various temperature Units and to smoothly convert/work with both Celsius and Fahrenheit, as well as kelvin and rankine Units.
Kornucopia has unique features and internal logic to help handle calculations involving units of frequency such as Hz, kHz, MHz, etc. as well 1/s (or similar) and angular frequency with units of rad/s, 1/s, rpm, or similar.
Warning: Despite the features that will be discussed momentarily, there are still potential scenarios where you can produce incorrect or undesirable results due to the difficulty of detecting the difference between frequency and angular frequency. This is due to what we call the Hz, 1/s and rad/s Conundrum. This conundrum is explained below. That is then followed by a discussion of how Kornucopia attempts to deal with it. Please review the discussion below and then explore the tutorial link provided at the end of this section.
This conundrum is set up by these commonly accepted statements:
The SI definition of hertz is Hz = 1/s (ref: The NIST Reference on Constants, Units and Uncertainty, physics.nist.gov/cuu/Units/units.html)
The definition of hertz from Wikipedia (en.wikipedia.org/wiki/Hertz) is Hz = cycle per second.
Many engineers would consider a cycle to be one revolution where and one revolution = 2*pi*rad. Thus a cycle = 2*pi*rad.
A radian, unit rad, is a derived Unit for a plane angle, and expressed in terms of SI base units rad = m/m = 1 (ref: The NIST Reference on Constants, Units and Uncertainty, physics.nist.gov/cuu/Units/units.html).
Simply putting these statements together, one concludes:
Hz = 1/s = 2*pi*rad/s = 2*pi/s
Thus 1 = 2*pi. Obviously, that is not correct!
The conundrum lies in the interpretation of cycle and the difference between angular frequency and frequency. The conversion between a frequency, f, measured in Hz and an angular frequency, w, measured in rad/s, is
w = 2*pi*f
The problem caused by this conundrum is that the value of 2*pi is dimensionless and a radian is equal to 1, making it difficult for general purpose software to track with normal unit-tracking techniques the difference between variables holding frequency, those holding angular frequency, and those simply holding a rate of a dimensionless quantity with rate units of 1/s, or rad/s where in this latter case, it could just be an angular speed where nothing is oscillating. It is further noted that relying on the name of a variable, f or w (or omega), is not at all a reliable nor viable approach for real-world problems addressed by general purpose software.
Kornucopia's solution to this conundrum lies in its additional units tracking related to angles and frequency. This additional tracking allows Kornucopia to automatically convert, in many cases, between Units of frequency (containing some form of a hertz Unit such as Hz, kHz, MHz, etc.) and Units like rad/s, 1/s, etc. Thus, the software often knows when to include (or exclude) the 2*pi factor whenever a conversion involves a Unit of hertz. However, if the calculation only has rad/s and 1/s like quantities, it is not possible for the software to know if either of these entities are intended to represent angular frequency or frequency, and thus it does not know if a 2*pi factor should be included in conversion calculations or not. Additionally, there are other cases with multiplication and division where using a combination of hertz and angle per time Units can result in an unclear Units transform. These multiplication and division cases will often lead to a warning issued by Kornucopia related to the unclear nature of the Units calculation.
Kornucopia's Units Engine is able to automatically do the following, but also has the following limitations as noted.
Robust capability: Convert from an entity with some form of hertz Unit (Hz, kHz, MHz, GHz, or THz) to an entity Units with some form of 1/time (such as 1/s, 1/ms, 1/min, 1/hr) and visa versa. This also means that multiplying or dividing quantities with units of hertz by quantities with units of time works properly.
Robust capability: Convert from an entity with some form of hertz Unit (Hz, kHz, MHz, GHz, or THz) and Units with some form of angle/time (such as rad/s, rad/ms, etc. or rev/min, rev/sec, etc. or even deg/s, deg/min, etc.) and visa versa. However, multiplying or dividing an entity with some form of hertz Unit by some form of angle/time Unit will generally lead to a warning about an unclear Units calculation that may now be incorrect.
Limitations:
When no form of a hertz Unit is present in a calculation, but you do have angle per time Units (or similar), Kornucopia cannot uniquely identify if the angle/time Units are intended to imply an angular frequency or not. There are cases where it is, but other cases where it is not. As such, if you have angle/time and you request to convert to 1/time (or visa versa), Kornucopia will NOT attempt to apply any 2*pi factors during the conversion. It will simply convert the angular Unit to rad and then view rad as unity during the conversion. No warning is issued in these cases because there are several scenarios, not related to angular frequency, where this is the intended result. Bottom line, it is up to YOU the user to be careful when doing this type of calculation.
The proper units conversion process can become unclear if you attempt to multiply or divide Units with hertz relative to Units with angle per time. Because this is a much less occurring scenario, Kornucopia will attempt to detect such cases and issue a warning as the resulting calculation may be inaccurate; it is simply impossible for the software to know your intent as it is not psychic! In some cases, the resulting calculation will indeed be wrong, but in other cases it could be correct. It is simply the natural of this type of problem. The examples presented in the tutorial described at the end of this help page show both types of cases.
The General Kornucopia Rules For Frequency and Angular Frequency
When some form of hertz Unit is involved in a conversion, Kornucopia interprets frequency as expected and it knows how to apply any needed 2*pi constants to convert to and from entities involving units of angle/time or just 1/time, or similar.
When you only have angle/time and/or 1/time and no hertz involved, Kornucopia makes no assumptions related to frequency nor automatic applications of 2*pi factors. You are responsible to apply or remove any 2*pi factors as needed. There are NO warnings issued in these cases.
You should NOT perform calculations that multiply or divide Units with hertz AND Units with angle/time. The tracking of any 2*pi factors becomes unclear and Kornucopia will typically issue a warning about a potentially incorrect calculation.
Tip: You should try to stick with either calculations based on frequency (preferred) or angular frequency. You should try to avoid doing calculations that are constantly mixing frequency and angular frequency variables together.
Tutorial: Working with Frequency and Angles. Exploring this tutorial is the best way to get comfortable with the topic of Units involving hertz, angle/time, 1/time, and angles.