VEGAS Pulsar Modes Manager


1. Introduction

The VEGAS Pulsar Modes Manager (still called the VEGAS Manager) is an adaptation of the previously existing VEGAS Manager (for spectral line modes) to process pulsar modes. To adapt the Manager for Pulsar Modes, new parameters and backends (see below) were added to the original VEGAS Manager, as well as other assorted changes to make everything work in concert.

Many of the parameters and behavior of the VPM Manager were adapted from the GUPPI Manager and the DIBAS dealer/player software. These were adapted to function within the context of the original VEGAS Manager.

2. Parameters

These are the parameters to be added to the Vegas Manager for inclusion of the Pulsar modes. Many of these were taken from the GuppiBackend.py (incoherent) and GuppiCODDBackend.py (coherent) files of DIBAS. Included are their types in a C++ context.
Parameter Type Inco/Coh Range Units Description
cal_freq float Both >=0.0 Hz Frequency of switching noise diodes (1/SWPER)
dm float Coherent >=0.0 parsecs/cm^3 Dispersion measure for COHERENT_SEARCH mode
feed_polarization enum Both LIN/CIRC none The type of feed polarizaiton
fft_info struct Coherent values >= 0 none fft_len, overlap, blocsize
integration_time float Both >=0.0 sec Integration time
nbin int Both >=0.0 none Number of bins in a pulse profile for cal and fold modes
obs_frequency float Both >=0.0 MHz Center frequency of observing band
obs_mode string Both COHERENT_{SEARCH, FOLD, CAL}, RAW none Observing mode
only_i bool Both true, false none Whether to 'record only summed polarizations' (true) or full stokes data (false)
par_file string Both   none Pulsar profile ephemeris file
rf_frequency float Both >=0.0 MHz A reference frequency
scale float Incoherent 0.0 - 65535.99998 none For setting all incoherent scaling factors to one parameter
scale_p0 float Coherent 0.0 - 65535.99998 none Hardware scaling factor for the p0 polarization
scale_p1 float Coherent 0.0 - 65535.99998 none Hardware scaling factor for the p1 polarization
tbin float Both >=0.0 sec Actual integration time
tfold float Both >=0.0 sec Software integration time per profile for all folding and cal modes
The following are so-called metadata parameters. Not actual parameters of the manager, but important values to be written to FITS files.
  • observer (e.g. Bob Dole)
  • major_coord (RA)
  • minor_coord (Dec)
  • telescope (i.e. GBT)
  • receiver (i.e. Rcvr1_2)
The values projectid and source also need to be written, but these are already parameters of the Manager base class. The guppi_daq_server should handle the other metadata

3. Backends

The VEGAS Manager uses a strategy pattern of Backend classes. These classes handle mode specific calculations and behavior, specific to a certain class of modes. The VEGAS Manager stores a Backend object for each individual mode (specified in a config file), and each object handles the behavior for that specific mode. The methods of the Backend class include public getter and setter methods. The getter methods are often overridden by subclasses, for mode-specific calculations. The setter methods often double as check methods, ensuring a parameter can be adequately set. The Backend class itself is a virtual class which can't completely handle the behavior of any single mode.

The below diagram shows the inheritance tree for the Backend classes. The italic text are for virtual classes, not designed to be instantiated. The underlined text are the creatable Backends corresponding to actual modes.

VegasStrategy.png

PulsarBackend and SpectralBackend split the basic functionality between these two types of modes. IncoherentBackend and CoherentBackend specify the parameter behaviors/dependencies for these modes. The FastBackend class simply adds some more specific functionality to the IncoherentBackend class.

4. HPC Programs

The VEGAS Manager originally handled the execution of an HPC program called the vegas_hpc_server, which can handle calculations for spectral line modes. However, we also need to handle these calculations for pulsar modes. For the time being, we do this by additionally making use of the guppi_daq_server program. The vegas_hpc_server does not write FITS files, so for spectral line modes, the VEGAS Manager must write the FITS files using a VegasFitsIO interface. The guppi_daq_server has a built-in FITS writer, for the special PSR FITS format. This means that the VEGAS Manager does NOT need to write FITS files in these pulsar modes.

Whenever the mode is changed, the current HPC/DAQ program is stopped, and the appropriate HPC/DAQ program is restarted.

5. Status Memory

The guppi_daq_server is super picky about its status shared memory, and must have appropriate values for several fields in order to do its job. The following is a list of the status memory values which are used for the mode i1500x0064. As scans are run, the guppi_daq_server reads these values from status shared memory, and writes its own values to the same memory buffer.
ACC_LEN : 512 BACKEND : GUPPI
BANKNAM : BANKA BASE_BW : 1450
BLOCSIZE : 0 CAL_DCYC : 0.5
CAL_FREQ : 25 CAL_MODE : ON
CHAN_BW : 23.4375 CHAN_DM : 0
DAQPULSE : Mon Jun 22 11:46:59 2015 DAQSTATE : stopped
DATADIR : . DATAHOST : 10.17.0.86
DATAPORT : 60000 DS_FREQ : 1
DS_TIME : 1 FD_POLN : LIN
FFTLEN : 0 NBIN : 256
NBITS : 8 NPOL : 4
NRCVR : 2 OBSBW : 1500
OBSERVER : unknown OBSFREQ : 1500
OBSNCHAN : 64 OBS_MODE : CAL
OFFSET0 : 0 OFFSET1 : 0
OFFSET2 : 0 OFFSET3 : 0
ONLY_I : 0 OVERLAP : 0
PARFILE : /home/sim/etc/config/example.par PFB_OVER : 12
PKTFMT : 1SFA POL_TYPE : IQUV
PROJID : JUNK SCALE0 : 1
SCALE1 : 1 SCALE2 : 1
SCALE3 : 1 SCANLEN : 60
SRC_NAME : unknown TBIN : 2.18453e-05
TELESCOP : GBT TFOLD : 1

6. Coherent Modes

In Coherent modes, there is an extra level of organization required. In these modes, one bank (the master) is required to handle the processing of the other banks. The bandwidth is divided up between each bank, with each handling the processing of its own "node bandwidth". This requires an extra listing in these coherent mode sections of the config file. The cdd_hpcs, and cdd_master_hpc keys determine the running nodes, and the corresponding roach ports. The cdd_master_hpc key specifies the master bank, which controls the roach.

-- JustinRichmondDecker - 2015-05-19
Topic attachments
I Attachment Action Size DateSorted ascending Who Comment
VegasStrategy.pngpng VegasStrategy.png manage 16 K 2015-06-22 - 13:15 JustinRichmondDecker Strategy Pattern for Vegas Backends
Topic revision: r5 - 2015-06-22, JustinRichmondDecker
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback