[lsst-dm-stack-users] Pipeline and sensor routines

[Chris Walter]

Hi Andy,

Great thanks. I do have access to the document archive now so I will take a look. As you know, I'm working towards being able to compare with the sensor test data which is why I want to be able work in sensor coordinates.

-Chris

On Aug 7, 2013, at 5:18 PM, "Rasmussen, Andrew Peter" <arasmus at slac.stanford.edu> wrote:

> Hi Chris,
> 
> on your second item, there is also a "focal plane configuration database" described in docs 7822 & 12765, with tables containing transformation prescriptions between the various amplifier/readout order systems and the CCS (camera coordinate system, not camera control system). The idea was to have a place to record how the actual focal plane fits together according to its intrinsic modularity/hierarchy, and how to transmit assembly time bookkeeping information for the focal plane's 3 dimensions. The current focal plane model is v0.2, and is contained in the tar file doc-12766.
> 
> I honestly haven't compared the information carried in afw.cameraGeom against what's in FPModv0.2, and am not sure how the afw.cameraGeom classes are populated. What I do know/assume is that PhoSim uses the 3D information of the current FPMod package in the camera coordinate system  to determine which pixels to populate during image formation. Those transformation offsets & matrices I think are copied into the phosim produced images, but may be removed DM downstream (?) in preference for afw.cameraGeom classes for clarity.
> 
> Integration clock phase dependence on the pixel grid registration will also be tracked and updated - so that pixel registration errors across the sensor mid-line will be understood before they are discovered. we already saw a larger physical midline gap (or phasing error) in the STA1900A model layout, which would suggest that a single grid is insufficient to describe more than 8 amplifiers at a time for those sensors.
> 
> If you do get into the nitty-gritty of transforming between systems you're likely to encounter differences between "first pixel" definitions which may be discrepant by either 1.5, 0.5 or 1 pixels. Also, the CCS x-axis (which is parallel to the horizon for zero camera rotation), is also nominally parallel to the parallel transfer direction (in all focal plane sensors but those carried by two of the corner rafts). We should be able to avoid confusion by keeping coordinates distinct from addresses. Also, the address of the first physical pixel read will also depend on specific details of the clock timing. This detail can't be ignored on the configuration database/phosim side, but probably simply comes out in the wash on the DM side.
> 
> Let me know if you have access to the document archive, and if not, whether you'd like a copy of these tables. I think they're a couple hundred Mb in size, which works out to about 0.1 byte per pixel for the surface height maps. The coordinate transformation prescriptions take up less space, of course. They're provided in *.h, binary fits table and excel spreadsheet forms for convenience.
> 
> andy
> 
> On Aug 7, 2013, at 11:55 AM, Chris Walter <chris.walter at duke.edu> wrote:
> 
>> Dear All,
>> 
>> After following this advice from Jim in another message to someone else on the list:
>> 
>>> As I said before, the documentation isn't great, but you'd be better off looking at the bin directory of the pipe_tasks package, rather than what's in pipe_base, and then following those to the docstrings of the Task classes they invoke (in pipe_tasks/python/...).
>> 
>> I think I now have an OK understanding of how the abstract base CmdLineTask and processImage classes etc are put together to make a commandline task like processCcd etc.  I have two quick questions I'm a bit unclear on:
>> 
>> - In trying to understand the software I read the two-year old "Scientists guide to the LSST applications software".  In that document all of the pipeline tasks are described through using a clipboard and running with "runStage" etc.  I still see that code in lsst::pex::harness.  Is that code used in a different context, an alternative way of handling things, or is it now deprecated?
>> 
>> - Before I write them myself I wanted to check that something like this doesn't already exist: I would like routines to determine, based on the pixel I am in etc, where I am physically located on a sensor chip (in mm or something in the reference frame of the sensor) along with constants describing the dimensions of the chip and possibly routines determining offsets from physical characteristics (like an edge).  Does anything like this already exist for the different camera descriptions?
>> 
>> Thanks for all the help,
>> 
>> -Chris
>> 
>> 
>> _______________________________________________
>> lsst-dm-stack-users mailing list
>> lsst-dm-stack-users at lsstcorp.org
>> http://listserv.lsstcorp.org/mailman/listinfo/lsst-dm-stack-users