Implement a script to check instance catalog inputs from CatSim against PhoSim output

[jchiang87]

This issue is in response to @drphilmarshall's comment at https://github.com/DarkEnergyScienceCollaboration/Twinkles/issues/323#issuecomment-249266179

The calexp exposure produced by processEimage.py copies the header keywords from the eimage to the PHDU. The attached file, v703312-fu_PHDU_header.txt, contains a dump of the primary header for an example visit.

@rbiswas4 I think this should have the info you need.

[rbiswas4]

@jchiang87 Going through the header, I find the following variables are there in the phosim instance catalog (in some form). I am not sure if variables have some different conventions yet (for example the SEED here might well be different from the SEED in the input, but I would not be surprised if PRA, PDEC are different through some kind of warping too.

Now, in order to get a better sense, I suggest that we run phosim (in the version we are using at SLAC on a single input catalog with the physics override plan that is part of the plan) . The validation branch in Twinkles now has a single phosim instance catalog . Can we try to generate the eimage for this? I am happy to try (on my slac accoun) if someone could direct me to what I should do or if someone started such a job that would be good too.

Also, do we want to check that we are correctly using the physics override file?

OBSID   =               703312 / Opsim observation ID   
TAI     =     60617.0927263889 / International Atomic Time scale                
MJD-OBS =     60617.0927263889 / Modified Julian date (also TAI)     
FILTNM  =                    0 / Filter (0=u, 1=g, 2=r, 3=i, 4=z, 5=y)          
SEED    =             89604830 / Random seed 
PRA     =    0.925184000470688 / Pointing RA (radians)                          
PDEC    =   -0.478899999846147 / Pointing Dec (radians)                         
RA_DEG  =           53.0091385 / Pointing RA (decimal degrees)                  
DEC_DEG =          -27.4389488 / Pointing Dec (decimal degrees) 
ROTANG  =           116.117689 / Rotation Angle (rotSkyPos) (degrees)  
SPIDANG =                   0. / Angle of Spider (rotTelPos)                    
ZENITH  =                   1. / Zenith Angle (degrees)                         
AZIMUTH =                   0. / Azimuthal Angle (degrees)  

Some Seeing value

SEE1    =             0.039087 / Seeing at 5000 angstrom (sigma) 
SEE2    =             0.031148 / Seeing at 5000 angstrom (sigma)
SEE3    =             0.037345 / Seeing at 5000 angstrom (sigma) 
``       

[rbiswas4]

Strange I am not finding this on github ...

Anyway I agree with this. We can have a truncated instance catalog in the repo too for this purpose, but, rather than replacing the full instance catalog with this, I would also like to keep the full instance catalog too for other integration tests.

Thanks, Rahul

On Thu, Oct 13, 2016 at 1:15 PM, James Chiang notifications@github.com wrote:

@rbiswas4 https://github.com/rbiswas4 I'll run phosim using that instance catalog, but I'd like to truncate the object list after the stars, since phosim will just run faster and I don't have to set up the spectra_files. If we are just interested in validating the input parameters, it might be worth truncating that instance catalog in the repo similarly and removing data/spectra_files.tgz.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DarkEnergyScienceCollaboration/Twinkles/issues/325#issuecomment-253625825, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLPjoMlly5Swl_l5Vhhf6KRmo4qmHYAks5qzpFRgaJpZM4KFfdV .

[jchiang87]

@rbiswas4 The run finished after ~14 hours. The eimage file is at SLAC here:

/nfs/farm/g/desc/u1/users/jchiang/desc_projects/phosim_test_run/output/R22_S11/lsst_e_230_f2_R22_S11_E000.fits.gz

For the record, the command I used was

/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/phoSim/3.5.3/phosim.py phosimCatalog_stars_only.dat \
-s R22_S11 -c/nfs/slac/g/ki/ki18/jchiang/DESC/Twinkles/Twinkles/workflows/PhoSim/twinkles_I_physics_override.txt \
-o /nfs/farm/g/desc/u1/users/jchiang/desc_projects/phosim_test_run/output/R22_S11 \
-w /nfs/farm/g/desc/u1/users/jchiang/desc_projects/phosim_test_run/work/R22_S11 \
--sed=/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v12_0/opt/lsst/sims_sed_library

[sethdigel]

This Confluence page has some comparisons between instance catalog and centroid file source positions for visits in Twinkles Run 3. The bottom line is that the shifts are small (amounting to a few pixels) and essentially the same in each of the visits, with no obvious dependence on, e.g., elevation angle or filter.

Here's a set of scatter plots and histograms defined on the Confluence page. They are based on the first 191 of the Run 3 visits.

[drphilmarshall]

Interesting! Any idea where this is coming from, @danielsf?

Talking with @SimonKrughoff: the astrometric registration starts from a WCS supplied by PhoSim, and so the astrometric tweak applied to this WCS by the DM code should contain the (-3, 3) pixel shift. It might be interesting to check this. However, the final WCS should come out consistent with the reference catalog from which the instance catalogs were made, since this is what the registration script uses. This means that the truth table that @jbkalmbach is making, out of the instance catalogs), should give accurate matches to the DM object positions.

[danielsf]

Off the top of my head: I don't know.

There are effects beyond refraction that PhoSim takes into account (e.g. pin cushion distortions due to the telescope's optics). These will vary based on an object's on-chip position. That could obscure the altitude dependence of refraction. Maybe if we re-generated these plots with individual points for every object in the 191 pointings, we might see something.

I am working on a PR (#392) that reads in an InstanceCatalog and its corresponding centroid file and attempts to validate the positions of each object using the CatSim code. Maybe running that script on a bunch of InstanceCatalog/centroid file pairs, we might see something.

[sethdigel]

The bottom line is that the simplest possible transformation between instance catalog and centroid file coordinates gets the source positions to line up to <~1" regardless of altitude and band. The phosim runs do have some effects turned off that look possibly relevant to the pixel coordinates of sources (Impurity Variation, Fringing, Dead Layer, Charge Sharing, Pixel Error, Contamination Mode, QE variation). I do not understand why the histograms of the residuals in xshift and yshift have a fairly wide range of shapes from visit to visit. I haven't looked yet at whether the residuals depend systematically on position in the CCD - that should not be hard to check.