[Clas12_software] A rant revistited

[David Heddle]

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>
>>
>> --
>>
>> *David P. Heddle, Ph.D.Professor of Physics*
>> *MS APCS Graduate Program Coordinator*
>>
>> * Christopher Newport University Newport News, VA 23606*
>>
>> *757.594.8434*
>>
>> _______________________________________________
>> Clas12_software mailing list
>> Clas12_software at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/clas12_software
>>
>
>

-- 

*David P. Heddle, Ph.D.Professor of Physics*
*MS APCS Graduate Program Coordinator*

* Christopher Newport University Newport News, VA 23606*

*757.594.8434*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/clas12_software/attachments/20180712/4a4db50a/attachment-0002.html>