An Observation Scheduling System for Radio Telescope Array
Round 1
Reviewer 1 Report
Comments and Suggestions for AuthorsThe authors present an overview of a software tool written for a 4x4.5 m radio telescope array to schedule observations within a 24h interval. The tool transforms sky coordinates into local telescope coordinates and schedules/ prioritizes observations based on their observability. It also calculates “uv-coverage” for observations. As part of the function testing it also investigates the uv-coverage ratios for multiple telescope array setups.
Most of the functionalities of the software as generally knows calculations used in interferometry. It is mainly a manual/development document with very little novelty and originality. If there is any originality in the performed calculations its not traceable. It lacks quantitative documentation like accuracy requirements. The described “intelligent scheduling module” is a simple straight forward procedure without any multi parameter optimization or similar. While this might be a good way to prioritize and schedule observations, this is not comprehendible from the paper, as only a single 24h set of sources is presented. Here it would be essential to show how it has performed over a longer period of weeks or months. This could tell if it successfully scheduling observations, or if further optimization was/will be needed.
Presenting this tool to the broader audience might be useful at a later point with statistical data on how well it performed and a quantitative analysis of the fulfillment of the requirements, e.g. for the u,v coverage. In its current form I cannot recommend it for publication since to many essentials (quantitative requirements, what is new about them, quantitative analysis of the success of the scheduling scheme,…) are missing. I do however encourage the authors to further work on the topic, as good publications on software tool for observational astronomy are very useful to the community.
Some major concerns suggestions:
- The title is misleading, as observations are not predicted but rather local coordinates such as elevation are calculated, which is standard for many telescope operating systems, if there is any relevant progress in accuracy or in the u,v coverage calculation its needs to be clearly pointed out
- All figure and table descriptions are very short and lack detail, like referring the targets in table 1 to the sample in the text above
- Chapter 1 The analysis of available software of other observatories would need more details, e.g. if the Effelsberg software does lack a detailed predictor for target source observations, how is the telescope able to perform observations? Most telescope pointing software can use sky coordinates as input and perform observations. The calculations are relevant here for the purpose of scheduling. This should be pointed out more clearly.
- Chapter 2.1 Why does the software only look at 24h intervals. Usually scheduling and priorities are considered on longer time frames. The 24h limit needs to be motivated
- Chapter 2.2: The requirements for the calibrators, like how long the need to be observed, are missing. Are the observations with overheads short enough not to be considered in the scheduling process? What happened if no calibrators are available in the transition time between sources
- Chapter 3.1 How was the sample used for the testing defined? Are those the actual observations performed on that date. Are they from a target pool for a cycle? How does the 24h period connect to the overall cycle?
- Chapter 3.2 What is the general role of telescope overheads? How does the splitting up of observations affect the overall efficiency and uv-coverage?
- Chapter 3.4 The relevance of the analysis of different array layouts and integration times is unclear, since the paper is describing a software tool. If this is a functionality test what are the requirements tested against
- Chapter 4 figure 17 is missing
- Chapter 4 How was the software used specifically to aid the detection of the pulsars.
Author Response
Comments and Suggestions for Authors
- The authors present an overview of a software tool written for a 4x4.5 m radio telescope array to schedule observations within a 24h interval. The tool transforms sky coordinates into local telescope coordinates and schedules/ prioritizes observations based on their observability. It also calculates “uv-coverage” for observations. As part of the function testing it also investigates the uv-coverage ratios for multiple telescope array setups.
Thanks.
- Most of the functionalities of the software as generally knows calculations used in interferometry.It is mainly a manual/development document with very little novelty and originality. If there is any originality in the performed calculations its not traceable. It lacks quantitative documentation like accuracy requirements. The described “intelligent scheduling module” is a simple straight forward procedure without any multi parameter optimization or similar. While this might be a good way to prioritize and schedule observations, this is not comprehendible from the paper, as only a single 24h set of sources is presented. Here it would be essential to show how it has performed over a longer period of weeks or months. This could tell if it successfully scheduling observations, or if further optimization was/will be needed.
Thanks. We have responded to the question of 'Why does the software only consider 24 - hour intervals' below.
- Presenting this tool to the broader audience might be useful at a later point with statistical data on how well it performed and a quantitative analysis of the fulfillment of the requirements, e.g. for the u,v coverage. In its current form I cannot recommend it for publication since to many essentials (quantitative requirements, what is new about them, quantitative analysis of the success of the scheduling scheme,…) are missing.I do however encourage the authors to further work on the topic, as good publications on software tool for observational astronomy are very useful to the community.
Thanks for your comment. However, we should note that uv coverage is one of the basic functions in radio astronomical observation scheduling. For instance, the SCHED software supports the selection of different antennas among stations for uv coverage, thereby determining the observation plan. Consequently, we add the uv coverage function to this system. In this way, we can determine the observation schedule based on uv coverage and find the optimal array arrangement when constructing new arrays. Therefore, the revised manuscript retains the uv coverage function.
Some major concerns suggestions:
- The title is misleading, as observations are not predicted but rather local coordinates such as elevation are calculated, which is standard for many telescope operating systems, if there is any relevant progress in accuracy or in the u,v coverage calculation its needs to be clearly pointed out
Yes, to make it clearer, we have revised it to 'a observation scheduling system for radio telescope array'.
- All figure and table descriptions are very short and lack detail, like referring the targets in table 1 to the sample in the text above
Thanks for your comment. We have added more details to all figures and tables.
- Chapter 1 The analysis of available software of other observatories would need more details, e.g. if the Effelsberg software does lack a detailed predictor for target source observations, how is the telescope able to perform observations? Most telescope pointing software can use sky coordinates as input and perform observations. The calculations are relevant here for the purpose of scheduling. This should be pointed out more clearly.
Yes. We have pointed this out to make it clearer.
- Chapter 2.1 Why does the software only look at 24h intervals. Usually scheduling and priorities are considered on longer time frames. The 24h limit needs to be motivated
Thanks for your comment. This 24h interval is determined according to our current array observations. Since we have observers on duty every day, who are responsible for the daily observation plan and maintenance, this 24h prediction has already met our requirements. This time length is also the conventional duration in formulating radio astronomy observation proposals. In addition, if scheduling for more than 24 hours is indeed required, the current software can achieve this through multiple schedulings by extending the start time.
- Chapter 2.2: The requirements for the calibrators, like how long the need to be observed, are missing. Are the observations with overheads short enough not to be considered in the scheduling process? What happened if no calibrators are available in the transition time between sources
Thank you for your comment. Currently, the performance of our telescope array is restricted in detecting the traditionnal calibrator signal, and this function mainly serves the subsequently upgraded telescope array. The calibrator we are using at present is the Sun, and the observation time is 4 seconds.
- Chapter 3.1 How was the sample used for the testing defined? Are those the actual observations performed on that date. Are they from a target pool for a cycle? How does the 24h period connect to the overall cycle?
These samples are the target sources that may receive signals from the telescope array and were used for the telescope array's daily observations. The six sources are distributed within 24 hours, with 24 hours being regarded as an observation period.
- Chapter 3.2 What is the general role of telescope overheads? How does the splitting up of observations affect the overall efficiency and uv-coverage?
Constrained by the number of antennas (four) in the array, the uv - coverage has not yet been taken into account in the telescope overheads. This analysis will be incorporated in future work.
- Chapter 3.4 The relevance of the analysis of different array layouts and integration times is unclear, since the paper is describing a software tool. If this is a functionality test what are the requirements tested against
A description of the integration time has been added. The uv coverage is utilized to determine the optimal layout of the array configuration during the array upgrade and for ranking according to the quality of uv coverage in observation scheduling. This description has been inserted into Chapter 3.4.
- Chapter 4 figure 17 is missing
This figure has been added.
- Chapter 4 How was the software used specifically to aid the detection of the pulsars
This software, together with other software and hardware, is used for pulsar detection.
Reviewer 2 Report
Comments and Suggestions for AuthorsRadio source observation prediction system is a newly developed computer program package for observation planning, although this kind of systems are nothing new, but for various reasons none of existing ones provide full sweep of functionality, others are outdated or are not publicly available. This article contains detailed algorithms of how specific functionality has been made. A source observation prediction system can provide a good value for the community, especially if source code will be made publicly accessible. Inelegant scheduling mode provides new functionality compared to pySCHED (traditionally used observation planning tool for arrays).
Major comments:
4 X 4.5 m telescope array at Guizhou Normal University is a new facility which needs more in-depth introduction on the international stage, so I encourage author’s to expand the section about array.
Add information like: more specific geographical location (are these 4 antennas located at intended position of array - Liupanshui City or same place else), short history of this array project (when it was firstly proposed, when construction started, first dish delivered) and overall scope of project (total number of planned antennas and projection when expanded array will be fully finished), is it student built(?), give frequency range coverage and same sensitivity characteristics of receiver, what is expected efficiency of aperture. And of course will be free to add any other information that the author team thinks can be beneficial for readers.
To enhance the impact of the radio source observation prediction system and this article, I suggest making the Observation Prediction System publicly available. For example with a public GitHub repository with functional and basic documentation, and with link (acknowledgment) to this article. I think it will greatly improve the impact of this article, Observation Prediction System as a modular system could be useful for many observatories across the world, especially for most new ones.
Although formally correct, I am suggesting to use the elevation (angle) in all the places where its meaning is the angle between source on the sky and observer local plain instead of altitude. In this article the Earth center coordinate system XYZ was used for uvw transformation, but one could want to use latitude and longitude and also the altitude (m above...) to precisely show antenna position. In this way any possible confusion can be more easily avoided.
Minor comments:
Line 190 …..based on the specific observational requirements. - Give examples of one, two possible requirements to use. ... requirements (for example…..).
Line 192 explain what is QT interface (Qt)
Add in text what red dot in Fig 1. 6. 8 marks in this figures
Line 257 missing space
Line 286 ... radio burst FRB190523 (represented by the blue line at the top of Figure 8) – seams Figure 7 is correct reference here
Line 287 . Similarly, when tracking the target source J1846-0258 (the orange line at the top of Figure 8) – once again Fig 7
Also target - calibrator pair description can be improved, perhaps consider to make a plot or Table to show fully observation plan in one day (like Fig 7 but also showing time on calibrator), including targets and calibrators and showing time executing observation
Table 2 explain what is the altitude difference angle - is it difference in elevation angle in one day?
Fig 9 x-axes units ; if 4 antennas already operational is in this array, mark them in different color
Fig 10 – Fixed axes scale will allow beater to see improvement over time, it will also make it consistent with Fig 12 style.
Fig 17 – Not loaded
Author Response
Comments and Suggestions for Authors
- Radio source observation prediction system is a newly developed computer program package for observation planning, although this kind of systems are nothing new, but for various reasons none of existing ones provide full sweep of functionality, others are outdated or are not publicly available. This article contains detailed algorithms of how specific functionality has been made. A source observation prediction system can provide a good value for the community, especially if source code will be made publicly accessible. Inelegant scheduling mode provides new functionality compared to pySCHED (traditionally used observation planning tool for arrays).
Thanks.
Major comments:
- 4 X 4.5 m telescope array at Guizhou Normal University is a new facility which needs more in-depth introduction on the international stage, so I encourage author’s to expand the section about array.
Thank you for your comment. In the revised manuscript, a detailed introduction to the array part has been added.
- Add information like: more specific geographical location (are these 4 antennas located at intended position of array - Liupanshui City or same place else), short history of this array project (when it was firstly proposed, when construction started, first dish delivered) and overall scope of project (total number of planned antennas and projection when expanded array will be fully finished), is it student built(?), give frequency range coverage and same sensitivity characteristics of receiver, what is expected efficiency of aperture. And of course will be free to add any other information that the author team thinks can be beneficial for readers.
Thank you for your comment. The newly added introduction to the array includes the above mentioned information about arrays. Please refer to Section 2, Table 1 and Table 2.
- To enhance the impact of the radio source observation prediction system and this article, I suggest making the Observation Prediction System publicly available. For example with a public GitHub repository with functional and basic documentation, and with link (acknowledgment) to this article. I think it will greatly improve the impact of this article, Observation Prediction System as a modular system could be useful for many observatories across the world, especially for most new ones.
Thank you for your comment. The source code of our system has been uploaded to GitHub. The following is the link to the project:
https://github.com/MC-git37/A-RADIO-SOURCES-OBSERVATION-PREDICTION-SYSTEM-FOR-TELESCOPE-ARRAY/tree/master/optimize20240401
- Although formally correct, I am suggesting to use the elevation (angle) in all the places where its meaning is the angle between source on the sky and observer local plain instead of altitude. In this article the Earth center coordinate system XYZ was used for uvw transformation, but one could want to use latitude and longitude and also the altitude (m above...) to precisely show antenna position. In this way any possible confusion can be more easily avoided.
Thanks. It has been replaced as required.
Minor comments:
- Line 190 …..based on the specific observational requirements. - Give examples of one, two possible requirements to use. ... requirements (for example…..).
The use requirements have been illustrated by examples.
- Line 192 explain what is QT interface (Qt)
Here, by "The QT interface", we aim to denote the interface generated by the Qt module, namely, the system interface. To clarify it, we have already revised it to "system interface" in the modified manuscript.
- Add in text what red dot in Fig 1. 6. 8 marks in this figures
The meaning of the red dot has been explained in the text, which is the elevation value of the target source at the current observation time.
- Line 257 missing space
Already checked.
- Line 286 ... radio burst FRB190523 (represented by the blue line at the top of Figure 8) – seams Figure 7 is correct reference here
The Figure 7 reference has been corrected.
- Line 287 . Similarly, when tracking the target source J1846-0258 (the orange line at the top of Figure 8) – once again Fig 7
The Figure 7 reference has been corrected
- Also target - calibrator pair description can be improved, perhaps consider to make a plot or Table to show fully observation plan in one day (like Fig 7 but also showing time on calibrator), including targets and calibrators and showing time executing observation
At present, the function of placing the target source and its required calibration source on the same canvas has not been realized, and the corresponding calibration source is manually inserted into the observation schedule after obtaining it. The observation of the target-calibration source is explained in detail in Chapter 4.2.
- Table 2 explain what is the altitude difference angle - is it difference in elevation angle in one day?
The difference angle represents the difference between the maximum and minimum elevations of the target within 24 hours. This description has been added.
- Fig 9 x-axes units ; if 4 antennas already operational is in this array, mark them in different color
The array is a subsequently upgraded one and does not include the four antennas that are already in operation. The upgraded array is expected to be constructed 180 kilometers away from this four - telescope array.
- Fig 10 – Fixed axes scale will allow beater to see improvement over time, it will also make it consistent with Fig 12 style.
Fig 10 has been corrected in units.
- Fig 17 – Not loaded
This figure has been added.
Reviewer 3 Report
Comments and Suggestions for Authors
Referee report on “A OBSERVATION SCHEDULING SYSTEM FOR RADIO
TELESCOPE ARRAY” by Ma Chi, Zhao Rushuang, Lao Baoqiang, Xiao Wenjun, Liu Hui, You Ziyi
- submitted title: “A RADIO SOURCES OBSERVATION PREDICTION SYSTEM
FOR TELESCOPE ARRAY”
In this paper, the authors present their new design and development of a radio sources observation prediction system for the telescope array at Guizhou Normal University. With this, they aim to create a fully functional and highly adaptable target prediction system. The authors have used Python and PyQt5 for a modular design approach. The system is designed with four modules and the most important is the uv coverage module.
Some general comments:
The paper is well organized, the writing style is clear and understandable. Although I have some comments and suggestions.
Title: Check the grammar in the title, please.
Abstract: Clarify or specify that You have developed this system. And what gives it in the results.
The system software: The authors have not specified is their designed system is actually a software, code and etc.? If it’s tested by the results of the two pulsars, could it have accepted as a verification?
References: Check [23] in the reference list.
Comments in detail:
Comment 1. Row 29: Here "uv coverage" is mentioned for the first time and my suggestion is: Although, it is clear and known for the specialists in the radio-telescopes, I think it could be useful if you add few words explanation, or just to mention that it is related to the uv coordinates transformation.
Comment 2. Row 64: "next 24 hours" – it should be clearer if “next” is replace with other word or just explain.
Comment 3. Equation 1: It is not clear how it is obtained. If it is from the known usual mathematical relations, maybe you should write 2-3 words to mentioned this.
Comment 4. Row 285: Isn’t it “Columns 1 to 3”?
Comment 5. Figures 12 and 14: Where the negative values in X axis are coming from? It is not very clear. Perhaps it is obvious, but I think you should give some short explanation of this.
Comment 6. Figures 17 and 18: The “Intensity” axis: Since the dimensions are missing, is it a ratio? Or it is a part of the whole value? Specify this in the text.
Comments for author File: Comments.pdf
Author Response
Thank you for your valuable comments.
Some general comments:
The paper is well organized, the writing style is clear and understandable. Although I have some comments and suggestions.
Respond: Thanks for your helpful comments and suggestions, we have taken them into consideration to make significant modifications to the paper.
Title: Check the grammar in the title, please.
Respond: We have checked the grammar in the title, and changed it to 'AN OBSERVATION SCHEDULING SYSTEM FOR RADIO TELESCOPE ARRAY'.
Abstract: Clarify or specify that You have developed this system. And what gives it in the results.
Respond: We have clarified in the Abstract that we developed this system and presented the results.
The system software: The authors have not specified is their designed system is actually a software, code and etc.? If it’s tested by the results of the two pulsars, could it have accepted as a verification?
Respond: In the 'Discussion and conclusion' section, we have clearly specified that our system is a software. And yes, we think the successful detection of two pulsars shows that we have predicted the position of pulsars crrectly in the sky, which means our software is effective.
References: Check [23] in the reference list.
Respond: This reference has been corrected.
Comments in detail:
Comment 1. Row 29: Here "uv coverage" is mentioned for the first time and my suggestion is: Although, it is clear and known for the specialists in the radio-telescopes, I think it could be useful if you add few words explanation, or just to mention that it is related to the uv coordinates transformation.
Respond: Thanks for your suggestion. We have added the following description to clarify the uv coverage:
'The uv coverage represents the coordinate points of u and v on the uv plane, which are determined by transforming the coordinates of the baselines of the telescope array. Here, the line connecting each pair of telescopes in the array is called a baseline.'
Comment 2. Row 64: "next 24 hours" – it should be clearer if “next” is replace with other word or just explain.
Respond: We have replaced it with 'upcoming' or 'following'.
Comment 3. Equation 1: It is not clear how it is obtained. If it is from the known usual mathematical relations, maybe you should write 2-3 words to mentioned this.
Respond: For Equation 1, we used the mathematical relations from Reference [8]. To clarify it, we have added this reference in the context of Equation 1.
Comment 4. Row 285: Isn’t it “Columns 1 to 3”?
Respond: Yes, this has been fixed.
Comment 5. Figures 12 and 14: Where the negative values in X axis are coming from? It is not very clear. Perhaps it is obvious, but I think you should give some short explanation of this.
Respond: Yes, the problem has been explained in the text.
Comment 6. Figures 17 and 18: The “Intensity” axis: Since the dimensions are missing, is it a ratio? Or it is a part of the whole value? Specify this in the text.
Respond: Yes, we should describe the "Intensity" axis with more details. Since we can not do the calibration right now, we just use the pazi package in psrchive software (Hotan et al. 2004). And the Intesity stands for the relative flux density.
Author Response File: Author Response.pdf
Round 2
Reviewer 1 Report
Comments and Suggestions for AuthorsThe orginal concern still stand. Many of the points still are not adressed, like e.g. proper descriptions ofd the figures. The article is clearly still in flux, and should only be submitted once complete
Author Response
Comments and Suggestions for Authors
The orginal concern still stand. Many of the points still are not adressed, like e.g. proper descriptions ofd the figures. The article is clearly still in flux, and should only be submitted once complete
Thanks for your comments, we have update the drift according to your comments. Please check the content in the text.
Reviewer 2 Report
Comments and Suggestions for AuthorsThanks for a quick and precise improvements for article.
Experiential about expanding about telescope array
As final thing, I suggest to add also the GitHub link in this paper for readers to more easy find and access it.
In my opinion it will greatly improve visibility of this software and can increase expected amount of citations
Author Response
Comments and Suggestions for Authors
Thanks for a quick and precise improvements for article.
Experiential about expanding about telescope array
As final thing, I suggest to add also the GitHub link in this paper for readers to more easy find and access it.
In my opinion it will greatly improve visibility of this software and can increase expected amount of citations.
Thanks. We have added the Github link in the Discussion and conclusion section.
Round 3
Reviewer 1 Report
Comments and Suggestions for AuthorsMy orginal concern still stands, that this is more of technical description than a scientift paper, due to the lack of actually new capabilities in the software presentet. This cannot be changed with edits to the text but would require more research work. Given that the paper is still written in an accetable manner. If the journal acceptes the issue raised above it can be published.