[Clas12_software] A rant revistited

Fri Jul 13 05:25:53 EDT 2018

To avoid confusion: reconstruction and GEMC use the SAME geometry provided
by Geo2.
Andrey.

On Fri, Jul 13, 2018, 04:28 Whitney R. Armstrong <warmstrong at anl.gov> wrote:

> Hi David,
>
> Yes and that package should be written in C++ for obvious reasons.
>
> On Thu, Jul 12, 2018 at 02:45:33PM -0400, David Heddle wrote:
> >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
> >>
> >>
>
> >_______________________________________________
> >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/20180713/ea40a70a/attachment-0002.html>