[Clas12_software] A rant revistited

Thu Jul 12 15:28:15 EDT 2018

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