Observing Tool: Difference between revisions
(Created page with " ---- '''Domanda?''' Risposta ... ----") |
No edit summary |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
'''FAQ''' | |||
'''How can I submit my proposal?''' | |||
With the OT | |||
'''Webstart or Tarball OT’s version?''' | |||
Webstart has some limits on some OS to access the archive and to print the summary | |||
'''How can I produce a pdf summary of my proposal?''' | |||
With the tool "Generate a pdf summary" | |||
'''Is there a format (.tex/.style) or a template to write the proposal?''' | |||
No | |||
'''Will my proposal have 2 abstracts (one in the OT and one in the attached pdf file)?''' | |||
The one in the pdf is not compulsory | |||
'''What should I fill in for ‘line width’ in continuum observations?''' | |||
Nothing | |||
'''What is the ‘Recent Publications’ section in the OT?''' | |||
A list of recent publications of the proposer collaboration related with the submitted proposal | |||
'''Where should I attach my pdf file in the OT?''' | |||
Scrolling down to the bottom of the editor page. | |||
---- | |||
'''What is the largest angular scale of a source?''' | |||
The maximum angular dimension on which signal is expected. | |||
---- | |||
'''Problem with temporal resolution. ''' | |||
A ticket has been opened on behalf of users concerning | |||
the spectral sampling available for pulsar timing measurements. The original answer was that | |||
the minimum integration time for Cycle 0, given the data rate limit of 17 MB/s, is 10s. After | |||
the user discussed the problem directly with the helpdesk (ticket 1780), it was found that with | |||
an integration time of 96 ms, and the selected correlator setup, the data rate is of order of 5 | |||
MB/s, well below the maximum allowed. | |||
---- | ---- | ||
''' | |||
'''Issues in the OT with targets more than 15 degrees apart.''' | |||
A science goal with a list of sources separated by more than 15 degrees on the sky produced a warning that it might happen | |||
that the sources were going to be observed in different scheduling blocks. In the time estimate, | |||
despite the time on-source was only few minutes, the total time including calibration was of | |||
the order of days. Our suggestion was to separate the sources in different science goals. This | |||
considerably reduced the total time needed - which in itself is rather strange (could this be a | |||
bug in the OT?). | |||
The need to define multiple science goals can be very annoying if the sample includes a large | |||
number of sources, in particular if the targets could in principle share part of the calibration | |||
(e.g. bandpass and/or flux density), needlessly increasing the total time requested for the project | |||
(except in this case, though - see above). | |||
---- | |||
'''Discrepancies between the OST and the OT sensitivity calculator in handling the Tsys.''' | |||
See ticket 1868: The user pointed out that the Tsys in the sensitivity calculator for Band 9 is | |||
about 1000 K while in the OST it is 341 K, the latter value being closer to the expected values | |||
given in the Technical Handbook. After suggesting to trust the sensitivity calculator we sug- | |||
gested the user to open a ticket to get further details. The problem was related to the way the | |||
correlator removes the signal for the unused band for the double sideband receiver, but it does | |||
not remove the noise. To handle this, the sensitivity calculator increases the Tsys, but there is | |||
no correction for this in the OST. | |||
---- | |||
'''Misunderstanding about the peak flux density definition for spectral lines.''' | |||
One user | |||
wanted to detect a line with a spectral resolution (R) but knew only the expected integrated | |||
CO flux (S). They estimated the peak flux density to be entered into the OT with the following | |||
reasoning: assuming a total linewidth (W), the peak flux is S/W. The expected peak flux density | |||
in one channel should then be: S/W*W/R. This is however not the peak flux, but the integrated | |||
flux in one channel. | |||
---- | |||
'''Misunderstanding about the meaning of the ‘desired sensitivity per pointing’.''' | |||
Several | |||
users pointed out that it wasn’t clear what spectral setup had to be considered in order to define | |||
the ‘desired sensitivity per pointing’ in the OT, and that no example was available to clarify | |||
it. This was clarified by showing how to use the ‘Bandwidth used for sensitivity’ line. | |||
---- | |||
'''Misunderstanding about the usage of the ‘process as continuum’ tick.''' | |||
Some users fixed | |||
only one baseband centered on the spectral line they were interested in and ticked the ‘process as | |||
continuum’ button, assuming that it means that the other 3 basebands were fixed automatically | |||
by the system in a clever way, so that it was not necessary to specify them. | |||
---- | ---- | ||
Latest revision as of 11:09, 18 July 2011
FAQ
How can I submit my proposal?
With the OT
Webstart or Tarball OT’s version?
Webstart has some limits on some OS to access the archive and to print the summary
How can I produce a pdf summary of my proposal?
With the tool "Generate a pdf summary"
Is there a format (.tex/.style) or a template to write the proposal?
No
Will my proposal have 2 abstracts (one in the OT and one in the attached pdf file)?
The one in the pdf is not compulsory
What should I fill in for ‘line width’ in continuum observations?
Nothing
What is the ‘Recent Publications’ section in the OT?
A list of recent publications of the proposer collaboration related with the submitted proposal
Where should I attach my pdf file in the OT?
Scrolling down to the bottom of the editor page.
What is the largest angular scale of a source?
The maximum angular dimension on which signal is expected.
Problem with temporal resolution.
A ticket has been opened on behalf of users concerning the spectral sampling available for pulsar timing measurements. The original answer was that the minimum integration time for Cycle 0, given the data rate limit of 17 MB/s, is 10s. After the user discussed the problem directly with the helpdesk (ticket 1780), it was found that with an integration time of 96 ms, and the selected correlator setup, the data rate is of order of 5 MB/s, well below the maximum allowed.
Issues in the OT with targets more than 15 degrees apart.
A science goal with a list of sources separated by more than 15 degrees on the sky produced a warning that it might happen that the sources were going to be observed in different scheduling blocks. In the time estimate, despite the time on-source was only few minutes, the total time including calibration was of the order of days. Our suggestion was to separate the sources in different science goals. This considerably reduced the total time needed - which in itself is rather strange (could this be a bug in the OT?). The need to define multiple science goals can be very annoying if the sample includes a large number of sources, in particular if the targets could in principle share part of the calibration (e.g. bandpass and/or flux density), needlessly increasing the total time requested for the project (except in this case, though - see above).
Discrepancies between the OST and the OT sensitivity calculator in handling the Tsys. See ticket 1868: The user pointed out that the Tsys in the sensitivity calculator for Band 9 is about 1000 K while in the OST it is 341 K, the latter value being closer to the expected values given in the Technical Handbook. After suggesting to trust the sensitivity calculator we sug- gested the user to open a ticket to get further details. The problem was related to the way the correlator removes the signal for the unused band for the double sideband receiver, but it does not remove the noise. To handle this, the sensitivity calculator increases the Tsys, but there is no correction for this in the OST.
Misunderstanding about the peak flux density definition for spectral lines.
One user wanted to detect a line with a spectral resolution (R) but knew only the expected integrated CO flux (S). They estimated the peak flux density to be entered into the OT with the following reasoning: assuming a total linewidth (W), the peak flux is S/W. The expected peak flux density in one channel should then be: S/W*W/R. This is however not the peak flux, but the integrated flux in one channel.
Misunderstanding about the meaning of the ‘desired sensitivity per pointing’.
Several users pointed out that it wasn’t clear what spectral setup had to be considered in order to define the ‘desired sensitivity per pointing’ in the OT, and that no example was available to clarify it. This was clarified by showing how to use the ‘Bandwidth used for sensitivity’ line.
Misunderstanding about the usage of the ‘process as continuum’ tick.
Some users fixed only one baseband centered on the spectral line they were interested in and ticked the ‘process as continuum’ button, assuming that it means that the other 3 basebands were fixed automatically by the system in a clever way, so that it was not necessary to specify them.