Units with rational exponents

[henrikt-ma]

The Modelica syntax for unit strings doesn't support rational exponents, even though it seems well known that such units are encountered from time to time in established engineering practices. The specification needs to either give a good reason why rational exponents are not supported, or extend the syntax to allow them.

Extending the syntax wouldn't be hard. For example, a simple but maybe not the most elegant solution could be:

unit-exponent:
   [ "+" | "-" ] ( UNSIGNED-INTEGER | rational-exponent )

rational-exponent:
  "(" UNSIGNED-INTEGER "/" UNSIGNED-INTEGER ")"

[HansOlsson]

I know that fractional exponents sometimes seem to occur, but it is not clear that they are needed; so we would need some actual motivating examples. Especially for non-half exponents.

I can see three reasons against:

• The SI-standard don't include them and says that the numbers are normally small integers in 2.3.3 Dimension of Quantities, and when combining them in 5.4.6 it is not considered.
• The philosophical argument that we don't measure such quantities (that's why they normally occur for coefficients instead).
• Rational number checking adds more complexity.

[henrikt-ma]

I know that fractional exponents sometimes seem to occur, but it is not clear that they are needed; so we would need some actual motivating examples. Especially for non-half exponents.

It's not hard to find examples of domains where k/2 exponents are standard. If we accept that k/2 exponents are a thing, then I'm not sure we need to debate whether other denominators than 2 are important or not – artificially restricting to only allow 2 would be poor design anyway. Still, I'll ask around for more examples to help illustrating the issue.

I can see three reasons against:

• The SI-standard don't include them and says that the numbers are normally small integers in 2.3.3 Dimension of Quantities, and when combining them in 5.4.6 it is not considered.

But 5.4.6 doesn't say anything regarding integer exponents either, right?

• The philosophical argument that we don't measure such quantities (that's why they normally occur for coefficients instead).

Yes, this seems to be the main reason why people don't like fractional exponents. I just wonder if this reason is strong enough to restrict what we allow to express in Modelica.

• Rational number checking adds more complexity.

Yes, a tiny bit. Working with rational numbers in the ranges we'll encounter is a solved problem, so I see no reason to worry about this.

Let's see if someone can come up with more convincing arguments for not allowing fractional exponents!

[HansOlsson]

I can see three reasons against:

• The SI-standard don't include them and says that the numbers are normally small integers in 2.3.3 Dimension of Quantities, and when combining them in 5.4.6 it is not considered.

But 5.4.6 doesn't say anything regarding integer exponents either, right?

It shows how they are combined using multiplication and division; and integer exponents are closed under those operations.

[henrikt-ma]

It shows how they are combined using multiplication and division; and integer exponents are closed under those operations.

And rational are not?

[HansOlsson]

It shows how they are combined using multiplication and division; and integer exponents are closed under those operations.

And rational are not?

They are not introduced by any of the operations that are according to the SI-standard - but integer exponents (positive, negative, and zero) are introduced by them.

[henrikt-ma]

A colleague of mine prepared a list of 45 quantities known to Wolfram Language, where (non-integer) rational exponents appear: RationalPowersInUnits.pdf

Notably, not a single one of these have any other denominator than 2 in the exponents.

[henrikt-ma]

The same colleague of mine also provided this reference for examples of non-rational powers: https://physics.stackexchange.com/questions/13245/dimensional-analysis-restricted-to-rational-exponents

This puts the craziness of supporting rational exponents into perspective!

(Edit: With that reference in mind, have reformulated this issue to say rational instead of fractional.)

[henrikt-ma]

Back in the days, there was also a prototype for unit checking with rational exponents in Modelica: https://www.ida.liu.se/~petfr27/paperlinks/2008-03-Broman-Aronsson-Fritzson-Modelica2008-Unitchecking.pdf

I believe that the analysis they (anyone knows how to ping Peter Fritzson?) did when deciding to support rational exponents was right, and that the decision has nothing to do with the fact that the prototype still hasn't made it to a System Modeler product feature.

[eshmoylova]

There are no pre-defined units with fractional exponents in Maple's Units package. But, according to the colleague who maintains it, it was explicitly made to support them, if they come up in some expressions.

[casella]

One such case is the valve flow equation:

w = Kv*sqrt(dp/(rho/rho0))

where w is the mass flow rate (kg/s), dp is the pressure drop (Pa = N/m2 = kg.m/(s2.m2) = kg/(m.s2)), rho is the inlet density (kg/m3), and rho0 is the reference density (cold water, also in kg/m3).

The unit of Kv is a bit weird: kg/s / (kg/(m.s2))^(1/2) = (kg.m)^(1/2)

[sjoelund]

Isn't that because Kv should be squared inside the sqrt? It's just the unit it is because it was convenient to break it out?

[henrikt-ma]

In the old and closed #376 digged up by @casella, the following link was added today by @thorade. This and the discussion in the issue shows that the old issue closed without action is still craving for attention: https://stackoverflow.com/questions/69467926/cant-represent-a-variable-on-openmodelica

The only real difference between the present issue and the closed #376 is that the present issue is also opens up for presenting convincing reasons for not allowing rational exponents as an alternative to allowing them.

[henrikt-ma]

One such case is the valve flow equation:

w = Kv*sqrt(dp/(rho/rho0))

I think this example should also remind us that working with things like sqrt could suddenly become much more complicated if your tool starts being picky about units but doesn't even support rational exponents internally. In other words, to not break some fine code out there that works without units being fully checked, a tool that performs more than the minimal level of unit checking needs to at least support rational exponents internally – even if such exponents cannot be expressed in the unit strings. But if tools should be capable of handling the rational exponents internally, why not also allow them to be expressed in unit strings?

[HansOlsson]

Back in the days, there was also a prototype for unit checking with rational exponents in Modelica: https://www.ida.liu.se/~petfr27/paperlinks/2008-03-Broman-Aronsson-Fritzson-Modelica2008-Unitchecking.pdf

That paper only uses shows example where square root is used for taking the root of a squared unit; sqrt(4 m2) -> 2 m.

[henrikt-ma]

https://www.ida.liu.se/~petfr27/paperlinks/2008-03-Broman-Aronsson-Fritzson-Modelica2008-Unitchecking.pdf

The first item when they describe their design in 4.1 is that the exponents are rational numbers, and a motivation is given in 3.3. For examples, see for instance #376 or the attached RationalPowersInUnits.pdf instead.

[casella]

EDIT: I messed up a bit with the valve formula, my apologies. The correct formula is

q = Kv*sqrt(dp/(rho/rho0))

where q is the volume flow rate (m3/s), dp is the pressure drop (Pa), and rho/rho0 is the relative fluid density. Hence the dimension of Kv is m^(7/2)/kg^(1/2).

If the density (not the relative density) were used, we'd get this formula

q = Av*sqrt(dp/rho)

where it turns out that the flow coefficient Av is just an area, m2. But sometimes, for practical reasons, people want to use the relative density instead, and that brings the dimension of sqrt(rho), which is kg^(1/2)/m^(3/2), into play.

Isn't that because Kv should be squared inside the sqrt? It's just the unit it is because it was convenient to break it out?

@sjoelund, I'm not sure I'm getting your point. That formula is based on the empirical observation that the volume flow rate through a valve is proportional to the square root of the pressure drop, and inversely proportional to the relative density of the fluid; Kv is just the proportionality constant. Why should it be brought into the square root? Besides, if I bring it squared inside the square root, nothing changes in terms of its dimension.

[HansOlsson]

@sjoelund, I'm not sure I'm getting your point. That formula is based on the empirical observation that the volume flow rate through a valve is proportional to the square root of the pressure drop, and inversely proportional to the relative density of the fluid; Kv is just the proportionality constant. Why should it be brought into the square root? Besides, if I bring it squared inside the square root, nothing changes in terms of its dimension.

I cannot fully read the mind of Sjölund but I guess the point was that instead of q = Kv*sqrt(dp/(rho/rho0)) we could write q=sqrt(K2*dp/(rho/rho0))- or q^2*(rho/rho0)=K2*dp, where K2=Kv^2, and without the unit-issue for K2.

I also recall that some of the formulas don't have q^2, but q*|q| (and alternatively sign(dp)*sqrt(|dp|...)); I don't know if that is applicable here as well. And on top of that we add regularization which makes it more complicated - but that also shows that square-root is far from ideal

However, it also shows that we are discussing two related, but different questions:

• Are fractional units necessary in the formulas?
• Are fractional units used and useful in the formulas?

[sjoelund]

@sjoelund, I'm not sure I'm getting your point. Why should it be brought into the square root?

Because there is no physical unit for the square root of the length, etc. The formula is just written with these odd units because as you wrote empirical observations showed that it is proportional to the square root of the length, but you could formulate it in a way that adheres to the physical units (albeit probably in a more convoluted way and being required to calculate some different coefficient than what you have). @HansOlsson has a quite detailed response.

[henrikt-ma]

However, it also shows that we are discussing two related, but different questions:

• Are fractional units necessary in the formulas?
• Are fractional units used and useful in the formulas?

We've seen that rational units are being used, so that part is easy. Whether they are necessary sounds like a theoretical question to which I haven't seen any attempts to answer yet. Whether they can be considered useful seems like a matter of taste: they can be considered useful by the fact that they are being used in communities that we care about, and they could be considered useless if it turns out that one can theoretically prove that they aren't necessary.

I'd say it's not for us to decide how users should express their equations, in other words that it is being used that is the more important criterion.

[casella]

I'd say it's not for us to decide how users should express their equations, in other words that it is being used that is the more important criterion.

I fully agree. The valve formula is actually contained in the IEC standard 60534.2. Unfortunately, it doesn't use SI units, but rather engineering units such as bars and m3/h, which makes it even more convoluted (you get a sqrt(1e5) unit conversion factor if you go from bars to Pascals). Not to mention the widely used Cv coefficient, which uses US imperial units. But that it another story. In Modelica.Fluid.Valves we fixed this issue by using Reals and some explanation in comments, and that works fine.

I would say that these are fairly rare instances and we probably have much higher priority issues to work on, so if the question is: are fractional units ever used, I'd say the answer is definitely yes; if the question is, should we take care of this with high priority, I'd say the answer is probably not.

[casella]

As far as units and unit checking are concerned, IMHO it would be far more important to fix the issue of the units of non-dimensional literal constants in expressions, which are instead widely used in physical models. This issue actually prevented me to find bugs in real-life models, that should have been caught easily by unit checking, just because the formula contained a 2 coefficient, which acted as a unit wildcard. Luckily nobody got hurt, but in one case it was a close shave, as the model in question was actually the model of an emergency respirator for COVID...

Please see my last comment on #2127, we can continue that discussion there.

[henrikt-ma]

I'd hope for some synergy between what we have here and #2127. As we can tell from several different discussions, there seems to be general interest in improvements related to unit checking. While some topics are difficult and could take time to resolve, allowing rational exponents shouldn't be one of those topics.

If at least there was a compelling reason given in the specification for not allowing rational exponents, maybe this request wouldn't come up over and over again, and when it comes up we could just point the poor user to the reason given in the specification. (On the other hand, personally, I doubt that such a reason exists, why it would be better to just go with the flow and allow the rational exponents.)

[henrikt-ma]

As another example of rational exponents in industrial use, the polarization mode dispersion was recently brought to my attention. It is a property of an optical fiber arising from the following relation:

Because the imperfections are random, the pulse spreading effects correspond to a random walk, and thus have a mean polarization-dependent time-differential Δτ (also called the differential group delay, or DGD) proportional to the square root of propagation distance L

Source: https://en.wikipedia.org/wiki/Polarization_mode_dispersion

Use in product specification: https://www.corning.com/media/worldwide/coc/documents/Fiber/product-information-sheets/PI-1424-AEN.pdf

[HansOlsson]

Solved by #3439