Hi.
I can't tell if this last post was intended to be humorous or not. I'm
in the mood to have fun and take it seriously, so here goes.
avogadros_number molecules = 1 mole molecules
A mole is like dozen. It is a count of whatever it is you are counting.
How many things are in a dozen? 12. How many things are in a mole?
avogadros_number. So, working with dozens I have:
12 eggs = 1 dozen eggs
1 egg = (1 dozen eggs) / 12
To make a quantity analogous to avogadro_constant, let's make
twelve_constant = 12 / dozen. I can then rewrite my formula as:
12 eggs = 1 * twelve_constant * dozen eggs
If I rearrange, I can write
1 egg = twelve_constant * dozen / 12 egg
1 egg = (twelve_constant / twelve_constant) egg
The inverse of twelve_constant is not 1. It is dozen / 12.
Twelve_constant and avogadro_constant are conversion factors, not units.
They convert scales without converting units (unlike conversion factors
between feet and meters, and like conversion factors between grams and
kilograms).
It is incorrect to write molecule = 1/avogadro_constant. In addition,
avogadro_constant should never be used as a unit, either straight up or
as a reciprocal.
Grace and peace,
Jim
On 1/8/15 1:39 PM, Steve Emmerson wrote:
> Jonathan,
>
> avogadro_constant = 6.022...e23/mole
> molecule = 1/avogadro_constant => 6.022...e23 molecules =
> 6.022...e23 (mole/6.022...e23) = 1 mole
>
> Now if we could just get the people who want units of "photon",
> "enzyme", "giraffe", etc. to use units of "avogadro_constant-1" (which
> is understood by UDUNITS) then all would be well.
>
> Regards,
> Steve Emmerson
>
> On Thu, Jan 8, 2015 at 6:34 AM, Jonathan Gregory
> <j.m.gregory at reading.ac.uk <mailto:j.m.gregory at reading.ac.uk>> wrote:
>
> Dear Maarten and Steve
>
> > >> I think you meant to say that if a physical quantity has a
> different
> > >> dimensionality (not unit), then we have to give it a
> different name.
>
> Yes, that's right, I meant physical dimensionality. I said "unit"
> meaning
> "canonical unit". Sorry to be sloppy!
>
> If I'm not oversimplifying, the point is that mol of NO2 means the
> same as
> 6e23 (Avogadro number) of NO2 molecules. Maarten's argument
> implies that there
> is no need for mole as one of the basic SI units which can't be
> converted into
> other units, because instead mole could be defined as an alias for
> Avogadro's
> (dimensionless) number, like percent is defined as 0.01 by
> udunits. Then we
> would not need different standard_names referring to number of
> molecules or
> to moles.
>
> I think this makes physical sense but it would not be consistent
> with SI. In
> SI, Avogadro's number is not dimensionless; it is 6e23 mole-1. It
> would not
> be consistent with SI to allow mole to be interconvertible with
> dimensionless
> numbers. I suppose that udunits would like to be consistent with
> SI. If so,
> we cannot do this.
>
> I think I'm repeating myself so I must have missed the point
> still. Maarten
> suggests that molecule should be defined to mean 1/Avogadro. Why
> reciprocal?
> Defining molecule=Avogadro I think would be confusing. If a
> quantity is said
> to be 1 molecule m-2, I don't think that means 1 mole m-2.
>
> Best wishes
>
> Jonathan
>
>
> ----- Forwarded message from Steve Emmerson <emmerson at ucar.edu
> <mailto:emmerson at ucar.edu>> -----
>
> > Date: Wed, 7 Jan 2015 10:37:58 -0700
> > From: Steve Emmerson <emmerson at ucar.edu <mailto:emmerson at ucar.edu>>
> > To: Maarten Sneep <maarten.sneep at knmi.nl
> <mailto:maarten.sneep at knmi.nl>>
> > CC: CF Metadata Mail List <cf-metadata at cgd.ucar.edu
> <mailto:cf-metadata at cgd.ucar.edu>>
> > Subject: Re: [CF-metadata] New UDUnits units for information:
> "byte" and
> > "octet"
> >
> > Maarten,
> >
> > I think I understand. You're fortunate in being
> "grandfathered-in", so to
> > speak.
> >
> > I just don't want to go down the road of adding support for all
> kinds of
> > different entities. I'm a bit sensitive in that regard. :-)
> >
> > Regards,
> > Steve Emmerson
> >
> > On Wed, Jan 7, 2015 at 10:31 AM, Maarten Sneep
> <maarten.sneep at knmi.nl <mailto:maarten.sneep at knmi.nl>>
> > wrote:
> >
> > > On 07-01-15 17:10, Steve Emmerson wrote:
> > >
> > >> Jonathan,
> > >>
> > >> I think you meant to say that if a physical quantity has a
> different
> > >> dimensionality (not unit), then we have to give it a
> different name.
> > >>
> > >> In my opinion, what's needed in this case is a package that
> understands
> > >> co-ordinate transformations -- in order to convert, for
> example, values
> > >> in units of "1e15/cm2" to values in units of "mol/m2". This
> is a rather
> > >> simple example and Maarten makes a good (though not yet
> convincing to
> > >> me) argument for simply modifying the UDUNITS database. One
> can imagine,
> > >> however, more complicated cases in which simple unit
> conversions are not
> > >> possible (e.g., converting between altitude and pressure). Such a
> > >> package would be easily capable of handling Maarten's conversion.
> > >>
> > >
> > > The only argument I'm making is that 'molecules' is available
> as a unit
> > > equivalent to 'avogadros_number-1' (which is the case with the
> current
> > > release of UDUnits). People who use 1/cm2 when they
> (implicitly) mean
> > > molecules/cm2 get what they deserve IMHO.
> > >
> > > As soon as you have molecules/cm2, then UDUnits can handle the
> conversion
> > > as is. For other densities, say an aerosol particle count, the
> conversion
> > > to mol is never needed, and number densities are fine (and a
> look at the
> > > standard_names will confirm this).
> > >
> > > So right now I'm not asking anything, as the most important
> scaled alias
> > > for 'mol' is available. This will ease the transition to
> mol/m2 quite
> > > significantly. It would be good to help the transition from
> photons to mol
> > > (photons) as well, which was a request that started this whole
> discussion
> > > in the first place.
> > >
> > > Does this make the argument clearer?
> > >
> > > Best,
> > >
> > > Maarten Sneep
> > > --
> > > KNMI
> > > T: 030 2206747
> > > E: maarten.sneep at knmi.nl <mailto:maarten.sneep at knmi.nl>
> > > R: A2.14
> > >
> > > _______________________________________________
> > > CF-metadata mailing list
> > > CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> > > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> > >
>
> > _______________________________________________
> > CF-metadata mailing list
> > CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> ----- End forwarded message -----
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu <mailto:CF-metadata at cgd.ucar.edu>
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org
o: +1 828 271 4900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150108/5344b336/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ibfcicaa.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150108/5344b336/attachment-0001.png>
Received on Thu Jan 08 2015 - 14:51:04 GMT
