Correcting array factor away from pointing center
Closed this issue · 9 comments
As in the telecon today, it would be nice to be able to correct for the array factor in a direction away from the delay or reference direction.
I see that #68 was similar to this, where the direction option was added. Prefactor already corrects for the beam at the pointing center (where array factor = 1 if I'm not mistaken). Attempting to take out just the array factor in another direction (on a phaseshifted dataset) results in
std exception detected: In applying the beam (with invert=true): the metadata of this observation indicate that the beam has already been applied
I split a couple timeslots and channels from a phaseshifted MS that already has the beam taken out at the original phase center by prefactor and uploaded it here: ftp://ftp.strw.leidenuniv.nl/pub/sweijen/test_beam.ms.tar
Thanks for the testset Frits. Just to make sure I understand everything, if I apply this parset:
msin=test_beam.ms
msout=output.ms
steps=[applybeam]
applybeam.direction=[10h47m00.0s, 59d05m00s]
You expect that it makes the beam applied at the new direction (the phase centre in this case), and when the beam was already applied, first undo that operation. Is that correct?
I was thinking even simpler (but maybe it isn't), allowing it to apply an array factor through applybeam.beammode=array_factor if the new direction is not the pointing center and it has not been applied in another direction yet.
Your suggestion sounds like it would probably be the better and proper way to do it though, as then the element beam would also be corrected correctly in that direction.
I think I implemented what you want in #222 . There's a description there.
It also outputs to stdout when a beam was already applied and you're applying a new one. In that case it should show:
input data has already a beam correction applied: will be undone.
in the applybeam step. When applying the beam for the first time, it shows
input data has no beam correction applied.
Ah sorry, undoing the element beam isn't necessary. Just for my own confirmation to make sure I understand the beam corrections:
- element beam is due to the the target moving across the stationary telescope
- array factor is the effect of going down the primary beam away from pointing center and is 1 when applied to the pointing center
right?
What I tried to explain is the scenario where the beam is corrected in the pointing center (where array factor is 1?) as prefactor does, or say direction A and the array_factor needs to be corrected in direction B. I think the two possibilities would then be, when applying the beam to direction B:
- undo the beam in direction A and apply the full beam in direction B
- assume the error for direction B from the element beam being corrected in direction A is small/acceptable and additionally apply just array factor for direction B (or undo the array factor in direction A in then apply in direction B in case direction A wasn't the pointing center, but we're unlikely to encounter this scenario I think).
Approach 1) is probably the more correct one? We currently do 2) with a workaround python script (dummy solve to get h5parm, call beam library to calculate beam, fill dummy h5parm, applycal), so we thought it would be nice if applybeam could do this instead. Sorry if my description wasn't clear earlier.
I think that what I implemented allows you to do this, in a fully correct way -- unless I'm missing something.
I agree on how you define element beam and array factor. The element beam includes the parallactic angle correction, and is important because of that (flux is otherwise suppressed when integrating over time) but is spatially smooth. The array factor is spatially less smooth.
If you now write a parset to correct the full beam in direction B, DP3 knows that the beam was already applied (partially) in a different direction, first corrects for that and then applies to full beam to direction B. So that's your solution 1, isn't it? So I thought that implements your request, or doesn't it?
Solution 2 would be a bit harder, because DP3 tracks what kind of beam is applied, so that e.g. WSClean can also automatically select the appropriate correction. That's desirable because the beams are confusing and I've seen quite a few people use incorrect corrections -- resulting in wrong flux levels. But that means that DP3 won't allow you to deliberately make a small error. I would think that's only better :). 'undoing the beam' happens automatically and doesn't affect performance.
Yes fully agree on solution 1.
I interpreted this bit wrongly then:
Applying an invert=true element beam to direction A, then applying an invert=true array beam to >direction B, would end up with the array beam applied to direction B (i.e. element beam to direction >A is undone).
So I should just apply the full beam in direction B and it will do the correct thing. What you describe indeed sounds exactly like what we wanted. I'll give it a try!
Any luck with this so far?
Just gave it a shot on the small test measurement set, and I think it does exactly what it should. Large beam corrections, when imaging, without the correction and small corrections when corrected beforehand with DP3 now. Thanks!
Great, thanks for testing!