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