[Clas12_software] A rant revistited

[Whitney R. Armstrong]

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