Is your feature request related to a problem? Please describe.
MolarMass.PoundPerMole does not represent lb/lbmol (pound-mass per pound-mole), which is the unit typically meant when working in the traditional FPS (English Engineering) unit system. Instead, PoundPerMole behaves as lb/gmol (pound-mass per gram-mole).
This becomes apparent when converting between PoundPerMole and KilogramPerKilomole:
var molarMass = MolarMass.FromPoundsPerMole(1);
double kgPerKmol = molarMass.KilogramsPerKilomole;
// Expected: 1.0 (since lb/lbmol == kg/kmol numerically)
// Actual: 453.59237 (because PoundPerMole is really lb/gmol)
kg/kmol and lb/lbmol are numerically identical — both express mass per mole where the mass unit and the mole unit are drawn from the same "family" (SI mass + SI mole count in one case, US/Imperial mass + US/Imperial mole count in the other). Because PoundPerMole is implemented as lb/gmol rather than lb/lbmol, that expected 1:1 relationship doesn't hold, and any conversion via PoundPerMole produces a value off by the gram-to-pound conversion factor (453.59237). This is easy to miss and produces silently incorrect results in engineering calculations that assume PoundPerMole corresponds to the pound-mole convention.
Describe the solution you'd like
Add a new unit, PoundPerPoundmole (lb/lbmol), to MolarMass, with a conversion factor of exactly 1.0 relative to KilogramPerKilomole.
This would let users working in the traditional FPS system convert correctly between molar mass values without manually applying a correction factor for gc or mole-basis mismatches, consistent with how UnitsNet already resolves other FPS/SI mismatches internally through SI base units.
Describe alternatives you've considered
- Manually multiplying/dividing by 453.59237 (grams-per-pound) when converting
PoundPerMole values — workable, but error-prone and easy to forget or apply in the wrong direction.
- Redefining
PoundPerMole itself to mean lb/lbmol — not backward compatible, since it would silently change the meaning/value of an existing unit for any consumers already relying on the current (lb/gmol) behavior.
Adding PoundPerPoundmole as a new, explicitly named unit avoids breaking existing behavior while giving FPS-system users a correct, unambiguous unit to use.
Additional context
KilogramPerKilomole and the proposed PoundPerPoundmole should be a straight 1:1 conversion, since kg/kmol and lb/lbmol are dimensionally and numerically equivalent (mass unit and mole-count unit scale together).PoundPerMole (lb/gmol) should remain unchanged for backward compatibility; it's simply a differently-scoped unit than what a pound-mole based unit would represent.
Is your feature request related to a problem? Please describe.
MolarMass.PoundPerMoledoes not represent lb/lbmol (pound-mass per pound-mole), which is the unit typically meant when working in the traditional FPS (English Engineering) unit system. Instead,PoundPerMolebehaves as lb/gmol (pound-mass per gram-mole).This becomes apparent when converting between
PoundPerMoleandKilogramPerKilomole:kg/kmolandlb/lbmolare numerically identical — both express mass per mole where the mass unit and the mole unit are drawn from the same "family" (SI mass + SI mole count in one case, US/Imperial mass + US/Imperial mole count in the other). BecausePoundPerMoleis implemented as lb/gmol rather than lb/lbmol, that expected 1:1 relationship doesn't hold, and any conversion viaPoundPerMoleproduces a value off by the gram-to-pound conversion factor (453.59237). This is easy to miss and produces silently incorrect results in engineering calculations that assumePoundPerMolecorresponds to the pound-mole convention.Describe the solution you'd like
Add a new unit,
PoundPerPoundmole(lb/lbmol), toMolarMass, with a conversion factor of exactly 1.0 relative toKilogramPerKilomole.This would let users working in the traditional FPS system convert correctly between molar mass values without manually applying a correction factor for gc or mole-basis mismatches, consistent with how
UnitsNetalready resolves other FPS/SI mismatches internally through SI base units.Describe alternatives you've considered
PoundPerMolevalues — workable, but error-prone and easy to forget or apply in the wrong direction.PoundPerMoleitself to mean lb/lbmol — not backward compatible, since it would silently change the meaning/value of an existing unit for any consumers already relying on the current (lb/gmol) behavior.Adding
PoundPerPoundmoleas a new, explicitly named unit avoids breaking existing behavior while giving FPS-system users a correct, unambiguous unit to use.Additional context
KilogramPerKilomoleand the proposedPoundPerPoundmoleshould be a straight 1:1 conversion, since kg/kmol and lb/lbmol are dimensionally and numerically equivalent (mass unit and mole-count unit scale together).PoundPerMole(lb/gmol) should remain unchanged for backward compatibility; it's simply a differently-scoped unit than what a pound-mole based unit would represent.