[PIPE2D-618] Process SM1 stability data Created: 22/Jul/20 Updated: 05/Jan/21 Resolved: 25/Sep/20 |
|
| Status: | Done |
| Project: | DRP 2-D Pipeline |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Normal |
| Reporter: | hassan | Assignee: | price |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Story Points: | 10 | ||||||||
| Sprint: | 2DDRP-2021 A | ||||||||
| Reviewers: | sogo.mineo | ||||||||
| Description |
|
Data have been acquired from SM1 at Subaru for determining the stability of the wavelength solution: See the SM1 logbook https://people.lam.fr/madec.fabrice/pfs/logbook_opdb_visit_sm1_subaru.html for visit details (look for name='stabilityTest'). Please perform a complete processing of bias, dark, quartz and arc data, listed under the name 'stabilityTest' using the 2D DRP. Process as far as reduceArc.py. So we should for each arc exposure, have the corresponding wavelength solution and detectorMap. In addition, the visit numbers processed should be sent to sogo.mineo at NOAJ so that he can look into updating his YAML mechanism to extract those visits from the opDB. Note: the actual analysis of the wavelength solution to characterize instrument breathing modes would be done later and will be the subject of a separate ticket. |
| Comments |
| Comment by price [ 23/Jul/20 ] |
price@price-laptop:~/pfs/pipe2d-618 $ sqlite3 obslog.sqlite3 sqlite> .mode csv sqlite> .import PIPE2D-618.csv obslog sqlite> .schema CREATE TABLE obslog( "cmd_str" TEXT, "pfs_visit_id" TEXT, "visit_set_id" TEXT, "exp_type" TEXT, "time_exp_start" TEXT, "notes" TEXT, "data_flag" TEXT, "comments" TEXT, "name" TEXT, "status" TEXT, "sequence_type" TEXT, "sps_module_id" TEXT, "arm" TEXT, "sps_camera_id" TEXT ); sqlite> select count(*) from obslog; 2596 sqlite> select min(pfs_visit_id), max(pfs_visit_id) from obslog; 18218,19555 Need to: * Generate suitable bias (18218..18227), dark (18188..18202), flat (17839..17982). * Bootstrap a detectorMap (flat: 18231, arc: 18232) * For each set: + Process flats as a fiberTrace + Process each arc independently (lsst-scipipe) pprice@tiger2-sumire:/tigress/pprice/pipe2d-618 $ generateCommands.py /projects/HSC/PFS/Subaru/ --calib /projects/HSC/PFS/Subaru/CALIB-price --rerun price/pipe2d-618 --blocks=pipe2d_618 -j 20 pipe2d-618.yaml calibs.sh (lsst-scipipe) pprice@tiger2-sumire:/tigress/pprice/pipe2d-618 $ ./calibs.sh Bootstrap r: bootstrap INFO: Median difference from detectorMap: -1.251848,-1.112205 pixels bootstrap INFO: Fit 116/141 points, rms: x=0.713381 y=0.189416 total=0.458008 pixels bootstrap INFO: Updating detectorMap... bootstrap INFO: Median difference from detectorMap: 0.685743,-1.230428 pixels bootstrap INFO: Fit 77/96 points, rms: x=0.349973 y=0.116337 total=0.121325 pixels Bootstrap b: bootstrap INFO: Median difference from detectorMap: 0.244493,-0.289952 pixels bootstrap INFO: Fit 8/12 points, rms: x=0.088476 y=0.142863 total=0.089313 pixels bootstrap INFO: Updating detectorMap... bootstrap INFO: Median difference from detectorMap: 1.236342,-0.364347 pixels bootstrap INFO: Fit 7/7 points, rms: x=0.258951 y=0.009806 total=0.178473 pixels generateCommands isn't going to work for the main processing, since we want to run reduceArc on each arc individually (to detect any short timescale motion). --> fiberTrace.sh (lsst-scipipe) pprice@tiger2-sumire:/tigress/pprice/pipe2d-618 $ ingestPfsCalibs.py /projects/HSC/PFS/Subaru --output=/projects/HSC/PFS/Subaru/CALIB-price --validity=1800 --doraise --mode=copy --config clobber=True register.ignore=True -- /projects/HSC/PFS/Subaru/rerun/price/pipe2d-618/fiberTrace/FIBERTRACE/*.fits The problem now is that the butler doesn't recognise visit0 (can only have a single fiberTrace per day). So we'll hack the calibRegistry when we want to turn the fiberTrace over. --> arcs.sh |
| Comment by price [ 23/Jul/20 ] |
|
Data is in /projects/HSC/PFS/Subaru/rerun/price/pipe2d-618/arc. |
| Comment by hassan [ 03/Aug/20 ] |
|
sogo.mineo: Can you look at Paul's YAML file and related scripts please? Does this help in your work in extracting information from the opDB for your DRP processing framework? (PIPE2D-423 and related tickets) |
| Comment by sogo.mineo [ 04/Aug/20 ] |
|
The yaml file declares that bias is made from "visit=18218..18227", but these are not the only bias exposures in obslog. What is the logic behind the choice of "visit=18218..18227" among others? |
| Comment by price [ 04/Aug/20 ] |
|
I wanted a single bias for the whole dataset (my job wasn't to examine the biases for changes, just the arcs) to avoid annoyances from having to modify the calib registry (like I had to for the fiberTraces). That set of biases is close to the dark, which is probably why I preferred it over other sets. |
| Comment by sogo.mineo [ 04/Aug/20 ] |
|
|
| Comment by sogo.mineo [ 05/Aug/20 ] |
|
I think this work is OK – Tanaka-san told me that it is not my task to decide which exposures to use. Sorry for my misunderstanding. |