<div dir="ltr">Hi Andrey,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>dph</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 12, 2018 at 1:55 AM Andrey Kim <<a href="mailto:kenjo@jlab.org">kenjo@jlab.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear David,<div>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.</div><div>Andrey.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 11, 2018 at 10:34 PM, David Heddle <span dir="ltr"><<a href="mailto:david.heddle@cnu.edu" target="_blank">david.heddle@cnu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><font color="#ff0000"><RANT></font><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Here are my (unsavory) choices:</div><div><br></div><div>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.</div><div><br></div><div>2) Switch completely to Geo2, and when I encounter needed functionality not present I can request mods and wait.</div><div><br></div><div>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 <i>another</i> (That only I'll use) to minimize my dependence on either.</div><div><br></div><div>This is <b>foo-bar</b>. A major accomplishment of the software group when the "eeks" (Veron<b>ique</b> and Gag<b>ik</b>)  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.</div><div><br></div><div>This should not have happened.</div><div><br></div><div><font color="#ff0000"></RANT></font><span class="m_6719633356301664322HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_6719633356301664322m_2934575143922066807gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><i>David P. Heddle, Ph.D.<br>Professor of Physics</i></div><div><i>MS APCS Graduate Program Coordinator</i></div><div dir="ltr"><i>
Christopher Newport University<br>
Newport News, VA 23606</i><div><i><br></i></div><div><i>757.594.8434</i></div></div></div></div></div></div></div></div></div></div></div></font></span></div></div>
<br>_______________________________________________<br>
Clas12_software mailing list<br>
<a href="mailto:Clas12_software@jlab.org" target="_blank">Clas12_software@jlab.org</a><br>
<a href="https://mailman.jlab.org/mailman/listinfo/clas12_software" rel="noreferrer" target="_blank">https://mailman.jlab.org/mailman/listinfo/clas12_software</a><br></blockquote></div><br></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><i>David P. Heddle, Ph.D.<br>Professor of Physics</i></div><div><i>MS APCS Graduate Program Coordinator</i></div><div dir="ltr"><i>
Christopher Newport University<br>
Newport News, VA 23606</i><div><i><br></i></div><div><i>757.594.8434</i></div></div></div></div></div></div></div></div></div></div></div>