[Clas12_software] JLab appointment

[Mac Mestayer]

Hello Johann;

I have attached a few old emails to document some of the
points I want to make.  The drift chamber geometry has
been coded up and is being used by gemc and also by ced,
I think.  The entire drift chamber geometry is based on
approximately 20 independent parameters.  These parameters
should be kept in the data-base.  The code uses these
parameters to define the 36 wire planes and the 112 wire
positions within each of the planes.  Note: so far this
does not include distortions or deviations from ideal,
but these will be added in direct analogy to what we do
in the present CLAS software.

I'm not sure if this is a formal service yet, but I do
include an email in which I specify the kind of services
a typical customer might want.

Note: the dc geometry is hierarchical: the chambers are
located relative to a torus coordinate system and the
torus is located relative to a hall coordinate system.
Anything else which is physically tied to the torus,
e.g. the Moller absorber, should also follow this
hierarchy.

Call or email me with questions.  As a note, I came up with
the original code which was corrected and improved by Yelena
Prok and implemented as a service by Vardan Gurjyan with
Maurizio Ungaro doing the implementation withing gemc and
Dave Heddle pulling it into ced.

 		- hey, good to hear about you position!
 				- Mac

"mestayer at jlab.org", (757)-269-7252

On Fri, 18 Feb 2011, Johann Goetz wrote:

> Hi Dennis and Mauri,
> I just talked with Latifa and I will shortly be an official JLab employee
> (50% of the time). The main project she wants me to focus on is the
> consolidation of the geometry information of CLAS12 and the associated
> interface (API). The first step is to determine what is out there. I will
> survey what parameters are being used for each subsystem -- probably by
> contacting the individuals in charge of design and/or construction. We'll
> see if I can collect enough information to make a report this coming Tuesday
> during the software meeting. At any rate, I have added this as part of the
> upcoming  agenda.
>
> I envision using the mysql database design from GlueX (Mark Ito and Dave
> Lawrence) for versioning and storage of the geometry parameters. I can then
> produce an API in C++ or Java (or Python?) which we can wrap in whatever
> language people want. The final step would be to expose the API as a CLARA
> service.
>
> That being said, could anyone from the clas12_software group comment on the
> aspects of geometry they are familiar with? I.e., who to talk to in order to
> get an understanding of where parameters are stored and/or associated
> algorithms for converting these to actual positions in the hall. Otherwise,
> I'll probably start by going through the TDR.
>
> Thank you,
> -- 
> Johann T. Goetz, PhD.
> jgoetz at ucla.edu
> Nefkens Group, UCLA Dept. of Physics & Astronomy
> Hall-B, Jefferson Lab, Newport News, VA
> Office: 757-269-5465 (CEBAF Center F-335)
> Mobile: 757-768-9999
>
-------------- next part --------------
From mestayer at jlab.org Wed Sep  2 09:56:09 2009
Date: Wed, 2 Sep 2009 09:56:08 -0400 (EDT)
From: Mac Mestayer <mestayer at jlab.org>
To: Yelena Prok <yprok at jlab.org>
Cc: Dave Heddle <heddle at jlab.org>, Vardan Gyurjyan <gurjyan at jlab.org>, Dennis Weygand <weygand at jlab.org>, Sebastien Procureur <procureu at jlab.org>, Maurizio Ungaro <ungaro at jlab.org>, clas_offline at jlab.org, clas12_software at jlab.org
Subject: CLAS12 geometry service

Hello Yelena;

I've been thinking about the data structures and methods
of tracking in general, and also specifically with regards
to geometry information.

First, I think it would be useful if we formally name and
describe a new coordinate system in which the new z-axis
lies in the sector mid-plane and is perpendicular to the
drift chamber wire planes (i.e. along a 25 deg. polar angle).
The new x-axis would also lie in the sector mid-plane.
We might call this the sector wire plane coordinate system.
In this coordinate system, the wire planes are defined by
a z-value only.

Here are a number of services I think the package should provide:
- given a point in the sector coordinate system, return a point
in the sector wire plane coordinate system
- return the nearest wire plane in the +z direction, as well as
the distance to that plane
- if the user also specifies a direction cosine in additon to the
space point, we could return the distance to the nearest plane along
that direction vector, as well as the point of intersection of the
line and plane
- we could also return the distance to the nearest two wires for the
point in the plane; perhaps both the distance as well as the distance
along x.

One of our customers would likely be a track-fitter, which might
like to swim a track to the nearest plane and determine the intersection
point on that plane, and then determine the nearest two wires (in the
plus and minus x-direction), and then determine the distance of closest
approach to the wires in question.  This operation would be repeated many
times, so it needs to be fast.

Another customer might be the graphics package from the event display
program, and that customer might have more requests.

Of course, we already have a gemc customer, that needs locations and
definition of wire plane pseudo-volumes.

Anyway, I wanted to start the dialog.  The associated objects might
be Wire and WirePlane, etc. for example.  First, I wanted to find out
what track fitters and track simulators need from the geometry service,
so I cc'd Sebastien and Dave and Maurizio and others.

Comments, anyone?			- Mac

"mestayer at jlab.org", (757)-269-7252

On Tue, 6 Oct 2009, Dennis Weygand wrote:

> Our meeting time today is 11:00 EST.
> No one suggested any agenda items, therefore:
> There is a CLAS12 Steering Committee meeting tomorrow, so let's
> discuss status of various projects.
>
> Also, as always, and status of the svn conversion.
>
> Dennis
>
> --
> Dennis Weygand
> weygand at jlab.org
> (757) 269-5926
>
>
>
> _______________________________________________
> Clas_offline mailing list
> Clas_offline at jlab.org
> https://mailman.jlab.org/mailman/listinfo/clas_offline
>

From gavalian at jlab.org Mon Dec  7 13:57:49 2009
Date: Mon, 07 Dec 2009 13:57:48 -0500
From: Gavalian <gavalian at jlab.org>
To: Mac Mestayer <mestayer at jlab.org>
Cc: yprok at jlab.org
Subject: Re: Geometry Standard Routines

Dear Mac,

I wrote it, and I checked it works fine, Yelena sent me the routines that
she was using I'm implementing some of her routines as well, and then I can
put it in clas12 repository for everyone to use if they desire. It is really
worth using a standard code for every package, will be easier to maintain !

Gagik.

Mac Mestayer wrote:
> Hello Gagik and Yelena;
> 
> I've been on travel, just back.
> Who wrote the package?
> 
>             - Mac
> 
> "mestayer at jlab.org", (757)-269-7252
> 
> On Thu, 19 Nov 2009, Gagik Gavalian wrote:
> 
> > Dear Mac and Yelena,
> > 
> > After today's discussion about having standardized package for geometry,
> > I just put together a library that does calculate intersects of lines
> > and planes. The package is not documented but the example included with
> > it is documented (cgeotests.exe), the whole source is located on jlab
> > CUE:
> > 
> > /u/home/gavalian/Clas12GeoPack
> > 
> > and can be built with scons, it builds the library and example.
> > I think this is what you had in mind ! Was I Right ?
> > 
> > I think development of standard tools for any geometry reconstruction is
> > essential for easiness of the code maintainers and for reducing number
> > of external libraries required to build CLAS code.
> > 
> > 
> > Gagik Gavalian
> > 
> > 


From mestayer at jlabs1.jlab.org Thu Dec 22 11:19:16 2005
Date: Thu, 22 Dec 2005 11:19:15 -0500 (EST)
From: Mac Mestayer <mestayer at jlabs1.jlab.org>
To: Maurik Holtrop <maurik.holtrop at unh.edu>
Cc: David Heddle <heddle at gmail.com>, clas12_software at jlab.org
Subject: Re: CLAS Geometry

Hello Maurik and Dave;

We keep records of position changes (for example, if we
remove and replace a drift chamber) in a geometry table
in our calibration data-base.
These position changes are relative to a nominal position which
is hard-coded.

I won't comment on the software implementation for CLAS12, but
I do think that the geometry should follow a hierarchical logical
structure which mirrors the physical situation.  For example,
we have a Hall Coordinate System which contains a Toroidal Coordinate
System which contains a Sector Coordinate System, etc.
All of the drift chambers are physically attached to the torus,
so if the torus moves we only have to change one item (its position
and orientation) to reproduce all of the chamber positions relative
to the beam line and target.

				regards, Mac

"mestayer at jlab.org", (757)-269-7252