Choice hierarchy between same base units and .to() method not working

[snipa-1337]

Hi Connor, I am working with structural fire safety verifications, and I had to add some thermal units to the structural environment. They were J, MJ, J/m² and W. I am pasting the code additions to the JSON file below to double-check if anything is wrong with it.

"J": {
        "Dimension": [1,2,-2,0,0,0,0],
        "Symbol": "J"},
    "MJ": {
        "Dimension": [1,2,-2,0,0,0,0],
        "Value": 1e6},
    "J_m2": {
        "Dimension": [1,0,-2,0,0,0,0],
        "Symbol": "J*m⁻²"},
    "W": {
        "Dimension": [1,2,-3,0,0,0,0]},

The funny thing is that kN/m and kJ/m² are the same base units (kg/s²), and for some reason, forallpeople is choosing the latter to represent my loads. I don't know how forallpeople choose between two units with the same base. What is the hierarchy, and how can I change that? I tried to use the .to() method to change to Newtons ('N' or 'N_m'), but it didn't work. It keeps changing to kJ/m², as seen in the screenshot below.

[abegertler]

Hi, I would like to second this question. And specifically I have been trying to figure out, is it possible to change the hierarchy of unit display within our environment? Say I am using structural at the top level, is it possible to make length outputs prefer display in inches rather than meters? I mean, without writing length.to("inch") every time.

If I do all calculations strictly in inches, I have no problem, but once I start mixing in with SI units, like thermal expansion with degrees Kelvin, even if the other units cancel out, my length will suddenly be reported in meters.

Thanks so much Conor!! Abe

[connorferster]

@snipa-1337 @abegertler Thanks for bringing this up. I would like the library to work in this case. I think #54 could help in this case, too.

The root cause of this is part of a bigger issue on how I modeled the quantities and how I wanted the representation to work.

There are three attributes on each Physical instance that are used to determine the representation of the quantity:

1. .dimensions - The "big bucket"
2. .factor- The "smaller bucket"
3. .prefix - The "special case" for scaling SI units

So, there are really only two attributes to determine how to show a quantity, the dimension and the factor. First, the library sorts out what eligible units exist for quantities of that dimension. Then, it looks to the factor, which is assumed to be unique for each unit. However, what if there are two unit representations of a quantity with the same dimension and, in both cases, the .factor == 1? This is the problem we are facing here.

The question about hierarchy: how does it choose? It is currently whichever quantity definition comes first in the environment JSON file: since J_m2 is first, that is what is rendering by default. I just verified this for myself by copying your quantity definitions into my own "structural.json" file and by changing the order in the file, I was able to get one or the other unit displayed.

To solve this, we need to figure out an additional way of keeping track of unit preference. Perhaps, behind the scenes, each unit definition is enumerated and we store the enumeration in the Physical instance? Then maybe the .to method could accept either a symbol or the enumeration? Going on from this, maybe #54 could be implemented as by setting which unit definition has the enumeration 0 and that would be selected as the default preference.

I am just typing out loud here. This is a new idea that just occurred to me. Thoughts on this?

[snipa-1337]

@connorferster Hi Connor, First of all, let me say that by no means I am an excellent developer like you; I am still learning the basics and having fun with them. So my suggestions here might be impossible to implement, or I could be using the wrong terminology, but I would like to help because your project is fantastic.

That being said, also typing out loud here:

As the problem is the order of the JSON file, a possible solution that came to my mind is that once we load an environment, you could add a test to search in the JSON file being loaded if there are two or more quantity definitions with the same dimension and factor.

E.g. the user loads "structural.json" and the if test shows that there is a conflict between kN/m and kJ/m. Then you raise a warning like: "kN/m and kJ/m have the same base units, current priority: kN/m, keep it?" If the user inputs "no" or "kJ/m", you could copy the kN/m entry from the JSON, delete it and append it again (assuming that it appends to the tail of the file). This way you would be changing the order without changing the main structure of forallpeople.

This sounds more like a trick than a solution, but I think it could be implemented quickly maybe with regular expressions?

This would not solve, however, the problem of #54, and it would change the rendering in the whole notebook, making it not possible to work with both units. So I am not sure if it's a good idea. I like more your idea of enumeration, I just thought that maybe you would have to make deep changes in how forallpeople was designed to implement it.

I will keep trying to think of solutions, if I come up with something else I will post here.