from:	Mark Gurwell 
to:	"Qi, Chunhua" 
cc:	"Young, Ken" ,
Jun-Hui Zhao ,
Glen Petitpas 
date:	Tue, Sep 27, 2016 at 4:21 PM
subject:	Re: Flagging ipoint data

Right now the variable bl.pointing is set to 1 for all scans unless the pointing is offset from the center. So this will be a change. 

Is there ever a case where we would want there to be an offset from the phase center that doesn't involve pointing?

Mark


On Tuesday, September 27, 2016, Qi, Chunhua  wrote:

    Hi Taco,

    About the pointing variable, shall we do as Mark suggested, set the variable to 0 for all scans except pointing. And for pointing data, set it to 1 as center position and >1 to be the pointing offset position ? If so, let's make it consistent for both science and pointing tracks.

    Mark, just to confirm, is the pointing variable bl.pointing you are using ?


    Charlie

    On Fri, Jun 24, 2016 at 10:11 AM, Mark Gurwell  wrote:

        Hi Taco,

        there is a pointing variable that is currently in use which is set to '0' if the beam center is offset from the normal pointing center, and '1' in all other cases.  You put that in for me to use to indentify 'center' points to recover flux measurements from.

        I use it extensively, but we could utilize it more effectively. We could for example set it to -1 for offcenter pointing scans, 0 for center pointing scans, and 1 for all others.

        otherwise, we would be in the position of having some variables use '1' to identify on center scans (as is currently the case for all scans) but for pointing we'd now have '1' identify 'pointing scans' both off and on.

        I urge you to consider a more inclusive and consistent way to identify these scans.

        Mark

        PS: regarding the current 'pointing' identifier (0 off center, 1 on center); I'll point out yet again that it doesn't work *during science tracks* though it appears to work ok during actual pointing tracks.  I think it may have to do with having more than one cycle. So, whatever you do, it would be great if that could also be corrected. If this doesn't make sense, let me know and I will show you copious examples.



        On Fri, Jun 24, 2016 at 9:53 AM, Young, Ken  wrote:

            Dear SMA Data Format Stakeholder,

                Charlie pointed out yesterday that my decision to increase the scan length for ipoint scans will make flagging ipoint data more difficult.   I propose using one of the spare integers in the integration header (inh records) to flag which scans are ipoint scans.    Right now all of the spare integers are set to 0.   I propose setting the first of those integers to 1 for ipoint scans, making them easy to identify and flag.   Since the size of the data structure will not change, this should not break any existing code unless it somehow depends upon that spare integer being zero.   Does anyone object to this change?

            Taco