[daip] small problem

[Mark Reid]

Eric Greisen wrote:
> Mark Reid wrote:
>> Dear Aipser's
>>
>>      Here is a problem that I've encountered more than once (but far 
>> enough apart in time to forget what happened).  It has cost me hours 
>> of work each time.
>>
>> When I run the following with default settings for VLBA data:
>>
>> AVSPC: to make a 16 chan "continuum" UV file from a 256 chan line file,
>>         the new parameter DOACOR=-1 removes the AC data.  Since older
>>         versions of AIPS didn't have this parameter, my old scripts don't
>>         know about this.
>>
>> ACCOR: runs "successfully" and creates an SN1 table.  But, the SN1
>>         table it creates is empty (as there is no AC data to work on).
>>
>> CLCOR: with SNVER 1; INVER 1 gives the message that it can't find
>>         SN2.  This is very puzzling, since I told it only to look at SN1.
>>
>>
>> Anyway, this all could be fixed by changing the the following:
>>
>>      AVSPC defaults so that DOACOR=+1.
>>      ACCOR should give a warning if it has no data to work on.
>>      CLCOR should not look for SN2 if told only to look at SN1
> 
> 1. The change to AVSPC was done October 1, 2007.  All tasks that allow 
> calibration were changed to support all standard 
> calibration/data-selection adverbs.  DOACOR false is what most users 
> want most of the time.  It is a global adverb and you can set it to true 
> (> 0) in your script.

   I'll do that, but it would be nice to have defaults that are 
backwards compatible.

> 
> 2. I have today modified ACCOR to trap the no data found case and set 
> the error return.  Your script will detect this error if you run with 
> DOWAIT=TRUE.  It will not see the error if you run instead with 
> DOWAIT=FALSE with task='accor'; go; wait.

    All my scripts use the "go; wait".   I assume there is a reason you 
can't have the task print a warning that appears in the messages.

> 
> 3. CLCOR does not modify CL table 1 - it is an error to tell it to do 
> so.  Instead, by default, it copies the input CL table (GAINVER) to an 
> output CL version (GAINUSE) and then modifies that version.  This would 
> be CL table 2 in normal usage (if you start with only 1 CL table).  The 
> error message suggests that it was unable to read that new table, but 
> you have not given me enough information to tell what really went wrong.
> 

    It was SN tables, not CL tables.  It looks for SN2 (at least that is 
what the message says), when I specified only SN1.

Mark