Subject: Re: 2.5m obslog 20100910 (MJD 55450)
From: David Schlegel
Date: Sat, 11 Sep 2010 11:25:36 -0700
--Apple-Mail-159-979658201
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Kaike,
Since this is happening so often, could we take as a work-around that
the observers look for a file appearing that says the flat-field was =
taken?
It looks like it would have to be one of these, where it should have the
correct timestamp:
    ls -l /data/gcam/$MJD/flat*
I don't know exactly where to dig to find out why this is failing.  But =
it does
look like there are no 0.5-sec guider images at the pre-calib times.
That probably means something at the STUI/sop level isn't asking
the guider to take the images.
-David
On Sep 11, 2010, at 10:59 AM, kaike pan wrote:
> Hi All,
>=20
>>=20
>> Guider flat failed a couple of times during the night, but we =
recieved no
>> loud error notice that there was a problem; see cart 17 in log.
>=20
>     It seems that you are having a problem on guider flat.   A few =
night ago, we had
> a problem associated with guider flat. We gotoField, take Calibs (flat =
and arc) which=20
> supposes to take guider flat too. When we started guider, we saw stars =
on two guiding fibers,
> I was thought we had stars on gotoField, but guider did not center =
stars. quickly, we noticed
> that we had a MARVELS guider mask configuration when a BOSS cartridge =
was
> actually loaded. Retake a guider flat fixed the problem.=20
>=20
>   It seems to me that guider may not complain not having a guider flat =
 AT ALL when a=20
> guider flat fails or not be taken. Instead it uses a guider flat from =
somewhere (previous one?).=20
> I think that displaying guider flat in guider mask will be very =
hopeful for catching a guider=20
> flat failure quickly. Of course, we do want guider to complain "no =
flat" when it does not
> have a good one.=20
>=20
>>=20
>>=20
>>=20
>> We are getting some RED waveMid values for B2 in SOS althogh the they =
seem to=20
>> be in spec: see log.=20
>>=20
>=20
>     Interestingly, I checked SoS outputs, and found that the reported =
RED waveMid values=20
> are black now as they are supposed to be. I do notice quite a few =
WSIGMA are in RED.
> For your information, current used XMID and WAVEMID nominal values are =
in Sept. science
> plan. I double checked and confirmed that they are consistent with =
OpLimits.par file
> in =
https://trac.sdss3.org/browser/repo/idlspec2d/trunk/examples/opLimits.par.=
=20
>=20
> These values are (from Sept science plan).
> The nominal XMID values are:
>=20
>      b1     r1     b2     r2
>=20
>      2036      2045      2043      2044
>=20
> The tolerance is +/- 8 pix (yellow), +/- 12 pix (red)
>=20
> =20
>=20
> The nominal WAVEMID values are:
>=20
>      b1     r1     b2     r2
>=20
>      4908     7987     4995     8053
>=20
> The tolerance is +/- 10 (yellow) and +/- 15 (blue) +/- 20  (red).
>=20
>    Cheers,
>=20
>   -kaike
>=20
--Apple-Mail-159-979658201
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii
Kaike,Since this is happening so often, could we =
take as a work-around thatthe observers look for a file =
appearing that says the flat-field was taken?It looks like it =
would have to be one of these, where it should have =
thecorrect timestamp:    ls -l =
/data/gcam/$MJD/flat*I don't know exactly =
where to dig to find out why this is failing.  But it =
doeslook like there are no 0.5-sec guider images at the =
pre-calib times.That probably means something at the STUI/sop =
level isn't askingthe guider to take the =
images.-David=
On Sep 11, 2010, at 10:59 AM, kaike pan wrote:Hi =
All,Guider flat =
failed a couple of times during the night, but we recieved noloud error notice that there was a problem; see cart =
17 in log.    It =
seems that you are having a problem on guider flat.   A few night =
ago, we hada problem associated with guider flat. We =
gotoField, take Calibs (flat and arc) which supposes to =
take guider flat too. When we started guider, we saw stars on two =
guiding fibers,I was thought we had stars on gotoField, but =
guider did not center stars. quickly, we noticedthat we had a =
MARVELS guider mask configuration when a BOSS cartridge =
wasactually loaded. Retake a guider flat fixed the =
problem.   It seems to me that =
guider may not complain not having a guider flat  AT ALL when =
a guider flat fails or not be taken. Instead it =
uses a guider flat from somewhere (previous one?). I =
think that displaying guider flat in guider mask will be very hopeful =
for catching a guider flat failure quickly. Of course, =
we do want guider to complain "no flat" when it does nothave =
a good one. We are getting some RED waveMid values for B2 in SOS =
althogh the they seem to be in spec: see log.    =
 Interestingly, I checked SoS outputs, and found that the reported =
RED waveMid values are black now as they are supposed to =
be. I do notice quite a few WSIGMA are in RED.For your =
information, current used XMID and WAVEMID nominal values are in Sept. =
scienceplan. I double checked and confirmed that they are =
consistent with OpLimits.par filein https:=
//trac.sdss3.org/browser/repo/idlspec2d/trunk/examples/opLimits.par.    =
These values are (from Sept science =
plan).The nominal XMID values =
are:   =
  b1     r1     =
b2     r2     2036      2045 =
     2043      =
2044The tolerance is +/- 8 pix (yellow), =
+/- 12 pix (red) The nominal =
WAVEMID values are:     =
b1     r1     =
b2     r2     4908     =
7987     4995     =
8053 The tolerance is +/- 10 (yellow) and =
+/- 15 (blue) +/- 20  (red).   Cheers,  -kaike  =
=
--Apple-Mail-159-979658201--