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.
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