|
|
| Changed: |
<
< |
| 2 | 02/07/2007 | AGBT07A_048_01 | Larry Rudnick & Shea Brown | Toney Minter & Dana Balser | The observers report higher than expected RMS for L-band. This is not unexpected and is likely from 1/f noise. However, they see the noise in the YY signal increase by a large amount. This begins at the start of a scan, persists for several scans, and then goes away at the end of a scan. Very strange.
Toney
Toney,
We've included plots of (calon-caloff), both xx and yy, for our 200 MHz bandwidth observation of 1422+83 (see 1422jump.gif). The plots are of two 6.25 MHz pieces of the spectrum:
Band 15: center freq.=1447 MHz
Band 26: center freq.=1515 MHz (this info. is also in the packet we gave you)
The x-axis is record number (basically time), and we have zoomed in on a
region that shows the yy (calon-caloff) going from a large rms to a much
smaller rms. Here are the start and end times for the high rms period, and
they occur during scan transitions:
START: 2007_02_07_20:34:41, LST=1.539849845e+03, moving from scan 135 to 136
END: 2007_02_07_20:36:45, LST=1.714326241e+03, moving from scan 138 to 139
We used the GBT Spectrometer calculator (for 6.25 MHz band,TSYS=15,t_on
and t_off = 0.4s) to calculate a theoretical rms of 10mK. We then added
this in quadrature with a 13mK confusion rms (estimated for 3 points/beam)
to get 16.4mK expected rms. Dividing this by the mean TSYS gives us a
theoretical RMS/MEAN=0.001 for the above plots. Our data are showing
instead:
XX RMS/MEAN=0.06
YY RMS/MEAN=0.12
Let us know what you make of this, and thanks for all the help!
Cheers,
Shea
| |
|
>
> |
| 2 | 02/07/2007 | AGBT07A_048_01 | Larry Rudnick & Shea Brown | Toney Minter & Dana Balser | The observers report higher than expected RMS for L-band. This is not unexpected and is likely from 1/f noise. However, they see the noise in the YY signal increase by a large amount. This begins at the start of a scan, persists for several scans, and then goes away at the end of a scan. Very strange.
Toney
Toney,
We've included plots of (calon-caloff), both xx and yy, for our 200 MHz bandwidth observation of 1422+83 (see graph). The plots are of two 6.25 MHz pieces of the spectrum:
Band 15: center freq.=1447 MHz
Band 26: center freq.=1515 MHz (this info. is also in the packet we gave you)
The x-axis is record number (basically time), and we have zoomed in on a
region that shows the yy (calon-caloff) going from a large rms to a much
smaller rms. Here are the start and end times for the high rms period, and
they occur during scan transitions:
START: 2007_02_07_20:34:41, LST=1.539849845e+03, moving from scan 135 to 136
END: 2007_02_07_20:36:45, LST=1.714326241e+03, moving from scan 138 to 139
We used the GBT Spectrometer calculator (for 6.25 MHz band,TSYS=15,t_on
and t_off = 0.4s) to calculate a theoretical rms of 10mK. We then added
this in quadrature with a 13mK confusion rms (estimated for 3 points/beam)
to get 16.4mK expected rms. Dividing this by the mean TSYS gives us a
theoretical RMS/MEAN=0.001 for the above plots. Our data are showing
instead:
XX RMS/MEAN=0.06
YY RMS/MEAN=0.12
Let us know what you make of this, and thanks for all the help!
Cheers,
Shea
| |
|
| Changed: |
<
< |
- 1422jump.gif:
%META:FILEATTACHMENT{name="1422jump.gif" attr="" comment="" date="1171293203" path="1422jump.gif" size="26387" user="ToneyMinter" version="1.1"}%
|
>
> |
%META:FILEATTACHMENT{name="1422jump.gif" attr="h" comment="" date="1171293203" path="1422jump.gif" size="26387" user="ToneyMinter" version="1.1"}% |
|
|
| Changed: |
<
< |
| 1 | 02/05/2007 | AGBT07A_102_01 | Lincoln Greenhill | Ron Maddalena & Toney Minter | Hi Ron,
Before the temperature shutdown on the GBT last night, I obtained a few nod
pairs on the Orion SiO? maser in two transitions. The v=1 transition comes in at 600 Jy, spread in two peaks about 3 MHz apart. I used a 200 MHz mode (AGBT_07A_102_01) w/ two offset windows (IFs). In IF2, the v=1 lines correctly appear at 43.12 GHz. An apparent replica of the lines appears at 43.22 GHz. [The line is not mirrored in frequency, though the line and artifact are on opposite sides of band-center.]
The strength of the artifact is down by ~ 600x (peak). In IF1, the same artifact appears, offset to 100 MHz lower frequency. [Again, there is no
mirroring.] Would 28 dB isolation be all that I should expect for the GBT?
Would you be able to explain in detail why there is an artifact at this intensity and nu-offset, based on a detailed description of the the microwave signal path? Might there be other artifacts?
Best,
Lincoln
Lincoln,
I just did a quick look at your data. You can see the maser in both beams
of the receiver. It is at least 400 times weaker in the beam that was "off"
the source. So the maser seems to be strong enough to come in the side-lobe
of the "off" beam. The "off" beam would probably be more than 30 dB down at
least.
Toney
Hi Toney,
Thanks for noticing the leakage into the off beam. I'd like to learn the
characteristics of the feed's beam pattern. I had anticipated more than
30 dB given the separation.
Lincoln & Toney,
The artifacts Lincoln is seeing are the weirdos that don't have a good
explanation. I'm still guessing it's a -25 to -30 dB 'sidelobe' on one
of our synthesizers.
The artifacts that Toney mentions are expected and have about the
expected magnitude. The beam separation of Q-band is ~58" while the
FWHM beam is 18". The separation of beam center to the first sidelobe
is ~47". The 2nd feed, then, is just slightly beyond the peak of the
first sidelobe. Toney's measurement of a 1/400 ghost in the 2nd feed (=
-26 dB) is actually very impressive for such a beam separation and
attests to the low sidelobes of the GBT even at Q-band.
At K-band and our other dual-feed receivers, things are somewhat
different. When compared to Q-band, the ratio of beam separations to
beam width is 50% larger, and, due to the longer wavelengths, the dish
is a bit better so the side lobe levels are a few dB lower. My estimate
is that the 2nd feed at K-band would see something like a -35 dB ghost
of what is in the 1st beam.
Ron
| |
|
>
> |
| 1 | 02/22/2007 | T_RCO340: | Larry Morgan | Larry Morgan | Performing the receiver checkout I had trouble balancing the system. I needed to set iftarget levels to 0.1/0.2 V suggesting that the iftarget defaults are not satisfactory. | |
|
|
|
| Changed: |
<
< |
|
>
> |
|
| Changed: |
<
< |
| 1 | 11/13/2006 | TKA_13NOV06 | Larry Morgan | Larry Morgan | When pointing/focusing with the Ka-band receiver the pointing scans are not handled correctly due to the lack of calibration information. However, the default data processing mode for these scans is 'beamswitched'. This needs to be changed to 'raw'. Otherwise the user needs to constantly select the option as the mode switches back to default between, and even during scans.
In short, please change the default data processing mode for the Ka-band receiver to 'raw'. | I will look into this. AmyShelton |
| 2 | 11/28/2006 | AGBT05B_011_46 | Toney Minter | Toney Minter | I had an break command in my script create a popup in astrid. I hit the 'yes' button and the popup went blank but did not go away. Astrid became unresponsive. I killed my astrid and tried to start a new one. I selected "work online with control" and this popup then went blank but did not go away with astrid being unresponsive. I notified the operator who restarted turtle. | Thanks for the report. Hopefully this will be resolved as part of the Astrid hangup investigation and related bug fixes. AmyShelton |
| 3 | 11/30/2007 | T_ZPEC_29NOV06 | Harris | O'Neil | IF manager went into an error state due to the power levels being too high, yet the scan was still able to run. Am I mis-remembering things, or shouldn't the system prevent a scan from running because of the error state? | Yes, if the Manager in question is included in the Scan Coordinator. AmyShelton |
| 4 | 12/05/2006 | AGBT06C_051 | Greenhill | Minter | The observer reported that a pop-up from a break command took two minutes to show up. The break was after a pointing and focus whose data displays showed up without any apparent delays. It is not know if the pop-up got hidden under other windows and it took 2 minutes to find it or if it really took 2 minutes for the pop-up to appear. The observer was observing remotely. | Unable to reproduce, but noted. The SDD is examing other issues related to dialog pop-ups. JoeBrandt |
| 5 | 01/01/2007 | AGBT05B_011 | Minter | Minter | When configuring the spectral processor for pulsar observations I continually find that the configuration tool does not setup the spectral processor as requested on the first attempt. It takes a second running of my astrid script to get the spectral processor setup correctly. This is very repeatable. An example script can be found in /users/tminter/pulsar_abs_obs/template_obs.py with the configurations used being in /users/tminter/pulsar_abs_obs/pulsar_abs.config
| I ran the scripts with Toney many times during maintenance on 01/02/2007 and we could not duplicate the problem. The next time he observes with these scripts, he will save the initial spectral processor configuration before he runs the script. This may provide us a clue as to how to duplicate it and the source of the problem.
For the AGBT06B_19_33 session, ASTRID logs confimed that the config tool reported that the spectral processor was in a different state than expected after configuration. This excerpt is from the ASTRID log for this session:
[08:30:53] Checking telescope
[08:30:53] Warning: Configuration complete but inconsistencies were found between the M&C system and the configuration tool. Verify the configuration
[08:30:53] (manager, parameter, expected value, actual value )
[08:30:53] ('SpectralProcessor', 'balance', 'NotBalance', 'Balance')
[08:30:53] ('SpectralProcessor', 'atodLevMode', 'Immediately', 'ScanStart')
[08:30:53] ('Rcvr1_2', 'tuning_frequency', '1420.405752', '1420.406')
[08:30:53] ('SpectralProcessor', 'numSpectr', '1', '2')
[08:30:53] ('SpectralProcessor', 'reqNumChan', '1024', '256')
[08:30:53] ('SpectralProcessor.SpectralProcessorA', 'observeFreq,1', '1420405752.0', '1420000000')
[08:30:53] ('SpectralProcessor.SpectralProcessorB', 'observeFreq,1', '1420405752.0', '1420000000')
[08:30:53]
|
| 6 | 01/02/2007 | AGBT06B_019_33 | Minter | Minter | A repeat of #5. | |
|
>
> |
| 1 | 02/05/2007 | AGBT07A_102_01 | Lincoln Greenhill | Ron Maddalena & Toney Minter | Hi Ron,
Before the temperature shutdown on the GBT last night, I obtained a few nod
pairs on the Orion SiO? maser in two transitions. The v=1 transition comes in at 600 Jy, spread in two peaks about 3 MHz apart. I used a 200 MHz mode (AGBT_07A_102_01) w/ two offset windows (IFs). In IF2, the v=1 lines correctly appear at 43.12 GHz. An apparent replica of the lines appears at 43.22 GHz. [The line is not mirrored in frequency, though the line and artifact are on opposite sides of band-center.]
The strength of the artifact is down by ~ 600x (peak). In IF1, the same artifact appears, offset to 100 MHz lower frequency. [Again, there is no
mirroring.] Would 28 dB isolation be all that I should expect for the GBT?
Would you be able to explain in detail why there is an artifact at this intensity and nu-offset, based on a detailed description of the the microwave signal path? Might there be other artifacts?
Best,
Lincoln
Lincoln,
I just did a quick look at your data. You can see the maser in both beams
of the receiver. It is at least 400 times weaker in the beam that was "off"
the source. So the maser seems to be strong enough to come in the side-lobe
of the "off" beam. The "off" beam would probably be more than 30 dB down at
least.
Toney
Hi Toney,
Thanks for noticing the leakage into the off beam. I'd like to learn the
characteristics of the feed's beam pattern. I had anticipated more than
30 dB given the separation.
Lincoln & Toney,
The artifacts Lincoln is seeing are the weirdos that don't have a good
explanation. I'm still guessing it's a -25 to -30 dB 'sidelobe' on one
of our synthesizers.
The artifacts that Toney mentions are expected and have about the
expected magnitude. The beam separation of Q-band is ~58" while the
FWHM beam is 18". The separation of beam center to the first sidelobe
is ~47". The 2nd feed, then, is just slightly beyond the peak of the
first sidelobe. Toney's measurement of a 1/400 ghost in the 2nd feed (=
-26 dB) is actually very impressive for such a beam separation and
attests to the low sidelobes of the GBT even at Q-band.
At K-band and our other dual-feed receivers, things are somewhat
different. When compared to Q-band, the ratio of beam separations to
beam width is 50% larger, and, due to the longer wavelengths, the dish
is a bit better so the side lobe levels are a few dB lower. My estimate
is that the 2nd feed at K-band would see something like a -35 dB ghost
of what is in the 1st beam.
Ron
| |
| 2 | 02/07/2007 | AGBT07A_048_01 | Larry Rudnick & Shea Brown | Toney Minter & Dana Balser | The observers report higher than expected RMS for L-band. This is not unexpected and is likely from 1/f noise. However, they see the noise in the YY signal increase by a large amount. This begins at the start of a scan, persists for several scans, and then goes away at the end of a scan. Very strange.
Toney
Toney,
We've included plots of (calon-caloff), both xx and yy, for our 200 MHz bandwidth observation of 1422+83 (see 1422jump.gif). The plots are of two 6.25 MHz pieces of the spectrum:
Band 15: center freq.=1447 MHz
Band 26: center freq.=1515 MHz (this info. is also in the packet we gave you)
The x-axis is record number (basically time), and we have zoomed in on a
region that shows the yy (calon-caloff) going from a large rms to a much
smaller rms. Here are the start and end times for the high rms period, and
they occur during scan transitions:
START: 2007_02_07_20:34:41, LST=1.539849845e+03, moving from scan 135 to 136
END: 2007_02_07_20:36:45, LST=1.714326241e+03, moving from scan 138 to 139
We used the GBT Spectrometer calculator (for 6.25 MHz band,TSYS=15,t_on
and t_off = 0.4s) to calculate a theoretical rms of 10mK. We then added
this in quadrature with a 13mK confusion rms (estimated for 3 points/beam)
to get 16.4mK expected rms. Dividing this by the mean TSYS gives us a
theoretical RMS/MEAN=0.001 for the above plots. Our data are showing
instead:
XX RMS/MEAN=0.06
YY RMS/MEAN=0.12
Let us know what you make of this, and thanks for all the help!
Cheers,
Shea
| |
|
| Added: |
>
> |
- 1422jump.gif:
%META:FILEATTACHMENT{name="1422jump.gif" attr="" comment="" date="1171293203" path="1422jump.gif" size="26387" user="ToneyMinter" version="1.1"}% |
|
|
| Changed: |
<
< |
| 5 | 01/01/2007 | AGBT05B_011 | Minter | Minter | When configuring the spectral processor for pulsar observations I continually find that the configuration tool does not setup the spectral processor as requested on the first attempt. It takes a second running of my astrid script to get the spectral processor setup correctly. This is very repeatable. An example script can be found in /users/tminter/pulsar_abs_obs/template_obs.py with the configurations used being in /users/tminter/pulsar_abs_obs/pulsar_abs.config
| |
|
>
> |
| 5 | 01/01/2007 | AGBT05B_011 | Minter | Minter | When configuring the spectral processor for pulsar observations I continually find that the configuration tool does not setup the spectral processor as requested on the first attempt. It takes a second running of my astrid script to get the spectral processor setup correctly. This is very repeatable. An example script can be found in /users/tminter/pulsar_abs_obs/template_obs.py with the configurations used being in /users/tminter/pulsar_abs_obs/pulsar_abs.config
| I ran the scripts with Toney many times during maintenance on 01/02/2007 and we could not duplicate the problem. The next time he observes with these scripts, he will save the initial spectral processor configuration before he runs the script. This may provide us a clue as to how to duplicate it and the source of the problem.
For the AGBT06B_19_33 session, ASTRID logs confimed that the config tool reported that the spectral processor was in a different state than expected after configuration. This excerpt is from the ASTRID log for this session:
[08:30:53] Checking telescope
[08:30:53] Warning: Configuration complete but inconsistencies were found between the M&C system and the configuration tool. Verify the configuration
[08:30:53] (manager, parameter, expected value, actual value )
[08:30:53] ('SpectralProcessor', 'balance', 'NotBalance', 'Balance')
[08:30:53] ('SpectralProcessor', 'atodLevMode', 'Immediately', 'ScanStart')
[08:30:53] ('Rcvr1_2', 'tuning_frequency', '1420.405752', '1420.406')
[08:30:53] ('SpectralProcessor', 'numSpectr', '1', '2')
[08:30:53] ('SpectralProcessor', 'reqNumChan', '1024', '256')
[08:30:53] ('SpectralProcessor.SpectralProcessorA', 'observeFreq,1', '1420405752.0', '1420000000')
[08:30:53] ('SpectralProcessor.SpectralProcessorB', 'observeFreq,1', '1420405752.0', '1420000000')
[08:30:53]
|
|
|
|
| Changed: |
<
< |
| 1 | 11/13/2006 | TKA_13NOV06 | Larry Morgan | Larry Morgan | When pointing/focusing with the Ka-band receiver the pointing scans are not handled correctly due to the lack of calibration information. However, the default data processing mode for these scans is 'beamswitched'. This needs to be changed to 'raw'. Otherwise the user needs to constantly select the option as the mode switches back to default between, and even during scans.
In short, please change the default data processing mode for the Ka-band receiver to 'raw'. | |
| 2 | 11/28/2006 | AGBT05B_011_46 | Toney Minter | Toney Minter | I had an break command in my script create a popup in astrid. I hit the 'yes' button and the popup went blank but did not go away. Astrid became unresponsive. I killed my astrid and tried to start a new one. I selected "work online with control" and this popup then went blank but did not go away with astrid being unresponsive. I notified the operator who restarted turtle. | |
| 3 | 11/30/2007 | T_ZPEC_29NOV06 | Harris | O'Neil | IF manager went into an error state due to the power levels being too high, yet the scan was still able to run. Am I mis-remembering things, or shouldn't the system prevent a scan from running because of the error state? | |
|
>
> |
| 1 | 11/13/2006 | TKA_13NOV06 | Larry Morgan | Larry Morgan | When pointing/focusing with the Ka-band receiver the pointing scans are not handled correctly due to the lack of calibration information. However, the default data processing mode for these scans is 'beamswitched'. This needs to be changed to 'raw'. Otherwise the user needs to constantly select the option as the mode switches back to default between, and even during scans.
In short, please change the default data processing mode for the Ka-band receiver to 'raw'. | I will look into this. AmyShelton |
| 2 | 11/28/2006 | AGBT05B_011_46 | Toney Minter | Toney Minter | I had an break command in my script create a popup in astrid. I hit the 'yes' button and the popup went blank but did not go away. Astrid became unresponsive. I killed my astrid and tried to start a new one. I selected "work online with control" and this popup then went blank but did not go away with astrid being unresponsive. I notified the operator who restarted turtle. | Thanks for the report. Hopefully this will be resolved as part of the Astrid hangup investigation and related bug fixes. AmyShelton |
| 3 | 11/30/2007 | T_ZPEC_29NOV06 | Harris | O'Neil | IF manager went into an error state due to the power levels being too high, yet the scan was still able to run. Am I mis-remembering things, or shouldn't the system prevent a scan from running because of the error state? | Yes, if the Manager in question is included in the Scan Coordinator. AmyShelton |
|
|
|
| Changed: |
<
< |
|
>
> |
|
| Deleted: |
<
< |
| 1 | 2 July 2006 | AGBT02A_053_02 | Heiles/Robishaw | Balser | During project AGBT02A_053_01 Heiles and Robishaw successfully used the cross correlation modes of the Spectrometer. For example see scan 14. During project AGBT02A_053_02 using the same configuration scripts they did not get any sensible data. For example see scan 122. The raw data almost appears to have two correlation functions plotted in one spectrum. It looked to me like a Spectrometer configuration problem and I suggested if they saw this again to perform a reset parameters, etc. During their next run the data looked okay.
Dana | Sounds like a firmware loading problem. The same scripts were later able to configure the spectormeter properly. JoeBrandt
|
| 2 | 46 Aug 2006 | AGBT06B_020_09 | O'Neil | O'Neil | The antenna was in an error state, due to truck #4 being turned off. Both thte scan coordinator and the astrid & GBTstatus "GBT status" windows correctly reflected this error state foe me, but the CLEO message window did not, even though the error did appear for the telescope operator. -Main.KarenONeil | The inability of the message system to reliably assert alerts is of serious concern for us. JoeBrandt has one fix for such problems, but a true resolution will require a more concerted effort. MarkClark |
| 3 | 15 Aug 2006 | T_FG060715 | Ghigo | Ghigo | I continue to be a bit annoyed by the "Center Freq"
item in the gbtstatus display. This is in fact the
IF1 frequency. But people might think it is
the sky frequency center. This has confused
people in the past. I would advocate
calling it "IF1 Freq" , and eliminating it
altogether from the display.
| The labels on the gbtstatus display have been approved by the sponsor. They should not be changed unless they are discussed at Observing issues meeting and approved byt CCC. Please bring this item up at the next observing issues meeting.
FYI:I have added this request to the gbtstatus enhancement request page: http://wiki.gb.nrao.edu/bin/preview/Software/GbtStatusDisplayRequests
|
| 4 | 21 Aug 2006 | General Tests | Balser | Balser | For the last two time periods when I was the support person there has been poor communication as to who was reponsible for running tests or commissioning observations. As a result time was lost and the time was not always filled with the most effective observing. Granted as support person I probably should have done a better job of following up on these tests.
Nevertheless, I think we can miminize this in the future by simply associating a person with each commissioning run or test, just like a PI on astronomy projects. This should go on the schedule so the operator, or anyone else, will know who is in charge of these observations.
Dana | |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| wrt#1: There are several problems with the Archivist. Several of the problems result in a core dump, however the problems seen with the weather station are less obvious. Bottom line here is that time is needed to fix the archivist, as a scheduled activity. JoeBrandt wrt#2: Indeed the validator needs to be enhanced to prevent users from doing unintended things during validation. There are a whole host of items also surrounding validation. We need to figure out how to get enhancements to the validator on the schedule. In the meantime, there is an easy work-around to avoid this problem. Simply create your own custom ScanType and place the offending code within the Execute method. I'd be more than willing to help you with this. AmyShelton Okay, this is something that one might want to do in the future. DanaBalser wrt#3: I have a good idea of what could be done to alleviate this problem. We need to free up resources and get time to fix it. AmyShelton wrt#4: I haven't heard about this before. Can you tell me the project id and session so I can look at the log. Or (even better) can you send me the log? AmyShelton I don't have the log but the project id's were TPTCSPNT_060817, TPTCSPNT_60817, and TPTCSPNT_060818. DanaBalser Thanks for the additional info. When I write my original response I assumed that the error message was displayed in the observing log. But now that I reread your entry, it sounds like the error was in the GFM log. Is that the case? I'll rerun your projects offline with GFM and inspect the logs. I'm guessing that they will probably reduce fine after the fact and that there was some sort of NFS slowness which prevented GFM from "seeing" the GO FITS file in time for the data reduction. This can usually be determined while observing by openning up a separate GFM session and reselecting the failed scans. If this is what happened, this could be prevented by moving to data streams rather than relying on the reading of FITS files for real-time data reduction. AmyShelton |
|
|
|
| Changed: |
<
< |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| wrt#1: There are several problems with the Archivist. Several of the problems result in a core dump, however the problems seen with the weather station are less obvious. Bottom line here is that time is needed to fix the archivist, as a scheduled activity. JoeBrandt wrt#2: Indeed the validator needs to be enhanced to prevent users from doing unintended things during validation. There are a whole host of items also surrounding validation. We need to figure out how to get enhancements to the validator on the schedule. In the meantime, there is an easy work-around to avoid this problem. Simply create your own custom ScanType and place the offending code within the Execute method. I'd be more than willing to help you with this. AmyShelton Okay, this is something that one might want to do in the future. DanaBalser wrt#3: I have a good idea of what could be done to alleviate this problem. We need to free up resources and get time to fix it. AmyShelton wrt#4: I haven't heard about this before. Can you tell me the project id and session so I can look at the log. Or (even better) can you send me the log? AmyShelton I don't have the log but the project id's were TPTCSPNT_060817, TPTCSPNT_60817, and TPTCSPNT_060818. DanaBalser |
|
>
> |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| wrt#1: There are several problems with the Archivist. Several of the problems result in a core dump, however the problems seen with the weather station are less obvious. Bottom line here is that time is needed to fix the archivist, as a scheduled activity. JoeBrandt wrt#2: Indeed the validator needs to be enhanced to prevent users from doing unintended things during validation. There are a whole host of items also surrounding validation. We need to figure out how to get enhancements to the validator on the schedule. In the meantime, there is an easy work-around to avoid this problem. Simply create your own custom ScanType and place the offending code within the Execute method. I'd be more than willing to help you with this. AmyShelton Okay, this is something that one might want to do in the future. DanaBalser wrt#3: I have a good idea of what could be done to alleviate this problem. We need to free up resources and get time to fix it. AmyShelton wrt#4: I haven't heard about this before. Can you tell me the project id and session so I can look at the log. Or (even better) can you send me the log? AmyShelton I don't have the log but the project id's were TPTCSPNT_060817, TPTCSPNT_60817, and TPTCSPNT_060818. DanaBalser Thanks for the additional info. When I write my original response I assumed that the error message was displayed in the observing log. But now that I reread your entry, it sounds like the error was in the GFM log. Is that the case? I'll rerun your projects offline with GFM and inspect the logs. I'm guessing that they will probably reduce fine after the fact and that there was some sort of NFS slowness which prevented GFM from "seeing" the GO FITS file in time for the data reduction. This can usually be determined while observing by openning up a separate GFM session and reselecting the failed scans. If this is what happened, this could be prevented by moving to data streams rather than relying on the reading of FITS files for real-time data reduction. AmyShelton |
|
|
|
| Changed: |
<
< |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| wrt#1: There are several problems with the Archivist. Several of the problems result in a core dump, however the problems seen with the weather station are less obvious. Bottom line here is that time is needed to fix the archivist, as a scheduled activity. JoeBrandt wrt#2: Indeed the validator needs to be enhanced to prevent users from doing unintended things during validation. There are a whole host of items also surrounding validation. We need to figure out how to get enhancements to the validator on the schedule. In the meantime, there is an easy work-around to avoid this problem. Simply create your own custom ScanType and place the offending code within the Execute method. I'd be more than willing to help you with this. AmyShelton wrt#3: I have a good idea of what could be done to alleviate this problem. We need to free up resources and get time to fix it. AmyShelton wrt#4: I haven't heard about this before. Can you tell me the project id and session so I can look at the log. Or (even better) can you send me the log? AmyShelton |
|
>
> |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| wrt#1: There are several problems with the Archivist. Several of the problems result in a core dump, however the problems seen with the weather station are less obvious. Bottom line here is that time is needed to fix the archivist, as a scheduled activity. JoeBrandt wrt#2: Indeed the validator needs to be enhanced to prevent users from doing unintended things during validation. There are a whole host of items also surrounding validation. We need to figure out how to get enhancements to the validator on the schedule. In the meantime, there is an easy work-around to avoid this problem. Simply create your own custom ScanType and place the offending code within the Execute method. I'd be more than willing to help you with this. AmyShelton Okay, this is something that one might want to do in the future. DanaBalser wrt#3: I have a good idea of what could be done to alleviate this problem. We need to free up resources and get time to fix it. AmyShelton wrt#4: I haven't heard about this before. Can you tell me the project id and session so I can look at the log. Or (even better) can you send me the log? AmyShelton I don't have the log but the project id's were TPTCSPNT_060817, TPTCSPNT_60817, and TPTCSPNT_060818. DanaBalser |
|
|
|
| Changed: |
<
< |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| wrt#1: There are several problems with the Archivist. Several of the problems result in a core dump, however the problems seen with the weather station are less obvious. Bottom line here is that time is needed to fix the archivist, as a scheduled activity. JoeBrandt |
|
>
> |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| wrt#1: There are several problems with the Archivist. Several of the problems result in a core dump, however the problems seen with the weather station are less obvious. Bottom line here is that time is needed to fix the archivist, as a scheduled activity. JoeBrandt wrt#2: Indeed the validator needs to be enhanced to prevent users from doing unintended things during validation. There are a whole host of items also surrounding validation. We need to figure out how to get enhancements to the validator on the schedule. In the meantime, there is an easy work-around to avoid this problem. Simply create your own custom ScanType and place the offending code within the Execute method. I'd be more than willing to help you with this. AmyShelton wrt#3: I have a good idea of what could be done to alleviate this problem. We need to free up resources and get time to fix it. AmyShelton wrt#4: I haven't heard about this before. Can you tell me the project id and session so I can look at the log. Or (even better) can you send me the log? AmyShelton |
|
|
|
| Changed: |
<
< |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| |
|
>
> |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| wrt#1: There are several problems with the Archivist. Several of the problems result in a core dump, however the problems seen with the weather station are less obvious. Bottom line here is that time is needed to fix the archivist, as a scheduled activity. JoeBrandt |
|
|
|
| Changed: |
<
< |
| 3 | 15 Aug 2006 | T_FG060715 | Ghigo | Ghigo | I continue to be a bit annoyed by the "Center Freq"
item in the gbtstatus display. This is in fact the
IF1 frequency. But people might think it is
the sky frequency center. This has confused
people in the past. I would advocate
calling it "IF1 Freq" , and eliminating it
altogether from the display.
| The labels on the gbtstatus display have been approved by the sponsor. I have added this request to the gbtstatus enhancement request page http://wiki.gb.nrao.edu/bin/preview/Software/GbtStatusDisplayRequests
Please not that all request changes should be discussed at Observing issues meeting and MRs will be forwarded to the CCC. |
|
>
> |
| 3 | 15 Aug 2006 | T_FG060715 | Ghigo | Ghigo | I continue to be a bit annoyed by the "Center Freq"
item in the gbtstatus display. This is in fact the
IF1 frequency. But people might think it is
the sky frequency center. This has confused
people in the past. I would advocate
calling it "IF1 Freq" , and eliminating it
altogether from the display.
| The labels on the gbtstatus display have been approved by the sponsor. They should not be changed unless they are discussed at Observing issues meeting and approved byt CCC. Please bring this item up at the next observing issues meeting.
FYI:I have added this request to the gbtstatus enhancement request page: http://wiki.gb.nrao.edu/bin/preview/Software/GbtStatusDisplayRequests
|
|
| Changed: |
<
< |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| |
|
>
> |
| 5 | 2006 | Pointing | Balser | Balser | Although the observing process has significantly improved over the last year or two there remains some nagging problems that seem to plague pointing runs more than standard astronomy. Here I list these problems as a summary of observing problems during pointing runs in 2006. These are by no means show stoppers but it would be very nice if they were fixed.
1. During most of the year the archivist did not work for the weather station data. This is essential for most PTCS runs. Furthermore, I think the weather should be archived with all projects (commissioning and astronomy). Yes, one can always go the the logs but the whole point of the archivist system is to allow the user to archive the data they want. It was a good idea and it is very useful! It would be even more useful if it were robust. (Thanks Joe for fixing the weather archivist before my last run. It seemed to work fine!)
2. While the validate process in astrid is extremely useful it sometimes performs evil acts. I am sure I do not understand exactly what it does. It seems to run the scheduling block without really running the scheduling block, except that it does run some things. In having to be more creative with PTCS commissioning we required code that probably was not within the scope of astrid and this has caused some problems.
I will only give one example to illustrate my point. When trying to perform an all sky pointing run it was necessary to save information about the current direction of the (Az,El) grid. To do this Amy suggested we just save this information to a file and read it back in. This seems to work okay but when you save the scheduling block to the database, and hence validate, it runs the code and thus changes the file.
I wonder if one can validate without really running the code since this can (1) cause some very subtle problems; and (2) it takes quite some time to validate large loops.
3. We still get the message that no corrections are detected when doing pointing. During pointing runs this, of course, happens more frequently. I know people have worked on this problem but it just seems to me that it should be easy to pass two numbers from one piece of software to another.
4. During every pointing run we continuue to get the message that the GO FITS file is malformed. I am told by the operators that they see this problem far more often during pointing runs. Is this because we generate more scans? I don't know.
Dana
| |
|