[Halld-offline] GEANT3 particle IDs

[Richard Jones]

David and all,

I support David's proposal.  We should not re-use particle codes that have already been assigned in G3.  G4 is built to work with the more robust and extensible PDG particle naming mechanism, but it also understands G3 numbers, so going to G4 does not immediately require us to abandon the existing particle id table that is part of the HDDM definition.  It makes sense to get this straightened out now.

-Richard Jones

On 4/5/2013 11:33 AM, David Lawrence wrote:
> Hi Offliners,
>
>    I was just trying to add Pb208 to the list of particles defined in
> particleType.h and ran into an issue. Several particle types have
> been added that extend beyond the original GEANT3 particle ID
> values (which is good). However, when I looked up the GEANT3
> list at the link below, I see there are a number of other particles
> defined, some of which conflict with the new ones added to
> particleType.h. For example, all of the KStar particles with id
> values 65-68 conflict with B10, B11, C12, and N14 in the
> GEANT list.
>
> http://wwwasdoc.web.cern.ch/wwwasdoc/geant/node72.html
>
> Since we don't currently define any of the heavier elements,
> this doesn't present a conflict at the moment. However, it might
> be nice not to have this discrepancy between what we define
> for these values and what the web documentation says. Since all
> code should work off of the enum and NOT have any of these
> hard-coded, then changing the values in particleType for
> should not affect anything.
>
> In a nutshell, I'd like to:
>
> - Change the currently defined particle IDs in particleType.h
>      that have values of 65 or greater to be 100 greater than
>      they are now (e.g. KStar_892_0 will change from being
>      65 to being 165, ...)
>
> - All other values will stay as they are since they are already
>      in alignment with the GEANT documentation
>
> This potentially could affect anyone processing files that
> have these particles defined with the old numbers if
> they try reading them with new code.
>
> It could also break anyone's code that uses hard-coded
> numbers for these (in which case I would feel really,
> really bad ... OK not really. If that happens you kind of
> deserve what you get).
>
> Sorry for the long winded explanation, but I wanted to give
> everyone a chance to object before I checked in this change.
>
> -David
>
>
>
> _______________________________________________
> Halld-offline mailing list
> Halld-offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-offline


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3232 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20130406/f567f475/attachment.p7s>