The AO System RTC ("RTC") Conceptual Design Post-Conference Questions and Answers
The following are the TMT responses to the AO System RTC Post-Conference Questions:
Q. Will the competition be re-opened after the Conceptual Design Study?
A. TMT is planning that the next phase of this procurement will be competitive and open to qualified bidders. Teams satisfactorily completing Conceptual Design Study contracts will automatically be qualified to bid in the next phase
____________________
Q. Will TMT provide hardware or additional funding to support benchmarking?
A. No, any hardware must be provided by the supplier within their study budget.
____________________
Q. Can TMT distribute a copy of their AO simulation tool ( LAOS) to provide additional description of the control algorithms?
A. We will distribute copies of the routines and code segments which will be useful for this purpose.
____________________
Q. Will there be a single baseline control algorithm by the time of the RFP?
A. No, the options described at the suppliers’ conference will probably still be retained. The current “error bars” in quantifying the AO performance of these algorithms are probably similar to the estimated differences in their performance, particularly when the effect of finite precision arithmetic and the range of options for phase screen grids are considered. Performance assessment of the various algorithms and these options will continue during the conceptual design study.
____________________
Q. How far should suppliers down-select the choice of control algorithms in their proposal?
A. Proposing to study all possible algorithms is not recommended. Suppliers should propose to study a modest subset of algorithms which are well matched to their proposed hardware options.
____________________
CLARIFICATION: Proposals will be due in 30 business days following the RFP, or in about six weeks.
____________________
CLARIFICATION: TMT is open to proposals with Conceptual Design Study durations from 6 to 9 months.
____________________
Q. How much benchmarking is expected during the Conceptual Design Study?
A. Suppliers will need to judiciously balance the effort invested in benchmarking against the development of the design. Only the most time-critical computations and I/O processes should be considered for benchmarking.
____________________
Q. Are suppliers expected to perform AO simulations?
A. No, but we welcome Supplier advice on what types of simulations should be performed at the TMT project office, and also their assistance in interpreting the results. All simulation results generated at TMT will be shared with both studies.
____________________
Q. Is TMT interested in hearing about new algorithms as part of this study?
A. Suppliers should focus upon studying the HW implementation of one or more of the candidate algorithms already specified in the RFP documentation, as it is simply too difficult to make progress in developing and fairly comparing the RTC HW designs if control algorithms are still in a state of flux.
____________________
Q. How will the TMT HW/SW standards apply to the RTC?
A. Some selected standards may not apply to the RTC HW, but the host part of the RTC will need to communicate to the rest of the AO control systems using the TMT Observatory Common Software API.
____________________
Q. What drives the requirement for background loop stabilization within 20 seconds?
A. The value of 20 seconds has been flown down from the overall timeline for acquiring a science target. Offloading low-order modes to the telescope and obtaining TWFS measurements with very dim guide stars may be the most challenging tasks to complete in 20 seconds. Most other computations of gains, filters, and weights should be nearing convergence after 2 updates at a rate of 0.1 Hz.
____________________
Q. Will data formats (fixed/floating, number of bits) be clarified for the study?
A. The baselines already defined on page 32 of the requirements document will be further clarified. Simulations will be performed at the TMT project office to evaluate and possibly revise these baselines, but probably not until after the start of the Conceptual Design Study.
____________________
Q. How is Latency defined?
A. See pages 31 and 32 of the requirements document
____________________
Q. The requirement for invisible mode removal is computationally challenging.
A. Please note that the invisible modes computed on cycle n need not be removed until cycle n+1. Suppliers are welcome to identify the cost savings which could be obtained by spreading the removal of the complete set invisible modes over a number m <= 16 cycles. Simulations will be performed at the TMT project office to estimate the allowable time delay in removing the invisible modes, but not until after the start of the Conceptual Design Study.
____________________
Q. On Page 108 of the TMT Presentations:"Performance Results (2)," the red numbers are understood to denote absolute wavefront errors using algorithm FD3 while the black numbers are quadrature increments (to be RSSed with FD3 wavefront error) for the other algorithms. Is that correct?
A. Yes, that is correct.
____________________
Q. Regarding the Algorithm Description, is an LTAO mode (i.e. LGS tomography w/ only DM0 fitting) desired?
A. The requirements document will be updated to indicate that implementation of an LTAO mode is required. If possible, it should be implemented by simply adjusting the parameters used in those steps which compute or operate upon the DM actuator command vector, including: the DM fitting step, the pseudo-open loop gradient computation, and the wavefront correction steps.
____________________
Q. Regarding the Requirements Document, REQ-3-NRTC-0590 REQ-3-NRTC-0595/0610 End-To-End Latency: On what basis are the 1000 msec requirement and 400 msec strong goal derived: discrete-time plant delay (i.e. transfer function relative order) of either 1 or 2 frames, perhaps? Within that time period, must the DM commands have been sent to DME or merely computed?
A. The latency requirements are based upon the total closed loop delay (including the LGS WFS integration time), which is between 1 and 2 frames when the DM computation latency is 400 msec and which is slightly over 2 frames when the DM computation latency is 1000 msec.
During that time period the DM commands are only computed, but are not yet transferred to the DME. The maximum latency allowed to transfer the DM commands to the DME is 10 msec.
____________________
Q. Regarding the Requirements Document, REQ-3-NRTC-0590 REQ-3-NRTC-0590/0595/0600 LGS AO End-To-End Latency: Separate latency requirements are given for pixel digitization to gradient computation, gradient computation to DM command, and gradient computation to LGS pointing. Can these effectively be combined into fewer requirements, or is there an external factor that drives the latency of gradient computations themselves?
A. Yes, these latency requirements could have been combined into fewer requirements. If necessary, suppliers may address this in their requirements compliance matrix generated as part of the study if the total end-to-end latency is still met.
____________________
Q. Regarding the Requirements Document, REQ-3-NRTC-0590 REQ-3-NRTC-0605/0610 NGS AO End-To-End Latency: Separate latency requirements are given for pixel digitization to gradient computation and gradient computation to DM command. Can these effectively be combined into a single requirement, or is there an external factor that drives the latency of gradient computations themselves?
A. Same answers as for the LGS AO End-To-End Latency
____________________
Q. Regarding the Requirements Document, REQ-3-NRTC-0715: The RTC shall include very high-level high bandwidth, flexible real time display tools. Is the scope of this requirement covered by the specific items/rates listed under REQ-3-NRTC-0720? Or, can you elaborate further on this requirement?
A. Yes, the scope of REQ-3-NRTC-0715 is essentially covered by REQ-3-NRTC-0720, although suppliers are invited to suggest other displays that they consider to be useful. Regarding the use of the word “flexibility” in REQ-3-NRTC-0715, the display tool should utilize standard windowing techniques to allow flexible selection, sizing, and positioning of the individual displays.
____________________
Q. Regarding the Requirements Document, REQ-3-NRTC-0730 [We think that you must mean REQ-3-NRTC-0725]: The RTC shall support remote user interfaces and remote real time displays
a) Does this requirement imply that all display tools referenced in REQ-3-NRTC-0715 and REQ-3-NRTC -0720 should all operate remotely?
A(a). Yes. Some TBD reduction in display bandwidth is acceptable, but transmitting full screen images to remote displays should be avoided.
b) How will remote displays be networked to the RTC? Will the supplier furnish the network, or will it utilize existing network infrastructure in the TMT facility?
A(b). The RTC supplier will utilize TMT network infrastructure
c) Should display tools run on supplier furnished equipment, or is it the intent for them to run on a common platform?
A(c). Display tools and engineering user interfaces shall be able to run on the TMT standard platforms specified in REQ-1-OAD-9715, which currently includes Unix and Linux variants.
____________________
Q. Regarding the Requirements Document, REQ-3-NRTC-0780 - Boot from cold start in less than 30s: Does that mean that all loops are closed within 30 seconds of being powered up? What is driving this requirement?
A. No, it means that the RTC shall be booted and set in a default configuration in 30 seconds. This time does not include the time for acquiring or closing the loops.
____________________
Q. Regarding the Requirements Document, REQ-3-NRTC-0795 – able to work in simulation mode: Can you elaborate on this requirement? Is this meant to be a non-real-time mode where the RTC interfaces to an external simulation of the telescope? Or, must the RTC include its own simulation models of the telescope optics and actuators? Is there a requirement for how fast it needs to run?
A. We will rewrite this requirement. “Simulation mode” was not intended in the sense of a closed-loop AO simulation. There will be two simulation modes:
- low level simulation mode, where input streams to the RTC are simulated; in particular, predefined WFS spots images are generated by the RTC and used to test the wavefront reconstruction algorithms
- high level simulation mode where the interface with the AO Sequencer is simulated.
____________________
Suppliers are encouraged to check this page regularly for any modifications, additions or new information regarding the TMT AO System RTC Conceptual Design.
Thank You,
The TMT Project
|
