Units - mole - MCAD13.1 glitch
Units - mole - MCAD13.1 glitch
(OP)
Am attempting to become proficient at MCAD13.1. MCAD advertises that I can add inches + furlongs + kilometers and MCAD will produce the correct answer, in the units of my choice.
This means that I should be able to calculate the density of an ideal gas, and input various values of the universal gas constant, - with proper dimensions - and expect to get the correct answer. My experience and attached documentation indicate that MCAD does not know the difference between a gram-mole, kilogram-mole, or a pound-mole. AND depending upon your choice, your answer can be off by a factor of 453.
See attached, rather lengthy, file.
This means that I should be able to calculate the density of an ideal gas, and input various values of the universal gas constant, - with proper dimensions - and expect to get the correct answer. My experience and attached documentation indicate that MCAD does not know the difference between a gram-mole, kilogram-mole, or a pound-mole. AND depending upon your choice, your answer can be off by a factor of 453.
See attached, rather lengthy, file.





RE: Units - mole - MCAD13.1 glitch
However, I don't see a bug, but an erroneous supposition on your part. You state that your second Ru is equivalent to the first, but your first Ru = 3771 J/mol*K, NOT 8.314472 J/mol*K, which you can easily check by asking for the desired units in the placeholder where you put your lbf*ft/mol*R
So the "error" in the calculation is exactly the same ratio as in the Ru values you put in; no surprise.
You're also using a 144 in^2/ft^2 conversion factor, which is unnecessary in Mathcad, since it's numerically and functionally equal to unity. You can delete the factor and see that none of the numbers change.
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
Based on your mole mass of 28.96 lbm/mol, at STP, your gas density is 36.61 lb/ft^3, which is pretty close to your second result. Using the correct SI value of R as 8.314472 J/mol*K, the English equivalent = 3.407 lbf*ft/mol*R, which Mathcad can automatically calculate, simply by substituting the desired units in to the display equality expression.
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
Therefore, you cannot use 453.592 times more material and still use the same ideal gas volume, you will, of course, get the wrong density. If you must insist on using lbmole, then you need to divide your defined value by 453.592 to get a thermodynamic mole that fits in 22.4 liters at STP.
Every one of your "errors" is because of the usage of lbmoles without correcting for that.
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
I am going to respond to each of your replies:
Reply #1. You just pointed out the glitch. Both Ru = 1545 ( lbf * ft ) / ( lbmole * R ) and Ru = 8.31 joule / ( mole * K ) values are taken from standard engineering texts.
As you converted the 1545 to SI you found that MCAD did not give the correct answer. THIS IS EXACTLY MY POINT. One cannot treat moles the same way most other dimensions are handled in MCAD.
Reply #2 The US system uses Pounds and Pound-moles. At standard conditions one Lb-mole occupies 359+ ft^3. This number has been around for at least the better part of the last century.
Note: To be correct, the dimension of the mole used in your conversion is gram-moles for both 8.3 and 3.4 numbers >>. Using the correct SI value of R as 8.314472 J/mol*K, the English equivalent = 3.407 lbf*ft/mol*R, which Mathcad can automatically calculate, simply by substituting the desired units in to the display equality expression. (See reply #1 again )
Reply #3. What you are saying is correct.
The point that I am making is that MCAD does not recognize the US quantity of the Lb-mole, and the fact that the SI mole is based on the gram-mole.
While MCAD recognizes inches and millimeters and converts well, it missed the boat on moles. Matter of fact, why does MCAD use mole and mol in their units?
MCAD advertising says "it handles units", clearly in your reply #1 you found that MCAD does not handle moles properly.
BTY I suspect we have an age difference and that you probably do not fiddle much with moles in aerospace, unless you fiddle with the thermo part of the engine or the environmental control system.
FJD
RE: Units - mole - MCAD13.1 glitch
lbmole:453.59mole.
Then, your first Ru = 1545 lbf*ft/lbmole*R MWt:28.96lb/lbmole resulting in p=0.075lb/ft^3
You'll get the same density in both calculations.
You cannot use a molar density that's 454 times larger, plug into the same equation and expect the same answer.
The definition of Ru for your units requires an lbmole in the denominator, not an SI mole.
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
I have already implemented exactly what you have suggested. I did it in a MCAD template to make sure I am consistent.
In either case, this approach is a Band-Aid since it is correcting a poor, improper or inadequate "MCAD" definition. MCAD is mixing apples and oranges in this case.
Thanks for your input
Frank
RE: Units - mole - MCAD13.1 glitch
The fact that an industry decides to create a new unit called a lbmole is machts nichts, particularly since, if defined and used correctly, it does not create any inconsistencies. By definition, an lbmole has to be mole*lb/gm; it is NOT a mole by ANY definition. The fact that you chose ignore the correct definition of an lbmole created the "errors." Had you used the CODATA value the gas constant and the correct definition of lbmole throughout the sheet, you would have NEVER had a problem.
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
We have a language and communication issue. In the CODATA world of SI the objective is to "improve" the quality of data and gain an acceptance of the SI unit system. Seems to me that the definitions and useage of words in the US-English language have not been considered when MCAD accepted the CODATA definition of "mol" and "mole".
MCAD mathematicians, and computer programmers have taken the CODATA definition of the mole and "ran with it", never realizing that there were gram-moles, kilogram-moles and pound-moles. They must have considered "a mole is a mole, the world around", and "if CODATA says it, it must be correct".
MCAD advertising compounded the issue by leading purchasers to believe that their UNITS feature took care of all problems with units and dimensions.
MCAD's documentation is no "fountain of user helpful information".
The problem that FJD is addressing is the letters "mol" and "mole" have been used in the US to mean "gram-mole", "kilogram-mole", "pound-mole". Text and scientific references, written in English and available in the US, will show the value for the Universal Gas Constant is 1545 lbf*ft/(mole R). If I use that value (1545) in MCAD and the MCAD UNITS icon to insert "mol" or "mole", then my problem will have an error, 1545 needs pound-moles and MCAD uses gram-moles. MCAD does not define pound-moles. MCAD seems to show consistent SI units and US units, except for the mole, perhaps there are other inconsistancies.
RE your reply: You noted in your first paragraph the term (word) grams. Does that not associate the Avagadro's number definition with the SI system? Matter of fact, CODATA only speaks SI. Is not pounds the normal unit of mass in the US system? MCAD is advertised to work "seemlessly" between systems of units. MCAD has mixed grams and pounds in the US system, as they pretain to mole.
In your second paragraph, the pound-mole was an accepted unit in the US system of units before CODATA existed (pre 1950), it is not a new unit. US engineering texts and references in the 1950's and 1960's freely use pound-moles as an acceptable unit. The "classic" definition of the lbmole is the weight in pounds of a substance divided by its molecular mass. Likewise, the gram-mole was defined as the mass of a substance in grams divided by its molecular mass. I submit that I can be consistent in any system of units and perform correct calculations, mixing and matching is where the inconsistancies begin. The US developed and engineered many advanced systems using these "classic" definitions, they must work.
CODATA "Fundamental Physical Constants" http:
CODATA is attempting to define commonly accepted standards, and that is good for science and industry.
CODATA redefines quantities that have been formerly accepted as standards.
It seems to me that CODATA, in an attempt to define" the quantity of a substance" also chose to neglect the "local US" common language useage of similar letters / words, and that is the issue of which I speak.
Regards
Frank
RE: Units - mole - MCAD13.1 glitch
The SI mole is a fundamental concept in chemistry, and is taught in all US schools.
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
The losing of the lb prefix is simply sloppy, and dangerous, and the real reason for this "error."
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
I must agree with your conclusion about "sloppy". I only wish that PTC would issue a "FIX" for MCAD13.1 and if necessary for MCAD14 to include gmole, gmol, Lbmole and remove "mol" and "mole". A website download.
I am aware that a search of NIST for MOLE will show that it is "the official system of units", and I believe it references kilogram-moles by virtue of the 0.012 constant.
NIST103 "Thermo Data Engine" is done only in SI.
HOWEVER NIST23 REFPROP gives the user the option of selecting the units of his choice. Refer: http://www.nist.gov/srd/PDFfiles/REFPROP8.PDF Select the "Users Guide" icon just above the price field about 2/3 down the sheet on left hand side. It ( mole selection ) is referenced below the figure of the REFPROP selection icon on page 35 of 57, Section 7.1 that both Lbmole and kilogram mole can be used in and by REFPROP.
If you are not familar with NIST23, and work with the "more popular" fluids, you might consider purchasing it. It's a bargin.
As far as the US schools teaching the SI system, beginning in grade and high school, that's true and sad to say, many do not discuss other units of measure. That's a whole other topic.
Regards
Frank
RE: Units - mole - MCAD13.1 glitch
I'm not sure why not teaching obscure units is a bad thing. The main reason that the US has not joined 6 billion other people is precisely because of the continued adherence to the ad hoc unit systems that have no real purpose or connection to the primary unit system that's being taught in all US schools. Obviously, even the US government and its agents are bad at this. We have a military contract whose requirements document uses a mix of English and SI units, despite a paragraph claiming adherence to SI units.
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
RE: "I'm not sure why not teaching obscure units is a bad thing." Perhaps the teachers do not understand the concepts, and "why burden the kids minds". Also probably parallels why Americans are not multi-lingual.
Have a great weekend
Frank
RE: Units - mole - MCAD13.1 glitch
How large is a mole of sand grains - Is life a beach?
Philip
RE: Units - mole - MCAD13.1 glitch
Nonetheless, it's a relatively trivial matter to set up one's Normal.xmct template file to include any rational units one cares to add. For the more adventuresome, the units can be added directly to the units definition files for Mathcad, but that's not a trivial exercise.
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
The classic definition ( pre circa 1956 ) of a mole was the "mass of stuff" divided by the "molecular mass" of the stuff. Since the mass could be measured in either the metric system (grams) or the english system (US) (pounds)and one pound of mass was the same as 454 grams, when you divided 1 pound by the molar mass you got one value. When you divided 454 grams by that same "molar mass" you got a second value. Each of these values had different dimensions, 1Lb/mole wt was defined as a "Pound Mole". 454grams/mole wt was defined as a "gram mole".
The International Agency in Paris that worries about Units has defined everything in SI units. They do not seem to worry about other unit systems. They defined a mole in terms of their "beloved" SI system.
When MathSoft programmers setup the UNITS they apparently did not know there was a POUND MOLE, a GRAM MOLE, or a KILOGRAM MOLE. Hey, 1956 is BC (before computers). Its interesting that they clearly knew the difference between a meter and a foot. They presented only "Half of the Story" when they defined UNITS of SUBSTANCE in MCAD. MathSoft marketing sales pressed the fact that MCAD can work "between systems of units" flawlessly. MCAD13.1 can't since it uses the US system of definition of the mole as GRAM MOLES, not POUND MOLES (to be consistent with using POUNDS for mass. There is no conversion in MCAD between the SI system of MOLE and the US system of mole. Thats the issue.
RE: Units - mole - MCAD13.1 glitch
You keep harping on this, even though the site that you referenced: http://w
And again, the whole point of Mathcad's unit definitions is that adding an lbmole is trivial. And, if you want it as part of the built-in units, it's doable.
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Units - mole - MCAD13.1 glitch
1. The mole is the amount of substance of a system which contains as many elementary entities as there are atoms in 0.012 kilogram of carbon 12; its symbol is "mol."
2. When the mole is used, the elementary entities <u>must</u> be specified and may be atoms, molecules, ions, electrons, other particles, or specified groups of such particles.
I'm sure that I can have a grain of sand as my elementary entity ;)
and more importantly, one <i>should</i> identify the entity being counted in the mole, just as one should declare what entity is being counted in the 'Hz' discussion.
I've still got to get round to calculating how big my beach is ;)