Here's how the flux level changed with PSF radius for the setting hi-med, 396cm-1, slit6.
Also plotted is the theoretical captured flux of a certain slit width, in arcsec, for a seeing of 2.5"
More later
Friday, September 08, 2017
How extracted flux depends on parameters in pipeline
For optimal extraction the pipeline uses to parameters, the aperture radius and the PSF radius.
Here's how the flux level changed with PSF radius for the setting hi-med, 396cm-1, slit6.
Also plotted is the theoretical captured flux of a certain slit width, in arcsec, for a seeing of 2.5"
More later
Here's how the flux level changed with PSF radius for the setting hi-med, 396cm-1, slit6.
Also plotted is the theoretical captured flux of a certain slit width, in arcsec, for a seeing of 2.5"
More later
Absolute fluxes from the pipeline in HI-MED at 6um
We've observed the 1640cm-1 hi-med setting repeatedly.
Series 1:
AFGL 2591 520 Jy
Vega
Series 4
AFGL 2136, 174 Jy (150 Jy Indriolo)
NGC 7538 IRS1, 92 Jy (100 Jy Indriolo)
Mon R2 IRS3, 179 Jy (150 Jy Indriolo)
W3 IRS 5, 161 Jy, (200 Jy Indriolo)
Sirius, 349 Jy
Series 5
BN, 200 Jy, Indriolo
Sirius, 349 Jy
Series 6
Europa, --
Polaris, 55 Jy
Series 7
Europa
Polaris, 55 Jy
This post is supposed to bring together all these observations to see if we're getting reasonable absolute fluxes. I've put ISO and model fluxes beside the targets above.
Using the 3.1 factor for converting ergs s-1 cm-1 SR-1 (cm-1)-1 to Jy, here's the out of the box, continuum level fluxes of these objects.
However, the blackbody is known to be mis-represented because of the additional contribution of scattered light from the KRS5 lens. It was removed prior to series 6.
With the lens in the BB, the setpoint of 260K has a flux equivalent to 277 K, in the lab.
(add reference to blogger post)
When removed, the same setpoint has a flux equivalent to 272 K.
Since the pipeline assumes scaling to blackbody counts of a 260 K source, this acts to reduce the absolute flux values. For 277K that factor is 1.75. For 272K the factor is 1.5.
Absolute Fluxes from Pipeline
object mode slit series actualflux correctedpipeflux
AFGL2591 nod-on 4 1 520
AFGL2591 nod-off 4 series1
Series 1:
AFGL 2591 520 Jy
Vega
Series 4
AFGL 2136, 174 Jy (150 Jy Indriolo)
NGC 7538 IRS1, 92 Jy (100 Jy Indriolo)
Mon R2 IRS3, 179 Jy (150 Jy Indriolo)
W3 IRS 5, 161 Jy, (200 Jy Indriolo)
Sirius, 349 Jy
Series 5
BN, 200 Jy, Indriolo
Sirius, 349 Jy
Series 6
Europa, --
Polaris, 55 Jy
Series 7
Europa
Polaris, 55 Jy
This post is supposed to bring together all these observations to see if we're getting reasonable absolute fluxes. I've put ISO and model fluxes beside the targets above.
Using the 3.1 factor for converting ergs s-1 cm-1 SR-1 (cm-1)-1 to Jy, here's the out of the box, continuum level fluxes of these objects.
With the lens in the BB, the setpoint of 260K has a flux equivalent to 277 K, in the lab.
(add reference to blogger post)
When removed, the same setpoint has a flux equivalent to 272 K.
Since the pipeline assumes scaling to blackbody counts of a 260 K source, this acts to reduce the absolute flux values. For 277K that factor is 1.75. For 272K the factor is 1.5.
Absolute Fluxes from Pipeline
object mode slit series actualflux correctedpipeflux
AFGL2591 nod-on 4 1 520
AFGL2591 nod-off 4 series1
Wednesday, September 06, 2017
Converting from ergs s-1 cm-1 SR-1 (cm-1)-1 to Jy
The pipeline puts the flux into flux density units as a default [ergs s-1 cm-1 SR-1 (cm-1)-1. To get it to Jy for point sources, apply this conversion
flux_Jy = flux_pipeline x (pixelscale_in_arcsec)^2 x 78.4023.
For pixscale = 0.2", this is
flux_Jy = 3.136 x flux_pipeline
The 78.4 comes from converting sq arcsec to steradians (pi /180/3600)^2 and multiplying by 1x10^21/ 2.99792458x10^8 m/s)
I can't say I understand it.
flux_Jy = flux_pipeline x (pixelscale_in_arcsec)^2 x 78.4023.
For pixscale = 0.2", this is
flux_Jy = 3.136 x flux_pipeline
The 78.4 comes from converting sq arcsec to steradians (pi /180/3600)^2 and multiplying by 1x10^21/ 2.99792458x10^8 m/s)
I can't say I understand it.
Wednesday, July 12, 2017
CD32 Instrument Configuration
Filter wheel:
F1 OPEN
F1 OPEN
F2 BBP5500 + MgF2
F3 18a+ZnSe
F4 Reading 6.2um + MgF2
F5 N07053 +CaF2
F3 18a+ZnSe
F4 Reading 6.2um + MgF2
F5 N07053 +CaF2
F6 N07466+CaF2
F7 BP14100
F8 Soifer
F9 OCLI 'O' + CaF2 (removed CO2 filter and mailed to TG)
F10 Tilted Reading 6.2um (removed N07904+CaF2)
F7 BP14100
F8 Soifer
F9 OCLI 'O' + CaF2 (removed CO2 filter and mailed to TG)
F10 Tilted Reading 6.2um (removed N07904+CaF2)
F11 N04679+MgF2 (removed OCLI 'S'+BaF2)
F12 Reading 18um (removed N05340+MgF2)
F12 Reading 18um (removed N05340+MgF2)
Decker wheel filters:
D1: BP13465 + BaF2
D2: BP6000 + MgF2
D3: BP6600 + MgF2
D4: BBP5030 + MgF2 (moved N04679 +MgF2 to FW)
D1: BP13465 + BaF2
D2: BP6000 + MgF2
D3: BP6600 + MgF2
D4: BBP5030 + MgF2 (moved N04679 +MgF2 to FW)
Lens wheel:
L1: mirror
L2: 1% neutral density filter
L3: 25mm KRS5 lens
L4: OPEN
L5: MgF2 blocker
L6: 38mm ZnSe lens (removed damaged 38mm KRS5 lens)
Friday, May 12, 2017
SaltLick Update and Data Summary
Folks,
FYI I've upgraded the SaltLick server in the lab. It now contains three disk drives as a single 4TB redundant (RAID5) volume. There is room to add one more drive, which would max out the storage at 6TB. We're presently sitting at 58% of capacity, so there's no imminent need to add that disk. I did go ahead and buy a complete set of replacement disks so that we're OK for future failures that might occur.
Now that there is room, I've consolidated the data from Everything EXES on dropbox with all the other lab data that isn't on the dropbox, so SaltLick is now (I believe) a comprehensive raw data set. I need to collect some of the reduced data still, and once that's done SaltLick will be a complete dataset.
Included below is a table summarizing the data that presently housed on SaltLick and on DB/EE/Data, in case you're wondering where to find something someday. This table is also stored at the root of SaltLick/raw, and I can update it as more data finds its way home. Please let me know if you see any errors that I've made.
<!--This file was converted to xhtml by LibreOffice - see http://cgit.freedesktop.org/libreoffice/core/tree/filter/source/xslt for the code.- no title specified
-->
FYI I've upgraded the SaltLick server in the lab. It now contains three disk drives as a single 4TB redundant (RAID5) volume. There is room to add one more drive, which would max out the storage at 6TB. We're presently sitting at 58% of capacity, so there's no imminent need to add that disk. I did go ahead and buy a complete set of replacement disks so that we're OK for future failures that might occur.
Now that there is room, I've consolidated the data from Everything EXES on dropbox with all the other lab data that isn't on the dropbox, so SaltLick is now (I believe) a comprehensive raw data set. I need to collect some of the reduced data still, and once that's done SaltLick will be a complete dataset.
Included below is a table summarizing the data that presently housed on SaltLick and on DB/EE/Data, in case you're wondering where to find something someday. This table is also stored at the root of SaltLick/raw, and I can update it as more data finds its way home. Please let me know if you see any errors that I've made.
<!--This file was converted to xhtml by LibreOffice - see http://cgit.freedesktop.org/libreoffice/core/tree/filter/source/xslt for the code.
| cooldown | SL_raw | SL_reduced | DBEE_data | date | |
| 1 | 1.7GB | -- | -- | Apr-Jul 09 | |
| 2 | -- | -- | -- | -- | |
| 3 | 2.2MB | -- | -- | Oct-Nov 09 | temp data only |
| 4 | 11GB | -- | -- | May-Jun 10 | |
| 5 | -- | -- | -- | -- | |
| 6 | -- | -- | -- | -- | |
| 7 | 1.3GB | -- | -- | Jul-Aug 10 | |
| 8 | 6.3GB | -- | -- | Aug-Sep 10 | |
| 9 | 23.4GB | 0.5MB | -- | Oct-Nov 10 | |
| 10 | 15.4GB | -- | -- | Nov-Dec10 | |
| 11 | 64GB | -- | -- | Jan 11 | IRTF |
| 12 | 142.8GB | -- | -- | Mar11–Dec12 | |
| 13 | 33.5GB | -- | -- | Feb-Aug 12 | |
| 14 | 43.7GB | -- | 15.8GB | Jan-May 13 | |
| 15 | 61.8GB | -- | 50MB | Jun-Aug 13 | |
| 16 | 90.9GB | -- | -- | Nov-Dec 13 | |
| 17 | 224GB | -- | 137.5GB | Apr-Oct 14 | Cyclops |
| 18 | 20.2GB | -- | 3.3GB | Oct-Dec 14 | |
| 19 | 7.3GB | -- | 1.6GB | Jan-Mar 15 | |
| 20 | -- | -- | -- | -- | |
| 21 | 190.8GB | 8.8GB | 199GB | Feb-Mar 15 | Wolverine |
| 22 | 114.8GB | 50.8GB | 79GB | Mar-Sep 15 | Storm |
| 23 | -- | -- | -- | -- | |
| 24 | 6.1GB | -- | 6.1GB | Feb-Apr 16 | |
| 25 | 157.1GB | 7.3GB | 157.1GB | Mar16 | Colossus |
| 26 | 6.9GB | -- | 6.9GB | Apr16 | |
| 27 | 31GB | -- | 31GB | Oct16 | |
| 28 | 12.3GB | -- | 12.3GB | Dec16 | |
| 29 | 186.8GB | 28.9GB | 186.8GB | Jan17 | Deadpool |
| 30 | 269.1GB | -- | 269.1GTB | Feb-Apr 17 | Kitty |
-->
Thursday, May 11, 2017
CD31 resolution tests
We took C2H2 Q branch spectra in himed and med modes with all slits and the pinhole. We also took rinsed cell spectra to go with them. Script and save files are in analysis/cd31/specfocus.
I used the pinholes to trace the path of dispersion and find the dispersion in wn/pix. I used a linear fit for wn/pix, although a quadratic would probably be <=3% better.
I used clickfit to fit along pixels and corrected for the fact that the slits didn't run along pixels later. This was a small effect.
For the high-med, I fit Q(9)-Q(15) and Q(15)-Q(19). For the med, I fit Q(10) through Q(23) along with R(0) and skipping Q(20) because of a hot band. As the slits got wider, the lower lines really blended together. In fact, no fits were good for slit 6.
In all cases, I fit many rows of each line and then took a median of all the fits that looked good for a particular line in order to calculate the resolving power in the bottom figures.
I used the pinholes to trace the path of dispersion and find the dispersion in wn/pix. I used a linear fit for wn/pix, although a quadratic would probably be <=3% better.
I used clickfit to fit along pixels and corrected for the fact that the slits didn't run along pixels later. This was a small effect.
For the high-med, I fit Q(9)-Q(15) and Q(15)-Q(19). For the med, I fit Q(10) through Q(23) along with R(0) and skipping Q(20) because of a hot band. As the slits got wider, the lower lines really blended together. In fact, no fits were good for slit 6.
In all cases, I fit many rows of each line and then took a median of all the fits that looked good for a particular line in order to calculate the resolving power in the bottom figures.
 |
| himed Q branch with slit 4 (rotated 90 degrees in IDL to work with clickfit) |
 |
| med Q branch with software rotate and only Q(10)-Q(23) (right to left) extracted |
 |
| himed resolving power as a function of x pixel. Each slit is different color. |
 |
| Medium mode resolving power as function of X pixel. Each slit is in different color. Predictions from ETC are horizontal lines with appropriate color. Note that Slit 6 was so broad that the fits didn't work. |
After finding that C2H2 med mode was ~85% of the prediction, which seems reasonable since we bias ourselves toward the high resolution, we looked at H2O at John Carr's 1838 cm-1 setting. The actually wn0 is a little different to provide good lines to fit.
Followed the same procedure with pinhole and all slits. The lines were present in the cell even when continuously pumping. Used an aluminum plate right in front of the window and adjusted the level in software to provide a good reference. Chose to divide rather than subtract.
Got resolving powers that were far below ETC prediction. We're going to look at more settings going toward longer wavelengths. Will check the ETC, too.
 |
| Resolving power for 1838 (nearJohn Carr's H2O setting) as a function of x pixel. Note that the line near x=850 was the brightest. The fits make me think maybe it was resolved by the narrowest slits. |
Friday, April 28, 2017
CD31 Instrument configuration
Filter wheel:
F1 OPEN
F1 OPEN
F2 BBP5500 + MgF2
F3 18a+ZnSe
F4 Reading 6.2um + MgF2
F5 N07053 +CaF2
F3 18a+ZnSe
F4 Reading 6.2um + MgF2
F5 N07053 +CaF2
F6 N07466+CaF2
F7 BP14100
F8 Soifer
F9 OCLI 'O' + CaF2 (removed CO2 filter and mailed to TG)
F10 N07904+CaF2
F7 BP14100
F8 Soifer
F9 OCLI 'O' + CaF2 (removed CO2 filter and mailed to TG)
F10 N07904+CaF2
F11 OCLI 'S'+BaF2
F12 N05340+MgF2
F12 N05340+MgF2
Decker wheel filters:
D1: BP13465 + BaF2
D2: BP6000 + MgF2
D3: BP6600 + MgF2
D4: N04679 +MgF2
D1: BP13465 + BaF2
D2: BP6000 + MgF2
D3: BP6600 + MgF2
D4: N04679 +MgF2
Lens wheel:
L1: mirror
L2: 1% neutral density filter
L3: 25mm KRS5 lens
L4: OPEN
L5: MgF2 blocker
L6: 38mm ZnSe lens (removed damaged 38mm KRS5 lens)
High-res door mirror stop:
moved screw stop by 1/12 turn CW.
[in CD27 -- turned 4-40 screw by 1/4 turn, CCW., in CD29, moved screw 1/8 turn CW]
Sunday, January 01, 2017
Understanding EXES coordinate system on FPI
12/30/2016
The ERF->SIRF conversion (delta) on the EXES GUI should be correct. Values entered in the ERF boxes (E/N) the SIRF calculated (|| and _|, that is: parallel and perpendicular) should move the telescope in the same direction as the previous command in ERF. At this point, my guess is that if the bright green cross represents 0,0 as defined by the XML then the commands as I send them now are "correct" in terms of coordinate system but do not actually move the telescope the same way.
If we want x to be -x, should change the XML so that 0,0 is at the lower right of the FPI, I think. My guess would be to change platescale in X to minus the current value. I would like to try this on the SIL as XML mode exes-slit-flip-x.
===================== What is in the code now: =========================
The above image (original, full with markup) shows a nod.define where in the EXES GUI we entered 20"E and 30"N "delta" for the. EXES current code translates this request to
nod.define coord_sys=ERF profile=3 pos_angle=146.3099 amplitude=18.028 amp2=18.028 track_pos_a=nodtracka track_pos_x=nodtrackx track_pos_b=nodtrackb
The 18.028 is sqtr(20*20 + 30*30)/2.
The yellow-green arrows show the requested position to move the telescope.
The red arrows show the movement the target makes on the FPI.
On the GUI, using coord.pos.sibs.vpa as the angle, E/N above is converted to SIRF:
x(q) =33.31
y(p) = -13.790770167929047
nodAngle = 112.49018659767083
nodAmp = 36.051927019573334 off slit
and produces the command:
nod.define coord_sys=SIRF profile=3 pos_angle=122.6227 amplitude=18.029 amp2=18.029 track_pos_a=nodtracka track_pos_x=nodtrackx track_pos_b=nodtrackb
122.67 degrees from Y axis counter-clockwise.
That image is shown here (original, full size with markup):
The point is that the command in SIRF is correct but since it does not go the same way as the ERF nod, it seems the conversion from SIRF to ERF in EXES code is wrong.
======================== Changes in code ================================
In order to "just make it work" we flip the X contribution ( X is "q" in EXES code below). These lines in the conversion from SIRF to ERF:
double north = -p * Math.cos(Math.toRadians(locTheta)) + q * Math.sin(Math.toRadians(locTheta));
double east = -p * Math.sin(Math.toRadians(locTheta)) - q * Math.cos(Math.toRadians(locTheta));
were changed to:
double north = -p * Math.cos(Math.toRadians(locTheta)) - q * Math.sin(Math.toRadians(locTheta));
double east = -p * Math.sin(Math.toRadians(locTheta)) + q * Math.cos(Math.toRadians(locTheta));
These line in the conversion from ERF to SIRF:
double q = north * Math.sin(Math.toRadians(locTheta)) - east * Math.cos(Math.toRadians(locTheta));
was changed to:
double q = -(north * Math.sin(Math.toRadians(locTheta)) - east * Math.cos(Math.toRadians(locTheta)));
This seemed to have worked in that if we moved with a nod.define in ERF and immediately followed with one in SIRF it all seemed to be going well (i.e. the conversion moved the telescope the same way in ERF and SIRF).
20 E 30 N => -28.13 Y -22.55 X OK
-20 E 30 N => -31.64 Y 17.29 X OK
-20 E -30 N => 28.13 Y 22.55 X OK
20 E -30 N => ???? I can not find an output (see outputs below)
I believe I forgot to hit Enter in the SIRF field but I need to test this again.
The (wrong) nod.define sent was:
nod.define coord_sys=SIRF profile=3 pos_angle=51.2785 amplitude=18.028 amp2=18.028 track_pos_a=nodtracka track_pos_x=nodtrackx track_pos_b=nodtrackb
========================================================================
OUTPUTS:
2016-12-30T16:29:12.438 AWT-EventQueue-0 East= 20.0 north=30.0 ERF: nodAngle = 146.30993247402023 nodAmp = 36.05551275463989 off slit
2016-12-30T16:30:19.580 AWT-EventQueue-0 SIRF: x(q) =-28.13 y(p) =-22.55 nodAngle = 231.28310695090178 nodAmp = 36.05273082583343 off slit
2016-12-30T16:31:52.768 AWT-EventQueue-0 East= -20.0 north=29.99879283921206 ERF: nodAngle = 213.69113163590538 nodAmp = 36.05450834236907 off slit
2016-12-30T16:33:05.643 AWT-EventQueue-0 SIRF: x(q) =-31.64 y(p) =17.2950355383569 nodAngle = 298.6618688239831 nodAmp = 36.05839505958395 off slit
2016-12-30T16:34:24.549 AWT-EventQueue-0 East= -20.002541398862668 north=-30.0 ERF: nodAngle = -33.6934276583436 nodAmp = 36.056922531092624 off slit
2016-12-30T16:35:44.086 AWT-EventQueue-0 SIRF: x(q) =28.13 y(p) =22.553731936380096 nodAngle = 51.27847970962215 nodAmp = 36.05506516785251 off slit
*no output with the above information in either form is between file close of FITS 00032 (so FITS 00033 matches and File close of FITS 00039, ASSUME I missed and did not hit ENTER in SIRF field? Some other bug?*
The ERF->SIRF conversion (delta) on the EXES GUI should be correct. Values entered in the ERF boxes (E/N) the SIRF calculated (|| and _|, that is: parallel and perpendicular) should move the telescope in the same direction as the previous command in ERF. At this point, my guess is that if the bright green cross represents 0,0 as defined by the XML then the commands as I send them now are "correct" in terms of coordinate system but do not actually move the telescope the same way.
If we want x to be -x, should change the XML so that 0,0 is at the lower right of the FPI, I think. My guess would be to change platescale in X to minus the current value. I would like to try this on the SIL as XML mode exes-slit-flip-x.
===================== What is in the code now: =========================
 |
| NOD 20"E, 30"N from SIBS |
nod.define coord_sys=ERF profile=3 pos_angle=146.3099 amplitude=18.028 amp2=18.028 track_pos_a=nodtracka track_pos_x=nodtrackx track_pos_b=nodtrackb
The 18.028 is sqtr(20*20 + 30*30)/2.
The yellow-green arrows show the requested position to move the telescope.
The red arrows show the movement the target makes on the FPI.
On the GUI, using coord.pos.sibs.vpa as the angle, E/N above is converted to SIRF:
x(q) =33.31
y(p) = -13.790770167929047
nodAngle = 112.49018659767083
nodAmp = 36.051927019573334 off slit
and produces the command:
nod.define coord_sys=SIRF profile=3 pos_angle=122.6227 amplitude=18.029 amp2=18.029 track_pos_a=nodtracka track_pos_x=nodtrackx track_pos_b=nodtrackb
122.67 degrees from Y axis counter-clockwise.
That image is shown here (original, full size with markup):
 |
| NOD 33.31" X, -13.79"Y |
======================== Changes in code ================================
In order to "just make it work" we flip the X contribution ( X is "q" in EXES code below). These lines in the conversion from SIRF to ERF:
double north = -p * Math.cos(Math.toRadians(locTheta)) + q * Math.sin(Math.toRadians(locTheta));
double east = -p * Math.sin(Math.toRadians(locTheta)) - q * Math.cos(Math.toRadians(locTheta));
were changed to:
double north = -p * Math.cos(Math.toRadians(locTheta)) - q * Math.sin(Math.toRadians(locTheta));
double east = -p * Math.sin(Math.toRadians(locTheta)) + q * Math.cos(Math.toRadians(locTheta));
These line in the conversion from ERF to SIRF:
double q = north * Math.sin(Math.toRadians(locTheta)) - east * Math.cos(Math.toRadians(locTheta));
was changed to:
double q = -(north * Math.sin(Math.toRadians(locTheta)) - east * Math.cos(Math.toRadians(locTheta)));
This seemed to have worked in that if we moved with a nod.define in ERF and immediately followed with one in SIRF it all seemed to be going well (i.e. the conversion moved the telescope the same way in ERF and SIRF).
20 E 30 N => -28.13 Y -22.55 X OK
-20 E 30 N => -31.64 Y 17.29 X OK
-20 E -30 N => 28.13 Y 22.55 X OK
20 E -30 N => ???? I can not find an output (see outputs below)
I believe I forgot to hit Enter in the SIRF field but I need to test this again.
The (wrong) nod.define sent was:
nod.define coord_sys=SIRF profile=3 pos_angle=51.2785 amplitude=18.028 amp2=18.028 track_pos_a=nodtracka track_pos_x=nodtrackx track_pos_b=nodtrackb
========================================================================
OUTPUTS:
2016-12-30T16:29:12.438 AWT-EventQueue-0 East= 20.0 north=30.0 ERF: nodAngle = 146.30993247402023 nodAmp = 36.05551275463989 off slit
2016-12-30T16:30:19.580 AWT-EventQueue-0 SIRF: x(q) =-28.13 y(p) =-22.55 nodAngle = 231.28310695090178 nodAmp = 36.05273082583343 off slit
2016-12-30T16:31:52.768 AWT-EventQueue-0 East= -20.0 north=29.99879283921206 ERF: nodAngle = 213.69113163590538 nodAmp = 36.05450834236907 off slit
2016-12-30T16:33:05.643 AWT-EventQueue-0 SIRF: x(q) =-31.64 y(p) =17.2950355383569 nodAngle = 298.6618688239831 nodAmp = 36.05839505958395 off slit
2016-12-30T16:34:24.549 AWT-EventQueue-0 East= -20.002541398862668 north=-30.0 ERF: nodAngle = -33.6934276583436 nodAmp = 36.056922531092624 off slit
2016-12-30T16:35:44.086 AWT-EventQueue-0 SIRF: x(q) =28.13 y(p) =22.553731936380096 nodAngle = 51.27847970962215 nodAmp = 36.05506516785251 off slit
*no output with the above information in either form is between file close of FITS 00032 (so FITS 00033 matches and File close of FITS 00039, ASSUME I missed and did not hit ENTER in SIRF field? Some other bug?*
Subscribe to:
Posts (Atom)