Table of contents
Combined revision comparison
...
The normal utilities in DiFX are used to set up a RA correlation job.
An initial CALC9 delay model is produced by running calcif3 as usual. This initial model can then be patched to contain the replacement delay & uvw polynomial data supplied by ASC. Patching is done with https://svn.atnf.csiro.au/difx/sites/MPIfR/oneoff/raPatchClosedloop.py which takes as input the original calcif3 .im file, the ASC poly text files, and some optional parameters, and produces a new file .im.closedloop.
$ calcif3 --allow-neg-delay rk18cj_1.input $ raPatchClosedloop.py -r 2.4886e-06 RA_C_COH.TXT RA_C_COH_uvw.txt rk18cj_1.im
The raPatchClosedLoop.py script reads the input .im file and detects all delay polynomial blocks for the spacecraft. Some consistency checks are included to make sure the ASC polynomial files and the CALC9 .im are compatible (poly start time, time interval). The .im polynomial blocks are then updated such that:
- the initial delay (0th order) at scan start as predicted by CALC9 is taken from the .im file
- subsequent poly segment intervals have delay (0th order) that is based on (1) and the sum of delay changes over all earlier poly segments, i.e., poly segments are kept time-continuous across poly boundaries
- the initial rate (1th order) and higher-order poly coefficients are taken from the ASC files
- rate is adjusted by optional user-provided residual rate (option '-r <delta rate usec/sec>')
To use the new .im.closedloop file for a DiFX correlation run:
$ mv rk18cj_1.im rk18cj_1.im.openloop $ cp rk18cj_1.im.closedloop rk18cj_1.im $ startdifx --dont-calc rk18cj_1.input
The startdifx option --dont-calc is necessary to avoid potentially overwriting the closed-loop -patched .im file.
The output of correlation can be processed as usual.
Iterative improvement of the ASC poly coefficients might be necessary. Currently, we know ASC has a method to do this, but at Bonn we do not have details yet. With PIMA fringe fitting one could determine delay, rate, acceleration residuals. However how higher-order terms could be refined is yet unclear. Once we settle at a good approach, a mechanism to feed back fringe-fit results into raPatchClosedloop.py will be implemented.
Version from 12:58, 16 May 2019
...
Version as of 13:17, 16 May 2019
...
The normal utilities in DiFX are used to set up a RA correlation job.
An initial CALC9 delay model is produced by running calcif3 as usual. This initial model can then be patched to contain the replacement delay & uvw polynomial data supplied by ASC. Patching is done with https://svn.atnf.csiro.au/difx/sites/MPIfR/oneoff/raPatchClosedloop.py which takes as input the original calcif3 .im file, the ASC poly text files, and some optional parameters, and produces a new file .im.closedloop.
$ calcif3 --allow-neg-delay rk18cj_1.input $ raPatchClosedloop.py -r 2.4886e-06 RA_C_COH.TXT RA_C_COH_uvw.txt rk18cj_1.im
The raPatchClosedLoop.py script reads the input .im file and detects all delay polynomial blocks for the spacecraft. Some consistency checks are included to make sure the ASC polynomial files and the CALC9 .im are compatible (poly start time, time interval). The .im polynomial blocks are then updated such that:
- the initial delay (0th order) at scan start as predicted by CALC9 is taken from the .im file
- subsequent poly segment intervals have delay (0th order) that is based on (1) and the sum of delay changes over all earlier poly segments, i.e., poly segments are kept time-continuous across poly boundaries
- the initial rate (1th order) and higher-order poly coefficients are taken from the ASC files
- rate is adjusted by optional user-provided residual rate (option '-r <delta rate usec/sec>')
To use the new .im.closedloop file for a DiFX correlation run:
$ mv rk18cj_1.im rk18cj_1.im.openloop $ cp rk18cj_1.im.closedloop rk18cj_1.im $ startdifx --dont-calc rk18cj_1.input
The startdifx option --dont-calc is necessary to avoid potentially overwriting the closed-loop -patched .im file.
The output of correlation can be processed as usual.
Iterative improvement of the ASC poly coefficients might be necessary. Currently, we know ASC has a method to do this, but at Bonn we do not have details yet. With PIMA fringe fitting one could determine delay, rate, acceleration residuals. However how higher-order terms could be refined is yet unclear. Once we settle at a good approach, a mechanism to feed back fringe-fit results into raPatchClosedloop.py will be implemented.
