from:	Petitpas, Glen 
to:	"Qi, Chunhua" 
cc:	David Wilner ,
Mark Gurwell ,
Ken Young ,
Jun-Hui Zhao 
date:	Thu, Oct 6, 2016 at 11:26 AM
subject:	Re: Velocity disaster in SWARM only data


OK thanks. As I mentioned, I didn't fix the header but I forgot the
velocity calculations were used in that way :(

Cheers

Glen

On Thu, Oct 6, 2016 at 11:25 AM, Qi, Chunhua  wrote:
> Hi Glen,
>
> When you use MIRIAD to image the upper sideband s1, you should put in
> correct rest frequency, for example,
>
> puthd in=160916.IC342_26_0.us1.vis/restfreq value=230.538
>
> before you invert it. Once you've done that, the velocity width should be as
> 0.182 km/s in miriad, consistent with that in MIR.
>
> So far I don't see any problem with the velocity header now.
>
> Best,
> Charlie
>
> On Wed, Oct 5, 2016 at 10:30 AM, Petitpas, Glen 
> wrote:
>>
>> Hi
>>
>> When I use idl2miriad to export the velocity corrected spectra the
>> output I see in MIRIAD does not match what I see in MIR. For s1 usb
>> the velocity range in MIR is
>> -20202 -> -17230 km/s
>> but when I export it in MIRIAD the range is
>> -20920 -> -17754 km/s.
>>
>> The line is not at the same velocity in MIR and MIRIAD.
>>
>> Mark suspects it is something in the way idl2miriad deals with channel
>> width. The velocity width in MIR per channel is 0.182 km/s and in
>> MIRIAD it is given as 0.193 km/s.
>>
>> Cheers
>> Glen
>>
>> On Tue, Oct 4, 2016 at 1:52 PM, Qi, Chunhua  wrote:
>> > It replaces the previous version.
>> >
>> > Charlie
>> >
>> > On Tuesday, October 4, 2016, Petitpas, Glen 
>> > wrote:
>> >>
>> >> Hi Charlie. Thanks I'll try it now.
>> >>
>> >> Does this new command replace the previous version and do both sb at
>> >> the same time or do I have to do the previous commands first, and then
>> >> this to get the other sideband?
>> >>
>> >> Glen
>> >>
>> >> On Tue, Oct 4, 2016 at 12:10 PM, Qi, Chunhua 
>> >> wrote:
>> >> > Hi Glenn,
>> >> >
>> >> > Sorry I got distracted by my cold and other stuff. Now I have written
>> >> > the
>> >> > code to regenerate the velocity headers so it will use the
>> >> > dopplerTracked
>> >> > chunk freq and velocity information to regenerate all the chunks
>> >> > velocity.
>> >> > Also please note that I forgot to mention one important thing in the
>> >> > previous email, when you provide the frequency information, if it has
>> >> > long
>> >> > digit, you should provide it as a double-precision value. The easy
>> >> > way
>> >> > is
>> >> > put 'd' after the value. If you didn't do that, you'd better
>> >> > regenerate
>> >> > the
>> >> > velocity header since the floating errors will be pretty big for such
>> >> > calculations. Here is the new syntax for velocity header
>> >> > regeneration:
>> >> >
>> >> > Assume the dopplerTracking tuning command is:
>> >> >
>> >> > observe -s hltau -r 04:31:38.418 -d +18:13:57.37 -e 2000 -v 6.6
>> >> > dopplerTrack -r 279.511701 -u -s22
>> >> >
>> >> > Then the new syntax for velocity header regeneration:
>> >> >
>> >> > refsb='u'
>> >> > refband='s22'
>> >> > reffreq=279.511701d
>> >> > refvel=6.6d
>> >> >
>> >> >
>> >> > uti_vel_fix,/reg,refsb=refsb,refband=refband,reffreq=reffreq,refvel=refvel
>> >> >
>> >> >
>> >> > Please give it a try and let me know if there is any problem.
>> >> >
>> >> > Best,
>> >> > Charlie
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Sep 27, 2016 at 1:50 PM, Qi, Chunhua 
>> >> > wrote:
>> >> >>
>> >> >> Great. I will work on a fix for other sideband and chunks.
>> >> >>
>> >> >> Charlie
>> >> >>
>> >> >> On Tue, Sep 27, 2016 at 1:46 PM, Petitpas, Glen
>> >> >>  wrote:
>> >> >>>
>> >> >>> Hi Charlie. It seems to have worked. I'm trusting your math for the
>> >> >>> time being, but will check the extremities of the band later to see
>> >> >>> how well this correction holds up +/- 5000 km/s from the target. :P
>> >> >>>
>> >> >>> What can I do for the other sideband? I've always just edited the
>> >> >>> header (or changed the velocity axes on my plots) to get the other
>> >> >>> sideband velocities to appropriate for the other lines, but the
>> >> >>> core
>> >> >>> info does not seem to be in place of the SWARM only track.
>> >> >>>
>> >> >>> Glen
>> >> >>>
>> >> >>> On Mon, Sep 26, 2016 at 1:44 PM, Qi, Chunhua 
>> >> >>> wrote:
>> >> >>> > I forgot to mention that so far it works best for the
>> >> >>> > dopplerTracked
>> >> >>> > chunk.
>> >> >>> > Presumably, once you regenerate the velocity headers for
>> >> >>> > dopplerTracked
>> >> >>> > chunk (s1 as the example), then you can use this chunk as
>> >> >>> > reference
>> >> >>> > chunk to
>> >> >>> > fix other ones e.g. s2 etc for the SAME sideband,
>> >> >>> >
>> >> >>> > uti_vel_fix, ref='s1', band='s2'
>> >> >>> >
>> >> >>> > I haven't tested it yet. If it works, I can get into the detail
>> >> >>> > of
>> >> >>> > the
>> >> >>> > other
>> >> >>> > sideband.
>> >> >>> >
>> >> >>> > Charlie
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Mon, Sep 26, 2016 at 1:23 PM, Qi, Chunhua
>> >> >>> > 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Hi Glen,
>> >> >>> >>
>> >> >>> >> I've revised the program uti_vel_fix in MIR so it can regenerate
>> >> >>> >> velocity
>> >> >>> >> header based on the tuning information provided. I have tested
>> >> >>> >> on
>> >> >>> >> the
>> >> >>> >> asic
>> >> >>> >> chunks and the recalculated velocity header should be accurate
>> >> >>> >> within
>> >> >>> >> 3e-5.
>> >> >>> >> But I haven't tried it on swarm-only track yet.
>> >> >>> >>
>> >> >>> >> To use the program to regenerate velocity header on the
>> >> >>> >> dopplerTracked
>> >> >>> >> chunk, eg. lsb s1, you can do:
>> >> >>> >>
>> >> >>> >> select,source='xxx',sideband='l',band='s1',/p,/re
>> >> >>> >> uti_vel_fix,/reg
>> >> >>> >>
>> >> >>> >> Then put in the value of the dopplerTracking frequency (the
>> >> >>> >> value
>> >> >>> >> after
>> >> >>> >> the DopplerTrack -r) and the observing source velocity (the
>> >> >>> >> value
>> >> >>> >> after the
>> >> >>> >> observe -v). It should replace the velocity headers of this
>> >> >>> >> trunk
>> >> >>> >> with
>> >> >>> >> the
>> >> >>> >> regenerated ones. You should do it before you output the swarm
>> >> >>> >> chunk
>> >> >>> >> for
>> >> >>> >> imaging.
>> >> >>> >>
>> >> >>> >> Can you give it a try and let me know if it works ?
>> >> >>> >>
>> >> >>> >> Best,
>> >> >>> >> Charlie
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> On Wed, Sep 21, 2016 at 2:57 PM, Petitpas, Glen
>> >> >>> >>  wrote:
>> >> >>> >>>
>> >> >>> >>> Hi.
>> >> >>> >>>
>> >> >>> >>> Any suggestions for what to do with the swarm-only track? ASIC
>> >> >>> >>> was
>> >> >>> >>> powered down completely for that, and will be in the near
>> >> >>> >>> future.
>> >> >>> >>>
>> >> >>> >>> Glen
>> >> >>> >>>
>> >> >>> >>>
>> >> >>> >>> On Sep 21, 2016 2:54 PM, "Qi, Chunhua" 
>> >> >>> >>> wrote:
>> >> >>> >>>>
>> >> >>> >>>> Hi Mark,
>> >> >>> >>>>
>> >> >>> >>>> For previous tracks with swarm, I had to use uti_vel_fix to
>> >> >>> >>>> fix
>> >> >>> >>>> the
>> >> >>> >>>> velocity headers of swarm chunks using asic chunks velocity
>> >> >>> >>>> information. At
>> >> >>> >>>> least that's how I reduced the comet track.
>> >> >>> >>>>
>> >> >>> >>>> Charlie
>> >> >>> >>>>
>> >> >>> >>>> On Wed, Sep 21, 2016 at 2:47 PM, Mark Gurwell
>> >> >>> >>>> 
>> >> >>> >>>> wrote:
>> >> >>> >>>>>
>> >> >>> >>>>> Hi Taco, Charlie,
>> >> >>> >>>>>
>> >> >>> >>>>> It seems to me that the velocity information in the SWARM
>> >> >>> >>>>> only
>> >> >>> >>>>> data
>> >> >>> >>>>> is
>> >> >>> >>>>> a complete mess, at least as read  in and reported within
>> >> >>> >>>>> MIR.
>> >> >>> >>>>> This
>> >> >>> >>>>> is
>> >> >>> >>>>> looking at the 'SWARM only' data from September 14 (Orion-KL
>> >> >>> >>>>> data).
>> >> >>> >>>>> Glen
>> >> >>> >>>>> mentioned to me that the velocity information was wildly
>> >> >>> >>>>> incorrect
>> >> >>> >>>>> in the
>> >> >>> >>>>> IC342 mosaic observations as well.
>> >> >>> >>>>>
>> >> >>> >>>>> Is this an issue with the raw data, or potentially with
>> >> >>> >>>>> readdata
>> >> >>> >>>>> within
>> >> >>> >>>>> MIR? Jun-Hui, do you see anything unusual with the data from
>> >> >>> >>>>> SWARM
>> >> >>> >>>>> only
>> >> >>> >>>>> tests using the miriad path?
>> >> >>> >>>>>
>> >> >>> >>>>> Thanks,
>> >> >>> >>>>>
>> >> >>> >>>>> Mark
>> >> >>> >>>>>
>> >> >>> >>>>
>> >> >>> >>
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>
>