|
In my experience, one of the most common causes of errors in engineering calculations is confusion over units. Because Mathcad can carry the units through, and can convert between one system and another at will, it is a great tool for checking that you are using dimensionally meaningful expressions, and for using American / British expressions with metric units (and vice versa).
My advice to engineers is to ALWAYS enter the units into your Mathcad expressions. If Mathcad returns your calculation in nonsensical units or won't give you a result at all, there is a very high likelihood that:
a) You have made an error with your units; or
b) The expression you are using includes some empirical terms which implicitly include a dimensional component; or
c) You have made a transcription error when copying the expression.
Either way - you are much better off resolving this issue when it arises rather than blindly carrying on with a unitless / dimensionless number, which may be totally incorrect.
Here’s an actual example we uncovered recently when we were converting some Excel calculations over to Mathcad – mainly for better presentation and legibility and ease of verification. In the process of applying units to our previously unitless calculation, we discovered that the original calculation written in Excel contained a subtle error that had not been noticed. The results obtained were plausible for typical data entry values, and as this was just an intermediate parameter, it didn't affect the final result to any significant degree - but it was an error nonetheless.
The source document was the "Model Code for Steel Chimneys" (1999) by CICIND (International Committee on Industrial Chimneys). The actual term as it appears in the original source document is expressed as:
r/100t
When you read the expression in the source document carefully, it is evident how the expression SHOULD have been interpreted as:
(r)/(100*t)
However, the implied parentheses are NOT used in the original source document. The expression was simply transcribed by the originator of the Excel calculation by copying character-by-character as:
r / 100 * t
which is interpreted as:
(r/100)*t
using the standard hierarchy of precedence as seen in Basic, FORTRAN, Excel, etc. This same mis-transcription was repeated in the first round of Mathcad calculations, but because of Mathcad's superior formatting, the incorrect transcription of the expression appeared as:
r
--- * t
100
which is less ambiguous than the format in the source document (but is an incorrect interpretation in this case).
When the data input in Mathcad had no units, the expression yielded a dimensionless number, and the Mathcad worksheet solution matched the (erroneous) Excel worksheet.
We modified the Mathcad worksheet to make it "units aware" - largely so that users could work in whatever units they like (metres, millimetres, inches, feet, or a combination of any of the above). However, Mathcad threw up an error, because the expression was now dimensionally incompatible. We went back to the printed source document, worked out where we had gone wrong, corrected the Mathcad worksheet - and now we get correct solutions, and it will work regardless of what units you choose for r and t.
When we identified the error (by adding "units awareness"), and correcting for the incorrect construction, the expression now appeared in Mathcad as:
r
-------
100 * t
which is again unambiguous, but is now a correct interpretation.
In my experience, this sort of transcription error is one of the most common errors that users make, and it can be one of the hardest to track down in non-dimensional expressions, but Mathcad immediately flags some sort of problem if you try to evaluate a dimensionally-inconsistent expression in a "units aware" calculation.
Julian Hardy
Manager - Advanced Analysis Group
Infrastructure & Environment
WorleyParsons |
