<div dir="auto">To avoid confusion: reconstruction and GEMC use the SAME geometry provided by Geo2.<div dir="auto"><div dir="auto">Andrey.</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 13, 2018, 04:28 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,<br>
<br>
Yes and that package should be written in C++ for obvious reasons.<br>
<br>
On Thu, Jul 12, 2018 at 02:45:33PM -0400, David Heddle wrote:<br>
>Hi Whitney,<br>
>Yes there has been general agreement since time 0 that we should have a<br>
>common geometry. Why it diverged is water under the bridge. I'm confident<br>
>we will converge back to one package.<br>
><br>
>David<br>
><br>
>On Thu, Jul 12, 2018, 11:46 AM Whitney R. Armstrong <<a href="mailto:warmstrong@anl.gov" target="_blank" rel="noreferrer">warmstrong@anl.gov</a>><br>
>wrote:<br>
><br>
>> 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<br>
>> 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<br>
>> 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<br>
>> should<br>
>> >> modify the whole JCSG package or, at this point, should have just<br>
>> 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<br>
>> methods of<br>
>> >>> Geo1 for planes, 3D, intersections of 3D objects, rotations, etc. all<br>
>> 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<br>
>> 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<br>
>> of<br>
>> >>> Geo1. I don't even know if that is possible, and I'm not going to<br>
>> check,<br>
>> >>> because while I like a good hack as much as the next person, using one<br>
>> 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<br>
>> 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<br>
>> geo<br>
>> >>> packages that have not been "unioned" into one, the simplest approach<br>
>> is to<br>
>> >>> write *another* (That only I'll use) to minimize my dependence on<br>
>> either.<br>
>> >>><br>
>> >>> This is *foo-bar*. A major accomplishment of the software group when<br>
>> 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<br>
>> 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>
>><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>