[Clas12_software] A rant revistited

[David Heddle]

Hi Whitney,
Yes there has been general agreement since time 0 that we should have a
common geometry. Why it diverged is water under the bridge. I'm confident
we will converge back to one package.

David

On Thu, Jul 12, 2018, 11:46 AM Whitney R. Armstrong <warmstrong at anl.gov>
wrote:

> Hi David and Andrey,
>
> I have some comments:
>
> On Thu, Jul 12, 2018 at 06:00:10AM -0400, David Heddle wrote:
> >So the problem, in nutshell, is that
> >in the present situation we can never be sure that GEMC, the
> >reconstruction, FastMC and ced have the same wire positions (and in fact
> >they don't). And that's just one detector.
>
> I made proposal 3 years ago to address this problem (see slide 10
> titled "Consistent Geometries: The elephant in the room"
> https://userweb.jlab.org/~whit/clas12/talks/digitizer_7-23-2015.pdf).
> At the time it was made clear that an alternative "solution" was being
> actively pursued (coatjava).
>
> >And while it might be possible (I don't think so, without some mods to
> >Geo1) to transform the DC hexagonal tubes of Geo1 so that the center line
> >agrees with the wire positions from Geo2, to me this is at most a stop-gap
> >solution. The problem with such hacks is they tend to be forgotten and
> >linger in the background like a time bomb.
>
> IMO, the problem in the java code between Geo1 and Geo2 is easily
> addressed (as you even point out). But this fails to address the
> underlying problem, which is a lack of consistent or a single source for
> geometry information.
>
> Clearly you don't think GEMC has the same geometry as found in either
> geo1 or geo2. I have my own ideas on fixing this, but I am interested to
> hear what you think is a reasonable solution?
>
> Cheers,
> Whit
>
>
> On Thu, Jul 12, 2018 at 06:00:10AM -0400, David Heddle wrote:
> >Hi Andrey,
> >
> >I don't think the reconstruction package does what you say, because I
> think
> >reconstruction uses only uses the wire endpoints. The DC wires in what I
> >called Geo1 are actually 3D hexagonal "tubes" with a center line
> >corresponding to the sense wire. Certainly ced makes great use of this 3D
> >object (and the attendant transformations available to apply to the
> >object), and FastMC uses it as well. So the problem, in nutshell, is that
> >in the present situation we can never be sure that GEMC, the
> >reconstruction, FastMC and ced have the same wire positions (and in fact
> >they don't). And that's just one detector.
> >
> >And while it might be possible (I don't think so, without some mods to
> >Geo1) to transform the DC hexagonal tubes of Geo1 so that the center line
> >agrees with the wire positions from Geo2, to me this is at most a stop-gap
> >solution. The problem with such hacks is they tend to be forgotten and
> >linger in the background like a time bomb.
> >
> >Just to be clear I am not claiming one package is better. I'm happy to use
> >either. I am claiming it is a mistake for us to have two packages, even
> >if/when the current situation is fixed so that they both give the same
> >numbers. Different numbers only shines a spotlight on the underlying
> >problem. If it was necessary to start a new package, it should first have
> >reproduced and then deprecated the older geometry package. What has
> >happened-- two code bases with similar goals and purposes but giving
> >different numbers was...predictable.
> >dph
> >
> >On Thu, Jul 12, 2018 at 1:55 AM Andrey Kim <kenjo at jlab.org> wrote:
> >
> >> Dear David,
> >> Just to clarify the situation, the reason why we have duplicate
> >> functionality and second geometry package is because we needed the
> ability
> >> to load CAD files in COATJAVA and GEMC. In order to do that we used
> >> existing project JSCG from github that came with its own classes, that
> >> provide duplicate functionality. So in order to get rid of them, one
> should
> >> modify the whole JCSG package or, at this point, should have just
> written
> >> his own CAD reading code. I think the reconstruction uses the first
> >> solution that you mentioned: get raw numbers from Geo2 and put them into
> >> Geo1 objects.
> >> Andrey.
> >>
> >>
> >>
> >> On Wed, Jul 11, 2018 at 10:34 PM, David Heddle <david.heddle at cnu.edu>
> >> wrote:
> >>
> >>> <RANT>
> >>>
> >>> To use the latest wire positions (with db variation)  I need to use a
> >>> geometry package  (call it Geo2) different from the one I've been using
> >>> (call it Geo1). However throughout my code I use the classes and
> methods of
> >>> Geo1 for planes, 3D, intersections of 3D objects, rotations, etc. all
> of
> >>> which are incompatible with the objects from Geo2.
> >>>
> >>> If it were only a question of wire end points there would be no
> problem.
> >>> It is a question of the functionality of the packages, which is not
> >>> identical.
> >>>
> >>> Here are my (unsavory) choices:
> >>>
> >>> 1) Use the wire positions from Geo2 and force them on the wire objects
> of
> >>> Geo1. I don't even know if that is possible, and I'm not going to
> check,
> >>> because while I like a good hack as much as the next person, using one
> geo
> >>> package to overwrite the values of another exceeds my hack threshold.
> >>>
> >>> 2) Switch completely to Geo2, and when I encounter needed functionality
> >>> not present I can request mods and wait.
> >>>
> >>> 3) (The choice I am inclined to make at this point) Use Geo2 for the
> wire
> >>> endpoints and other basic geometry and write my own
> >>> likely-fraught-with-errors  level geo package to reproduce the
> >>> functionality I used in Geo1--probably based on the apache math library
> >>> geometry package. That's right--because I am faced with two different
> geo
> >>> packages that have not been "unioned" into one, the simplest approach
> is to
> >>> write *another* (That only I'll use) to minimize my dependence on
> either.
> >>>
> >>> This is *foo-bar*. A major accomplishment of the software group when
> the
> >>> "eeks" (Veron*ique* and Gag*ik*)  took over was the institution of the
> >>> common tools library. Two (now 2.5 after I'm done) geometry packages
> is a
> >>> gross violation of the beloved common tools principle.
> >>>
> >>> This should not have happened.
> >>>
> >>> </RANT>
> >>>
>
> >_______________________________________________
> >Clas12_software mailing list
> >Clas12_software at jlab.org
> >https://mailman.jlab.org/mailman/listinfo/clas12_software
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/clas12_software/attachments/20180712/e0f42f71/attachment-0002.html>