I've been using SMath for several years now, and I generally like it. But one shortcoming compared to Mathcad has always been the units for the US, even though consistent and automatic unit conversion is SMath's most helpful ability compared to something like Excel for engineering calcs. Most of the time, I can just go through the extra steps of typing in the units I actually want every time SMath displays the results in metric units. But I can't do that in matrices. If everything in the matrix is the same unit, then I can type in my USCS units outside the matrix and everythign is good. But sometimes I have mixed units like with stiffness matrices, and I end up with results like below with no way to force them to display correctly. Even these are the result of an extensive workaround earlier in the worksheet where I basically made all my inputs dimensionless and had to keep track of units manually, as some of my stiffness matrices will have various elements in kips, kips/in, and kip-inches, all in the same matrix and not segregated by row or column. I've tried using the "Imperial" option in the user settings file several times over the years, but that is worse than leaving it metric and manually changing every unit in every formula. I've tried editing the Units.xml file, but I'm not sure how to go about that. Is there any guidance on how to edit that? Long story short, I would really request a better ability to define default units, especially when dealing with matrices. They need to be able to have certain units on a per-element basis.

The disadvantage of messing around with Units.xml is that your sheets won't be portable unless you convince the recipient of your sheets to also install your Units.xml. I tried to include a custom Units.xml in my inofficial portable distribution of SMath Studio but I skipped that because for me, the added value was very limited. This trade-off might be different for you.

In my Handbook (google SMath handbuch) you find some hints on the format of Units.xml (appendix F.3). This, however, hasn't been tested for a while and doesn't include re-definition of default units, because I never managed to do this.

This, btw. would also be handy for metric units. E.g. if you define an angular velocity of 1 rad/s this simplifies to 1 Hz, which is plain wrong. 1/s would be acceptable. You get this if you switch to symbolic evaluation but at the cost of rational representation of the numeric value.

In 2016 I filed a feature request on this.

Wrote

... If everything in the matrix is the same unit, then I can type in my USCS units outside the matrix and everythign is good. But sometimes I have mixed units ...

Hi Jason. This is a workaround. You can't show a column vector with mixed units, but a row vector.


row_vec_mixed_units.sm (3 KiB) downloaded 96 time(s).

Best regards.
Alvaro.

Martin, I agree. I would rather not have to edit Units.xml, but I'm not sure how else to accomplish it besides preventing SMath from even knowing those other units exist. Other than occasionally getting into some Eurocode calcs for structural mass timber connections, 99% of my work is in the US where metric is never an issue, and I'm basically the only one at my office (or in my grad school class, which is actually where I'm getting more heavily into the matrices now) that uses SMath or any of the calcs I develop from it. Office colleagues use Excel, and classmates use Mathcad. So a custom xml file might not be a big deal for me. I would like to see some more control of units moved into the program UI where you don't have to exit the program and edit settings files just to switch the default from Metric to Imperial or vice versa. But then the switch to Imperial has never really helped me because it always wants to use units I don't want, so I end up retyping all my units just as much as I did when it was set to metric, so I normally just leave it metric in the User Settings file.

Alvaro, thanks for the workaround suggestion. I don't think it will help, but let me add some more context. These stiffness matrices are (currently) 4x4 matrices with bending stiffnesses in 2 positions of each column and rotational stiffnesses in the other two positions. Previously, for truss stiffness matrix work, I was able to just apply kips/in outside the matrix because they were all axial stiffness terms, but now I have more degrees of freedom and more terms, and different units among the terms. This week, my class is proceeding to frames that will add more degrees of freedom and more variety of units among the different terms. See below for an example where I made everything unitless based on my input being in a specific input (length in inches, etc) so that my numerical values are correct in all terms, and what the same matrix looked like before when I had units assigned. I would like to see the units assigned and carried through if possible, because it is extra work to make sure I apply the correct units to my results at the end based on which elements were used from the matrix (e.g. is the value in my final system matrix based on the bending or axial stiffness value? One or the other might get canceled out because of boundary conditions, and that elimination happens in subsequent steps.) So while the row vector may be a workaround for the smaller vectors I'd initially shown in my first post, the matrices those derive from are bigger and more complicated and are actually the root problem, and I don't think that would be an option for those. But thank you for the suggestion!

Hi Jason. This is a workaround for show mixed units in a matrix.

matrix_mixed_units.sm (18 KiB) downloaded 88 time(s).



Best regards.
Alvaro.

Jason,

I know you were involved on this thread, but I'll share this thread regardless:

Wrote

... the attached units.xml must be used in place of the original file in the C:\Program Files (x86)\SMath Studio\entries folder. Please make a backup copy of the original units.xml file before switching so that you can always go back to the original.

Units.xml.txt (26 KiB) downloaded 237 time(s). (remove the .txt extension before use)

The attached units.xml file has been modified so that US Imperial units are the default for the Length, Area, Volume, Force, Pressure, and Mass categories.

As for the construction of the Units.xml file, I have a decent grasp on how it works and the issue would be this: changing the units to Imperial will not exactly make it easier to read as time (i.e. Seconds) is involved; so instead of 11 kip/in = 1,926,395 kg/s², you would get the answer of 11 kip/in = 4,246,974 lbm/s².

One thing you could try is to construct your matrix with pseudo units (that is, use a "unit" that is not defined, before your matrix for ease of reviewing. Just remember to define your "unit" afterwards to make the math work out). Below is an example, I create a matrix with the unit of 'customKIP. I multiply that matrix by inches (see variable F2) and display the result. After that, I define 'customKIP:='kip and the math now works out:



Hope this helps!
- Kenny Lemens, P.E. ᵂᴵ

Another way (always there is one more). Using Dimension utility, from this post.

dimensions v2.sm (68 KiB) downloaded 99 time(s).



Best regards.
Alvaro.

Usable default units for (the) US

Only half stirring here...

The US officially has usable units, and they are metric.

The imperial units still being used are now fully defined via the metric standards.

So imperial measurements/units are just metric measurements remapped via a hopefully 1:1 mapping (what type of gallons/inches/etc were you talking about? Rounding/resolution issues etc).

Twice the tooling costs and ~4x the error rate can't be good.

I'd rather the effort was put into other parts of SMath, rather than continuing an error-prone relic.

That's nice... and you're perfectly entitled to that outsider's opinion. Meanwhile, those of us here in the US work in US units like feet and kips. It's what are our calcs are expected to be in, so you're more than welcome to submit US calcs in metric units if you want, but your comments don't really help the practicing engineers in the US who still need to write effective calcs in the units used the vast majority of the time in our region. I could just as easily say that the rest of the world really has a usable language in English, so why bother with Russian and German and Spanish, etc? But dismissing the languages of other regions would probably be just as condescending as dismissing our regional units system ... Also, as long as the system of units is internally consistent, errors are not tied to the system of units but rather to the user's misunderstanding of them. I could probably make just as many errors in metric units as you could in US units.

Jason

Greetings,

It is best not to miss the forest for the trees.

Having OutputUnitsSystem=Imperial behave as anticipated would be a nice feature, but misses the larger picture of permitting a user to define a set of default units. As an Engineer in the USA, I know that the use of inch or feet depends on your profession, whether you want to use gallons or ft³ or in³ will depend on your application. Having a an Imperial loadout of feet and gallons for the default output units will not be a feature that I am interested in as I work primarily with inches and in³. I know this holds true to metric as well.

Allowing a user to customize their default set of output units is the true goal.

With that being said, the reason OutputUnitsSystem=Imperial doesn't work is because of Gravity; if you don't plan on using force or pressure, OutputUnitsSystem=Imperial works just as expected; its just until the acceleration due to gravity gets implemented into the conversion that the logic breaks down. Also, leaving units as Metric isn't a great solution either as the conversions as imperial→metric→imperial are not perfect (when gravity is involved), leaving large fractions for symbolic representations when they need not exist.

I have been able to come to terms with this limitation by modifying the units.xml file to have a new base unit of type Force; thus I have (3) unique units as it comes to the pound:

1. pound as mass
2. pound as weight
3. pound as force

Not a great solution, but I work with pound force as a base unit in most of my calculations; it serves my purposes.

Merry Chrsitmas!
- Kenny Lemens, P.E. ᵂᴵ

Thanks Jason and Kenny, agreed.

I did not deny the reality. It is just a pity that the USA could not make the change (the engineering bodies in the US pushed for metric at the time) when pretty much everyone else did.

For US manufacturers, fabricators etc the dual-tooling etc must be crippling. Many have changed to metric-only, but their supply chains often have to be overseas as many mixed-shops can't do metric well enough.

Wrote

... error-prone relic.

I like it. NASA has several of those relics in their Museum.

The key scientists behind the Apollo and earlier shots were using metric (ie not imperial): https://www.eclipseaviation.com/the-metric-system-a-key-to-the-success-of-the-apollo-moon-landing/

The cost was that they had to use precious computing resources to display the metric calculations in imperial (again, 'the cost of imperial' ): https://ukma.org.uk/why-metric/myths/metric-internationally/the-moon-landings/

The cost of mixing measurements continued: Metric vs Imperial Units: How NASA lost a 327 Million Dollar Mission to Mars: https://everydayastronaut.com/mars-climate-orbiter/

The latest moon shots are metric only: https://science.nasa.gov/science-news/science-at-nasa/2007/08jan_metricmoon/.

Wrote

How NASA lost a 327 Million Dollar Mission to Mars: https://everydayastronau...om/mars-climate-orbiter/

IMHO, NASA has no QA [Quality Assurance Department].

Greetings,

The problem of "mixed units" does not disappear if Imperial is replaced with Metric; the issue will just migrate to the issue of "misplaced decimal places," and there is no shortage of these types of conversion errors (e.g.; Spain’s S-80 Submarine Program).

The use of N/㎟ instead of ㎩, or the use of N instead of kN, could very well occur and failures would be no less grand when compared to an Imperial/Metric conversion errors.

Thus, the importance of utilizing units within equations: A huge perk of using SMath over Mathcad 15.0 is that SMath has the capacity to construct a stiffness matrix with units applied (in Mathcad, you were forced to make a matrix unitless). Factoring out units only to factor them back in later is not wise if it can be avoided:

At the end of the day, this conversation is not so much Imperial vs. Metric, but rather having the ability to perform quality control and/or prevent introducing needless errors. With regards to the first post:

Wrote

...But sometimes I have mixed units like with stiffness matrices, and I end up with results like below with no way to force them to display correctly...

Notice that Jason does not want kg to be replaced with lbm , nor does he want m to be replaced with ft, but rather to have 2224.111 ㎏ ㎨ reported as 0.5 kip. From a metric standpoint, I would presume the result of 2.22 kN would be preferred.

What are the 'solutions' to this limitation:

1. make inputs dimensionless
   
   • PRO:
     • results of force will not report values in terms of seconds
     • Data will be Compact

• CON:
  • have to keep track of units manually
  • harder to perform quality control
  • allows introduction of errors

utilize custom units

• PRO:
  • results of force will not report values in terms of seconds
  • easier to preform quality control

• CON:
  • requires more setup
  • inability to force units to simplify (e.g., ㎏*㎨ --> kN)
  • custom units will be at odds with built-in units (i.e., 'inches ≠ in )

Developers to better support Imperial units as default

• PRO:
  • results will be reported in imperial units

• CON:
  • results will not be reported as expected (e.g., force will still be reported in terms of seconds)
  • inability to force units to simplify (e.g., lbm*in/s² --> kip)
  • A current bug/error to the program for (pending 10 years), not easily fixed...

Developers to allow users to define a customize set of Output Units for all/any UnitsDimensions

• PRO:
  • results will be reported in units you want to see

• CON:
  • will require extensive resources/time to develop

This feature request is with regards to Option #3, but this will actually do very little to actually produce the intended results. Option #4 would address a huge limitation of SMath, but implementing such a feature is easier said than done. I would avoid Option #1 as managing units separately is prone to errors.

Therefore, the best path forward would be to implement a version of #2, where you can review your math in the context of a pseudo unit (reference: https://en.smath.com/forum/yaf_postsm79742_Usable-default-units-for-US.aspx#post79742)


-Kenny Lemens, P.E. ᵂᴵ

I'd vote for option 4 in the particular form of providing a command, which sets the default unit to a particular one, e.g.

DefaultUnit(N*mm) would display all values of matching dimension (whatever simplifies to kg*m^2/s^2) in units of N*mm (until the next such command is issued).



Pro:

- For matrix or list display it would be a way to control the display of individual components.
- For scalar results it would mitigate the need to adjust the unit manually on a by-region level.
- Should be straightforward to implement: Whenever a quantity is displayed, look if there is a custom unit for that dimension and if so, use that.
- Would be completely sheet-based, i.e. no portability problems.
- Hiding the setting commands (in a collapsed area region or outside the printable area) would not break comprehension of the sheet, because in an ideal world you anyways would have command over the units in results.
- Keeps the full power of the existing unit handling system

Con:

- Not for free in terms of work for implementation.
- Would require that DefaultUnit() can access it's argument in non-simplified, i.e. verbatim way. User-defined functions can't do that.
- It would not be possible to distinguish work or energy in J from moment in N*m, because both simplify to the same base units. Same with all units simplifying to numbers.

Yet the second con is a fundamental problem as long as expressions don't get a "quantity" attribute, which then would allow for default display units on a by quantity base rather than on a base unit base.

Quote

...

IMHO, NASA has no QA [Quality Assurance Department].

Getting Apollo to the moon, JWST to L2, Artemis around the moon etc shows the lie in this (clearly NASA has had both reliability engineering and QA).

Good reliability engineering would see QA not having to check measurement unit conversions.

Quote

...

The problem of "mixed units" does not disappear if Imperial is replaced with Metric; the issue will just migrate to the issue of "misplaced decimal places," and there is no shortage of these types of conversion errors (e.g.; Spain’s S-80 Submarine Program).

This argument is fallacious as it doesn't 'just migrate'. The 'decimal places' issue exists independent of the measurement system used (ie imperial has this problem independent of the SI system).

Option 0: Given the US inch is defined as 25.4mm (exact), the US pound is defined as 0.45359237 kg (exact), and the US second is defined as 1 SI second (exact): the best option is to do all the calculations in base units (ie SI, & with adequate resolution). Convert in, and convert out with adequate resolution knowing that this is an avoidable workaround (aka the 'imperial unit cost' ).

Quote

...

Notice that Jason does not want ... but rather to have 2224.111N reported as 0.5 kip.

Sorry Kenny & Jason, I suspect that I'm not understanding this issue fully. SMath appears to be handling the conversions and units display correctly:

Apologies accepted.

As for the this issue: SMath has the ability to define the Output Units System; it is Metric by default but you can change it to Imperial. This will has the effect of reporting units as Imperial, but there are some unworkable bugs (like pressure is deadlocked into using inHg, unit override does not work for units containing 'force;' this is not a fully functioning feature so it is not recommended for use:


While it is true that you can just keep it in Metric and override the unit placeholder to obtain your result, there are several items of note:

• Will be required to override units on each and every equation/evaluation
• Symbolic evaluation does not produce results as anticipated:
  
• Tooltip on a variable/function will be in terms of metric units
• When working with Matrices with mixed units, the results will be reported in metric with very little ability to influence
  (this is the driving limitation for this Feature Request)

As you indicated in your post, this is not an issue for simple evaluations, or for variables that share a common unit. However, the ability force units to report as you desire is not possible if you have a Stiffness Matrix (thus not strictly an Imperial Units issue, Metric has the same limitation: your values will always report in s² for a matrix when mixed units containing force/acceleration is involved). Do not get us wrong having a Stiffness Matrix WITH mixed unit support IS AMAZING! We just would like to have some control over which units are selected/displayed on the output in order to validate/report results.

I agree with Mr. Kraska; If it was possible to declare a preferred alias for any UnitsDimensions as a local worksheet feature, this should address the concerns of these feature request, as well as to make progress on feature request #1; this would have my vote as an acceptable solution.

Wrote

I'd vote for option 4 in the particular form of providing a command, which sets the default unit to a particular one, e.g.

DefaultUnit(N*mm) would display all values of matching dimension (whatever simplifies to kg*m^2/s^2) in units of N*mm (until the next such command is issued).


...

-Kenny Lemens, P.E. ᵂᴵ

Thank you for the excellent summary Kenny, greatly appreciated.
If I have this right, it sounds like there is agreement that the following steps are not at issue:

1. User declares their input variable in whatever units in their preferred units (an unavoidable pre-requisite).
2. SMath calculates the results, using SI units internally, and the results are correct in their SI units.
3. The SMath conversion to imperial units, as chosen, are correct (noting the bug/limitation described in SS-2286).
4. The display of significant figures (incl training zeros) is correct.

Regarding the symbolic representation of 0.52 kip (0.52 should be represented as 13/25): this is likely is correct, but likely arises from the finite resolution of the unit-conversion steps (call it ‘JACOIU’ for brevity).

Likewise, to me it sounds like your Option 4 would be best. Continuing the summary theme: to work adequately some development work is needed:

A) On a per-sheet basis: per-measurement basis (ie per-MKS calculated combination): the ability to force the displayed units of calculations.

Agreed, it looks to me like the behavior described in SS-2286 is inconsistent with the nicely consistent behavior with SI units. So, it is likely a bug and needs to stay as an issue despite A) above nicely bypassing the issue.