Units - mole - MCAD13.1 glitch

[fjd]

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.

 

[IRstuff]

As far as I know, no one from PTC lives here. You should post in the Mathcad collaboratory; there is a specific "Suspected Bugs," but that's specifically for M14, since M13 is not supported anymore.

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

 

[IRstuff]

I wasn't paying attention to what the specific problem you were doing. Your SI gas constant is correct, but your English gas constant is not. A standard mole of ideal gas STP occupies 22.4 liters, which is 0.791 ft^2.

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

 

[IRstuff]

Per your definition, a mole of iron is 55.845 gm, while a lbmole of iron is 55.845 lb, i.e., there is 453.592 times MORE material.

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

 

[fjd]

Greetings IRstuff and thanks for your replies.

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

 

[IRstuff]

Sure, it does. You can, and should, define

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

 

[fjd]

Greetings IRstuff

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

 

[IRstuff]

I'll disagree, as did Gutman in the Collab. A mole is extremely well defined, being 6.02214199 x 10^23 molecules of a substance. Avogadro's number was specifically formulated to result in an amount of a substance whose mass in grams is numerically equal to its molecular weight. This is an internationally accepted definition promulgated by CODATA.

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

 

[fjd]

07:38 08/05/29

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://www.codata.org/taskgroups/TGfundconst/index.html

cites: "Redefinition of SI Base Units", ( 28 June 2005 ), recommends that consideration be given to redefining at the same time the mole in terms of a fixed value of the Avogadro constant. FJD > that objective is good.

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

 

[IRstuff]

The US has ostensibly been officially on the SI system since the Metric Conversion Act of 1975. The US National Institute of Standards and Technology does everything in SI units, wherein they use the BIPM definition of the mole as a fundamental unit in the SI unit system:

http://physics.nist.gov/cuu/Units/mole.html

The SI mole is a fundamental concept in chemistry, and is taught in all US schools.


TTFN

FAQ731-376

 

[IRstuff]

Besides, your own cited link:

http://www.engineeringtoolbox.com/individual-universal-gas-constant-d_588.html

clearly distinguishes lbmol vs. mol.

The losing of the lb prefix is simply sloppy, and dangerous, and the real reason for this "error."

TTFN

FAQ731-376

 

[fjd]

Greetings IRstuff:

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

 

[IRstuff]

I'll disagree with the need for a "fix." There are tons of units that Mathcad could have, but the more units they add, the slower the program will run.

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

 

[fjd]

Greetings IRstuff
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

 

[philipoakley]

Aren't Moles like the Radians / Cycles discussion ;-) in that you also need to state what items have been 'counted', be they atoms, compounds, molecules, etc.

How large is a mole of sand grains - Is life a beach?

Philip

 

[IRstuff]

Nope... You open up any chemistry textbook, and a mole is defined the same way. Atoms and molecules work the same for moles. Grains of sand, on the other hand are not well defined themselves, being sometimes heavy on quartz and other times being heavy on other things.

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

 

[fjd]

Greetings Philipoakley

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.

 

[IRstuff]

Again, that is untrue. If you define a lbmol, or kgmol, with the correct units, Mathcad will do exactly as advertised. The fact that Mathcad did not include lbmol is moot. Mathcad did not include furlongs and fortnights until version 12, even though those units have been around for centuries.

You keep harping on this, even though the site that you referenced:

http://www.engineeringtoolbox.com/individual-universal-gas-constant-d_588.html

clearly distinguishes between mol and lbmol in its table of alternate unit gas constants.

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

 

[philipoakley]

Given:
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