==> DFS COMPONENT NAME: Masktracker ==> DFS COMPONENT RELEASE NUMBER: 2.5.3 ==> DFS RELEASE TYPE: major ==> DELIVERED BY: User Support Systems team ON: 27-Mar-03 ==> MAIN REASON OF THE DELIVERY: This is the official Masktracker 2.5 release. MaskTracker 2.5.2 [2247] Added OB ID to the list of available columns [2246] MaskDiscarded OB's are not visible from within the MaskQueue execution sequence on the MaskDiscarded tab [2245] When appending an ob to a Masktracker queue the queue was not refreshed when the insertion tab was selected MaskTracker 2.5.2beta3 [2197] Removed telescope. FORS maybe used so InstrumentList added in MaakBrowser. These use to be textfields [2194,2193,2185] [2187] Introduced Barcode instead of Mask Id for the barcodes that are used to physically identify the masks. The Mask Id is the database id. [2195] Caused by 2 identical mask configuration for the same OB's. Exception no longer thrown [2156] When adding an OB to the execution sequence the ** now appeaar [2188] Changed label to Sorting Criteria. This exapnds the panel below causing no truncation [2159] Status change now works. Date is tranformed to the correct status [2155] Label Added to Execution Sequence for masktracker [2191] Fixed duplicated OB's are not allowed in the Execution Sequence for VIMOS [2194,2193,2185 fixed by 2184] Added Optinos menu to Masktracker Repository Browser and OT Repository Browser. This involved adding new keywords into the site.cf file to point to the config files for masktracker:- MTREPOSITORYBROWSER.CONFIG.CONFIGMENU && MTQUEUEVIEW.CONFIG.CONFIGMENU "mtqv-helper.cf" [2074] Ask for confirmation when updating mask status from within Mask Queue [2081] Check OT increments Mask count when executing an OB correctly Exec count now in Mask Browser. VIMOS Configuration VIMOS procedures on mask management =================================== 1- Basic assumptions: ---------------------- 1.1- The mask status is known only to Paranal via the local repository. This information is not replicated to Garching. 1.2- Changes in mask status need queues that are loaded by the Mask Tracker. USG will provide the master queues allowing these operations, which will be handled by Paranal based on the locally available information on the mask status. 1.3- VM runs need to provide at least a subset of OB in advance to their arrival at Paranal, no less than two weeks before the beginning of their run provided that preimaging has been obtained and distributed to the user at least six weeks in advance.These OBs are certified by USG. 1.4- The capacity of the storage cabinet is sufficient to allow the storage of all masks manufactured for a given run until the run is declared completed or terminated. This assumption seems to be valid for Period 71 based on the currently available Phase 1 information, and may need to be reviewed in future Periods. 2- Mask manufacturing --------------------- 2.1- Service Mode: 2.1.1- Every day USG delivers the Service Mode daily queues (SMTS) as for all other instruments. 2.1.2- These queues are loaded by the daytime astronomer in the mask tracker each afternoon after 14:00 local time. 2.1.3- The daytime astronomer checks which OBs in each queue do not have a mask yet and sends a manufacturing order for these masks. 2.2- Visitor Mode: 2.2.1- Every day USG prepares a Visitor Mode queue (VMTS) containing all the VM OBs for future VM runs that have been certified so far by Garching. 2.2.2- The VMTS queue is loaded by the daytime astronomer in the mask tracker each afternoon after 14:00 local time. 2.2.3- The daytime astronomer checks which OBs in the VMTS queue do not have a mask yet and sends a manufacturing order for these masks. 2.2.4- Visitor Mode runs can order a limited number of additional masks (up to 3 per night and no less than 48 hours in advance). The manufacturing orders for these masks are handled directly by PSO by means of locally generated queues. 3- Mask discarding ------------------ 3.1- Service Mode with OBs executed normally: 3.1.1- Under normal circumstances, masks are kept in the storage cabinet until a run has been declared completed or terminated. 3.1.2- The completion/termination signal is sent by USG as is being done at present. 3.1.3- When the completion/termination signal is sent, all the OBs of that run are appended to a queue prepared by USG (VIMOS.DISCARD) that contains the OBs of all completed/terminated programs. This queue will contain normally also OBs whose masks have been already discarded, since this information is not available in Garching. 3.1.4- The VIMOS.DISCARD queue is loaded by the daytime astronomer in the mask tracker each afternoon after 14:00 local time. 3.1.5- The daytime astronomer checks which OBs in the VIMOS.DISCARD queue still have masks stored, and sends a discard order for these masks. 3.2- Service Mode OBs with faulty masks: If the mask associated to a SM OB or a group of them is suspected as faulty (normally due to a preparation error by the user) it must be stored and, if confirmed faulty, discarded. The steps are as follows: 3.2.1- When a problematic mask is identified, this is notified by the night astronomer to USG in a ticket using the Night Log. 3.2.2- An order is sent by the night astronomer who encountered the problem to move the problematic mask to the storage cabinet. 3.2.3- The USG astronomer supporting the program reviews the ticket and marks the affected OBs accordingly. The new OB status depends on the nature of the problem, but in any case it will prevent the OB from appearing in the next SMTS. 3.2.4- If after reviewing the problem the cause is identified to be OB-related and not mask-related, the OB is repaired and marked as 'M' so that it appears back in the schedule. The corresponding mask will thus appear with a 'stored' status. 3.2.5- If the mask is confirmed to be faulty by USG, the OB will be cancelled. It is TBC if when this happens the OB can be reintroduced in the VIMOS.DISCARD queue (3.1.3 - 3.1.5). Independent of this, for the moment USG will communicate to Paranal (as a ticket to the PSO PRS?) that the mask needs to be discarded. 3.3- Visitor Mode: 3.3.1- Masks used by the visitor that will not be used anymore in the remaining nights are moved to the storage cabinet at the end of each VM night. 3.3.2- At the end of each VM run PSO creates a queue containing the OBs prepared for the run and sends the discarding order for their masks. This queue contains all the OBs, to ensure that masks that were manufactured but not used are also discarded. Since this queue will contain a mixture of OBs submitted to the Garching and Paranal repositories, it can be prepared only locally. 4- Mask insertion and storage ----------------------------- 4.1- Service Mode: 4.1.1- At the end of the night, the night astronomer prepares a queue containing a limited number of MOS OBs taken from both the A and B SMTS queues provided by USG, by copying them from the SMTS queues. This locally prepared queue (hereafter called VIMOS.INSERT) should require as many masks as can be accomodated in the cabinet for the next night. 4.1.2- Once the morning calibrations are completed, the daytime astronomer sends the insertion order for the masks in the VIMOS.INSERT queue that are in the storage cabinet, and the storage order of masks that are currently inserted but do not appear in the VIMOS.INSERT queue. 4.1.3- During the night, the night astronomer selects the MOS OBs to be executed from the VIMOS.INSERT queue (which contains only those OBs whose masks are inserted and thus are executable), rather than from the SMTS queues (which will generally contain OBs with non-inserted masks; the mask status is not available from the OT). 4.2- Visitor Mode: 4.2.1- The procedure is as described in 4.1, except that the contents of the VIMOS.INSERT queue is prepared based on the request of the visiting astronomer and the OBs are fetched directly from the local repository.