Electronic orientation

[karl krughoff]

The current version of phosim assumes the serial register to be along the long axis of the segment. This is counter to the current chip design. The serial register is along the short axis in the physical devices. Things are further confused by the fact that the per-amp FITS files are oriented with the short axis along the x-axis. This is what I would expect if the serial register was along the short axis of the segment.

Jim Chiang noticed this back in August: https://project.lsst.org/meetings/lsst2016/sites/lsst.org.meetings.lsst2016/files/lsst_camera_readout_jchiang.pdf.

Can we get the orientation to be self consistent with the persisted files and with the sensor design? At the same time, I would like to request that the number of overscans is increased to 10 in both there serial and parallel direction.

If you'd like, I can probably provide a PR.

[John Peterson]

Simon & Jim-

We can fix this, but i am immediately confused by what you say. Why do you say phosim assumes the serial register is along the long axis? This wouldn’t be the case in any design, much less LSST. So is this a documentation error or a convention of what you see in the files or a header key word or what? I think the serial axis should be the short axis in the amplifier files. So in other words, i agree that the serial register is definitely the short axis, but i am wondering how are you concluding that phosim has this backwards?

john

[James Chiang]

Maybe there is some confusion caused by the Camera Coordinate System having the "x"-axis in the parallel direction, whereas the usual convention for CCDs is to have the x-axis aligned with the serial direction. See the labels for columns (c) and (d) of

https://bitbucket.org/phosim/phosim_release/src/2c80b15737b2a19beb845451b00fb5a68a15ea26/data/lsst/segmentation.txt?at=master&fileviewer=file-view-default

Just looking at the output amplifier files from phosim, the main problem I see is that the layout of the prescan and overscan regions doesn't match the Camera spec. Perhaps the most direct way to address this would be to provide headers from real camera data that specifies the pixel geometry so that the segmentation.txt file can be updated appropriately.

[John Peterson]

yeah, but the labels for columns in the segmentation file might just be wrong. ignore the pre/over scans for a second because those are trivial to fix.

i'm more worried about if there is a orientation issue. the amplifier files are in readout order, so at the point the have nothing to do with an x/y pixel geometry. see what i mean?

[karl krughoff]

@johnrpeterson intentionally or otherwise, the e2adc.cpp file treats the values in the segmentation file in the same sense as how they are labeled.

For example: this line reads the columns labelled as x low and x high into variables called outminx and outmaxx. This is true for the y variables as well.

Further, the serial pre/post scan regions are applied to the x values and the parallel pre/post scans are applied to the y values. See this and the following line.

This comment is where the array is transposed, after the extra regions are applied making them show up on the wrong axis in the file.

I believe that relabeling and re-assigning the values in the segmentation file would fix this, but if the pixel array were treated internally in the same orientation as it is read out, that would be less confusing.

[John Peterson]

but i think you are just saying the labels for the pre/over scans are wrong, right?

[karl krughoff]

That is not how I interpret it. The code explicitly assumes the serial register is along the x-axis. Given the design of the code, that's not a correct assumption. I think you could get around this problem by renaming the columns in the segmentation file, but I don't know how you solve it in general. I.e. if your sensors are oriented so the serial register is already along the x-axis, the renamed columns would be wrong.

[John Peterson]

yes, agreed. but can jim comment whether he thinks there is anything wrong for lsst devices other than the column labels/values of the pre/over scans?

[James Chiang]

I'll take a look at the amplifier files that are produced by the current release and will report back. I'll try to do that in the next day or so.

[James Chiang]

Hi Guys,

Sorry for taking so long to look at this, but I finally set aside some time this morning to look at the phosim amplifier files from our DC2 Run1.1p test run (using v3.7.8). I will restrict my observations to how the pixel data in the amplifier files appears with respect to what the Camera Control Software is producing currently from the test stands.

The good news is that that part I was worried most about looks ok, i.e., the pixels for all sixteen segments appear to be stored in consistent readout order, assuming we are simulating ITL devices. Since the output nodes for half of the segments in the e2v devices are on the other side of the segment, we'd need to check those files separately.

For the simulated ITL devices, there are two sets of issues:

1) The prescan and overscan geometries are incorrect:

• There are 6 rows of "prescan" pixels in the parallel direction. There should be zero.

• There is only one column of prescan pixels in the serial direction. There should nominally be 3 for the ITL devices.

• There are no overscan pixels in the serial direction. There should be at least 10.

• There are only 4 overscan pixels in the parallel direction. This is less crucial, but there should nominally be at least 10 here too.

These four issues are encapsulated by the header keywords describing the pixel geometries. For phosim, the relevant keywords are

NAXIS1  =                  510 / length of data axis 1
NAXIS2  =                 2010 / length of data axis 2
DATASEC = '[   2: 510,   7:2006]' / Data section of amplifier

Whereas for the FITS files being produced by the Camera team, they are

NAXIS1  =                  532
NAXIS2  =                 2020
DATASEC = '[4:512,1:2000]'

Note also that the Camera FITS files provide the DETSEC keyword which allows ds9 to construct a sensor-level mosaic from the amplifier images.

2) The segment/channel labels for the phosim amplifier files are swapped across the midline in the parallel direction. Here's a table showing the differences:

phosim     Camera team
  10           00
  11           01
  12           02
  13           03
  14           04
  15           05
  16           06
  17           07
  07           17
  06           16
  05           15
  04           14
  03           13
  02           12
  01           11
  00           10

[John Peterson]

ok, Jim, i'll send you a new segmentation file. try it out and make sure it fixes the two problems, and then i'll put it in a patch, if its fixed.

[James Chiang]

Thanks, John. FWIW, after discussing with Simon, I have to say that I am not totally sure that the channel label swap is a problem. So if you are convinced phosim currently has the correct labeling, let's go with that.

[James Chiang]

Hi John,

Could you email me the new file please? I'm worried that the formatting will be corrupted if I just try to extract the data from your post.

-Jim

[karl krughoff]

@johnrpeterson even better would be to attach the file to this issue instead of putting it in a comment.

[karl krughoff]

Updated segmentation file from John

[karl krughoff]

@johnrpeterson can you please delete your post so we don't have to scroll through all that to get to the end of the thread. I've attached the file to the issue.

[John Peterson]

ok, finally got them deleted. had to switch browsers to do it.

[James Chiang]

I ran phosim using the new segmentation.txt file that John provided and I confirm that it addresses the first issue I raised regarding the pixel geometries. So I'm good to go with this new file.

[John Peterson]

This is now formally released in v3.7.9.