pipeline.hifv.tasks.priorcals package¶
Submodules¶
pipeline.hifv.tasks.priorcals.opacitiesdisplay module¶
pipeline.hifv.tasks.priorcals.priorcals module¶
Example usage:
inputs = pipeline.vla.tasks.priorcals.Priorcals.Inputs(context) task = pipeline.vla.tasks.priorcals.Priocals(inputs) result = task.exectue(dry_run=False) result.accept(context)
-
class
pipeline.hifv.tasks.priorcals.priorcals.Priorcals(inputs)[source]¶ Bases:
pipeline.infrastructure.basetask.StandardTaskTemplate-
Inputs¶ alias of
PriorcalsInputs
-
analyse(results)[source]¶ Determine the best parameters by analysing the given jobs before returning any final jobs to execute.
- Parameters
jobs (a list of
JobRequest) – the job requests generated byprepare()- Return type
Result
-
-
class
pipeline.hifv.tasks.priorcals.priorcals.PriorcalsInputs(context, vis=None, tecmaps=None, swpow_spw=None)[source]¶ Bases:
pipeline.infrastructure.vdp.StandardInputs-
swpow_spw¶ VisDependentProperty is a Python data descriptor that standardises the behaviour of pipeline Inputs properties and lets them create default values more easily.
On reading a VisDependentProperty (ie. using the dot prefix: inputs.solint), one of two things happens:
If a NullMarker is found - signifying that no user input has been provided - and a ‘getter’ function has been defined, the getter function will be called to provide a default value for that measurement set.
If a user has overridden the value (eg. inputs.solint = 123), that value will be retrieved.
The value, either the default from step 1 or user-provided from step 2, is run through the optional postprocess function, which gives a final opportunity to change the value depending on the state/value of other properties.
A VisDependentProperty can be made read-only by specifying ‘readonly=True’ when creating the instance.
A VisDependentProperty can be hidden from the containing Inputs string representation by setting ‘hidden=True’ when creating the instance. This will hide the property from the web log and CLI getInputs calls.
Each VisDependentProperty has a set of values it considers equivalent to null. When the user sets the VDP value to one of these null values, the VDP machinery converts this to a private NullObject marker that signifies the property is now unset, resulting in the default value being returned next time the property is read. Developers can specify which values should be converted to NullObject by specifying null_input at creation time, e.g.,
solint = @VisDependentProperty(default=5, null_input=[None, ‘’, ‘RESET’, -1])
-
tecmaps¶ VisDependentProperty is a Python data descriptor that standardises the behaviour of pipeline Inputs properties and lets them create default values more easily.
On reading a VisDependentProperty (ie. using the dot prefix: inputs.solint), one of two things happens:
If a NullMarker is found - signifying that no user input has been provided - and a ‘getter’ function has been defined, the getter function will be called to provide a default value for that measurement set.
If a user has overridden the value (eg. inputs.solint = 123), that value will be retrieved.
The value, either the default from step 1 or user-provided from step 2, is run through the optional postprocess function, which gives a final opportunity to change the value depending on the state/value of other properties.
A VisDependentProperty can be made read-only by specifying ‘readonly=True’ when creating the instance.
A VisDependentProperty can be hidden from the containing Inputs string representation by setting ‘hidden=True’ when creating the instance. This will hide the property from the web log and CLI getInputs calls.
Each VisDependentProperty has a set of values it considers equivalent to null. When the user sets the VDP value to one of these null values, the VDP machinery converts this to a private NullObject marker that signifies the property is now unset, resulting in the default value being returned next time the property is read. Developers can specify which values should be converted to NullObject by specifying null_input at creation time, e.g.,
solint = @VisDependentProperty(default=5, null_input=[None, ‘’, ‘RESET’, -1])
-
-
pipeline.hifv.tasks.priorcals.priorcals.correct_ant_posns(vis_name, print_offsets=False)[source]¶ Given an input visibility MS name (vis_name), find the antenna position offsets that should be applied. This application should be via the gencal task, using caltype=’antpos’.
If the print_offsets parameter is True, will print out each of the found offsets (or indicate that none were found), otherwise runs silently.
A list is returned where the first element is the returned error code, the second element is a string of the antennas, and the third element is a list of antenna Bx,By,Bz offsets. An example return list might look like: [ 0, ‘ea01,ea19’, [0.0184, -0.0065, 0.005, 0.0365, -0.0435, 0.0543] ]
Usage examples:
CASA <1>: antenna_offsets = correct_ant_posns(‘test.ms’) CASA <2>: if (antenna_offsets[0] == 0): CASA <3>: gencal(vis=’test.ms’, caltable=’cal.G’, caltype=’antpos’, antenna=antenna_offsets[1], parameter=antenna_offsets[2])
This function does NOT work for VLA datasets, only EVLA. If an attempt is made to use the function for VLA data (prior to 2010), an error code of 1 is returned.
The offsets are retrieved over the internet. A description and the ability to manually examine and retrieve offsets is at: http://www.vla.nrao.edu/astro/archive/baselines/ If the attempt to establish the internet connection fails, an error code of 2 is returned.
Uses the same algorithm that the AIPS task VLANT does.
bjb nrao spring 2012
Update: BJB NRAO Spring 2020 (fixed version)
pipeline.hifv.tasks.priorcals.qa module¶
-
class
pipeline.hifv.tasks.priorcals.qa.PriorcalsListQAHandler[source]¶ Bases:
pipeline.infrastructure.pipelineqa.QAPluginQA handler for a list containing PriorcalsResults.
-
child_cls¶ alias of
pipeline.hifv.tasks.priorcals.resultobjects.PriorcalsResults
-
generating_task¶
-
result_cls¶ alias of
collections.abc.Iterable
-
-
class
pipeline.hifv.tasks.priorcals.qa.PriorcalsQAHandler[source]¶ Bases:
pipeline.infrastructure.pipelineqa.QAPlugin-
child_cls= None¶
-
generating_task¶
-
result_cls¶ alias of
pipeline.hifv.tasks.priorcals.resultobjects.PriorcalsResults
-
pipeline.hifv.tasks.priorcals.renderer module¶
Created on 24 Oct 2014
@author: brk
-
class
pipeline.hifv.tasks.priorcals.renderer.T2_4MDetailspriorcalsRenderer(uri='priorcals.mako', description='Priorcals (gaincurves, opacities, antenna positions corrections, rq gains, and switched power)', always_rerender=False)[source]¶ Bases:
pipeline.infrastructure.renderer.basetemplates.T2_4MDetailsDefaultRenderer
pipeline.hifv.tasks.priorcals.resultobjects module¶
-
class
pipeline.hifv.tasks.priorcals.resultobjects.PriorcalsResults(final=None, pool=None, preceding=None, gc_result=None, oc_result=None, rq_result=None, antpos_result=None, antcorrect=None, tecmaps_result=None, sw_result=None)[source]¶ Bases:
pipeline.infrastructure.basetask.Results-
merge_with_context(context)[source]¶ Merge these results with the given context.
This method will be called during the execution of accept(). For calibration tasks, a typical implementation will register caltables with the pipeline callibrary.
At this point the result is deemed safe to merge, so no further checks on the context need be performed.
-