Add Config Tool support for Spigot and Multiple Backend Configurations

Modification Request #7 (C07 2005)

1. Introduction

The configuration tool currently supports configuration of several backends: SpectralProcessor, Spectrometer, Vlbi, Radar, GASP, JPL, DCR, LLRadar as well as the BCPM/SPIGOT dual backend configuration. Currently only one backend can be configured within a configuration script (the DCR is the obvious exception to this rule).

Pulsar observers have requested that multiple backend configurations be supported by the configuration tool. Although the M&C system does not support multiple backend observations, most of the pulsar backends run outside of the normal M&C system and are not restricted by this limitation. The config tool is not severely limited by the lack of support of multi-backend modes within the M&C. IFpaths can be routed for multiple backends and parameters in the individual managers can be set. For the most part, multiple backend setups can be viewed as several single independent backend setups within a config script. The major differences between multiple backend and single backend configurations within the config tool are: ifpath routing such that the Converter Modules, freq converters etc. are not reused, the Switching Signals Master selection, the Scan Coordinators subsystemSelect selections, conflicting dependencies between backends, conflicting dependencies between backends and other keywords, and the validation for keywords like bandwidth in multi backend configurations.

Pulsar observing has become more integrated into the mainstream GBT observing process. Ease of configuration for observations has become no less important for pulsar observers as for other types of observers. With this goal in mind, and despite the fact that the M&C system does not support dual backend observations nor the spigot, the configuration tool will be modified to support the spigot stand alone and multi backend configurations.

2. Background

Initial configuration tool pulsar backend support was for a BCPM/SPIGOT tandem configuration. Support for the pulsar backends CGSR2 and GASP was added quickly in order to facilitate observations that were scheduled that week or even that evening. No MR's were written and the work was done on a "as time permits" basis. "I'll see what I can do in an hour" was the modus operandi. Thus, there is not a clearly defined record of the configuration requirements for many of the pulsar backends. To further muddy the waters, the BCPM/SPIGOT configuration was added to the config tool despite the fact that there was no M&C support for the SPIGOT. This is still the case. The config tool uses Spectrometer modes as spigot modes although in reality they are not equivalent. Spigot and spectrometer modes differ with respect to the ports used, the spectrometer mode required for a given set of meta keyword values and the validity of cross polarization modes. To support BCPM/SPIGOT configuration the configuration tool uses the "known" spectrometer configurations in place of the unknown spigot modes. This effectively routes the required paths to the required ports, but it does it by using twice the number of windows specifed by the user. Thus, the configuration tool must routes twice the number of ifpaths actually required for any spigot configuration. As yet, this has not been an issue, but could easily become one if there are converter module failures. Futhermore ACS cross polarization support was added to the configuration tool last cycle (5.6). No attempt was made to validate the spigot/cross polarization modes within the configuration tool, yet cross polorization is not supported in the spigot. It is unknown what the impact to the data would be if the user inadvertently selected cross polarization for a SPIGOT observation. This is an issue that can be resolved if the config tool is modified to configure the SPIGOT as an individual backend, distinct from the spectrometer.

The main stumbling block to implementing the stand alone spigot configurations is the lack of information concerning which ports the SPIGOT requires, legal modes, mode selections and cross polarization validty for each mode. A list of valid spigot modes with their associated ports and the validity of the cross polarization for each mode is necessary in order to complete the MR succesffully.

3. Requirements

Add SPIGOT as a legal backend in the config tool.
- The configuration should result in the same configuration as the BCPM/SPIGOT option except no BCPM specific parameters are set in the M&C system.
  - The switching signls master will be set to the DCR for the SPIGOT backend option.
- Spectrometer setup
  - Only 1 window mode (nwin = 1) will be supported
  - Setting the numbanks for SPIGOT configurations will no longer be required but if it numbanks is set to '2', the resulting configuration will be the same as if it was not specified. (A1_B1 mode, as specfied below)
  - All values for nchan (low, medium and high) will result in the same configuration:A1_B1
  - The samplers used in configurations whose bandwidth is 200 or 800 will be fast samplers 1 and 4
  - The samplers used in configurations whose bandwidth is 12.5 or 50 will be slow samplers 9 and 21 or 25 and 37 depending on the beam and receiver selected
  - Scripts specifying cross polarization will result in the error message: "The chosen spectrometer polarization mode is not supported with this setup." No configuration of the telescope will be performed.
  - Scripts specifying multibeam configurations (beam choice of 'B12' or 'B34' or 'B1234') will result in the error message: ERROR: This spectrometer mode is not supported." No configuration of the telescope will be performed.

Add multiple backend end support to the config tool. The config tool will not change with respect to the existing feature that configures the DCR backend for every setup. The DCR will always be set up no matter what the specified backend(s) is. It will not be necessary to include the DCR as a backend unless it is the only backend in the configuration.
- Multiple backend configurations will be specified by setting the backend keyword to BACKEND_1/BACKEND_2/BACKEND_N. For the remainder of the document, BACKEND_1/BACKEND_2/BACKEND_N will be referred to as the "backendString".
  - Example:
```
  g.backend = 'GASP/CGSR2/SPIGOT' 
```
    results in the configuration of 3 backends, GASP, CGSR2 and the SPIGOT.
- All backends in the backendString that are legal subsystems in the ScanCoordinators device list will selected in the ScanCoordinator. These backends are 'SpectralProcessor', 'Spectrometer', 'BCPM', 'DCR'. The DCR will be added to the ScanCoordinator for the DCR_AF backend option. If any other backends are included, the DCR will also be included in the ScanCoordinator.
- If any of the backends in the backendString requires the DCR as the switching signal master in a single backend configuration, then the switching signals master will be set to the DCR in the multi backend configuration. The backends requiring the DCR as the switching signals master are: GASP', 'CGSR2', 'SPIGOT', 'BCPM/SPIGOT', 'LLRADAR', and 'BCPM'.If no backend requires the DCR as the switching signal master, then the LAST backend in the string that is a legal switching signal master will be used as the master.
- Validation:
  - Consistency validation between keyword values will be performed only on the last backend in the backendString. This allows the config tool to do meaningful validation but allows the user to setup mutliple backends with keyword values that would normally be inconsistent. This can best be explained by example.
    - Ex: ' backend = 'SpectralProcesor/Spectrometer'. Validation for consistency between keywords will only be performed for the Spectrometer because consistency checks for all keywords with multiple backend setups would be too restrictive. In this example, the legal Spectral Processor bandwidths are 40, 20, 10, 5, 2.5, 1.25, 0.625, 0.3125, 0.15625, and 0.078125 while the legal Spectrometer bandwidths are 12.5, 50, 200 and 800. There is no intersection between the 2 sets of bandwidths. If the config tool performed consistency checks for all backends in the backendString, this backend tandem would be illegal and the configuration would not be allowed. In fact, this would occur for several other backend combinations as well.
  - Validation of required backend specific keywords will be performed for each backend in the backendString. Any missing keywords will be considered an illegal configuration and no configuration of the telescope will be performed.

4. Design

SPIGOT Single Mode Backend Configuration:
- Add items to the database as required for the SPIGOT backend
- Create SPIGOT class that inherits from Spectrometer class.
- Add SPIGOT dictionaries for SPigot modes and ports.
Multi backend mode
- Create required dictionaries and hierarchies to determine switching signals master in multi backend configurations
- Change validation code as required to support SPIGOT and multi backend modes.
- Add getting db items for multi backends within one configuration.

5. Deployment Checklist

Normal M&C test, release and build procedures should be sufficient.

6. Test Plan

NOTE: Warnings about bandwidths are OKAY. Errors that report not being able to find paths are NOT!

Test Suite 1: Pulsar multi backend configurations

Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/CGSR2_w_SPIGOT.py. Verify that no errors occur.
Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/GASP_w_CGSR2_w_SPIGOT.py. Verify that no errors occur.
Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/SPIGOT_w_CGSR2_w_GASP.py. Verify that no errors occur.
Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/CGSR2_w_SPIGOT_w_GASP.py. Verify that no errors occur.
Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/GASP_w_SPIGOT.py Verify that no errors occur.
Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/SPIGOT1.py Verify that no errors occur.
Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/SPIGOT2.py Verify that no errors occur.

Test Suite 2: Spigot backend configurations

Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/SPIGOT1.py. Verify using the test Pulsar that the expected pulsar data occurs.
Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/SPIGOT2.py. Verify using the test Pulsar that the expected pulsar data occurs.
Run the configuration script /users/mmello/trunk/gbt/user/config_tool/scripts/5.7Tests/bcpmSpigot.py. Verify that no errors occur. occurs.(regression test)

Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the SDD delivers exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Status

Written	MelindaMello - 3 Oct 2005
Checked	MarkClark - 17 Oct 2005
Approved/Signed by Sponsor	ScottRansom - 17 Oct 2005
Approved/Signed by CCC	symbol - date
Accepted/Delivered	ScottRansom - 29 Oct 2005

Symbols:

Use %X% if MR is not complete (will display )
Use %Y% if MR iscomplete (will display )

CCC Discussion Area

-- MelindaMello - 03 Oct 2005

Topic ModificationRequest7C705 . { Edit | Attach | Ref-By | Printable | Diffs | r1.12 | > | r1.11 | > | r1.10 | More }

Revision r1.12 - 29 Oct 2005 - 17:48 GMT - ScottRansom	Content copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.


NRAO Home > Green Bank \| Wiki Topic: GB > Software > ModificationRequest7C705

Changes \| Index \| Contents \| Search \| Statistics \| Go