[daip] FRING ignoring input models?

Andrew Biggs abiggs at eso.org
Thu Aug 9 03:29:59 EDT 2012


Hi Eric. This turned out to be completely my fault - I had more than one
CALSOUR defined. However, it might be good to issue a warning that in this
case no model will be used if one has been requested.

Cheers,

Andy

On 08/08/2012 23:47, "Eric Greisen" <egreisen at nrao.edu> wrote:

>Andrew Biggs wrote:
>> Hi there. I'm trying to run FRING using an input model for the source
>>made
>> with IMAGR. FRING appears to be ignoring this, no matter what inputs I
>> use. I've tried to provoke errors by entering IN2SEQ, INVER, NMAP, etc.,
>> that don't actually make sense, but that doesn't have any effect. If I
>> look in the history file, the map file is there, but NMAP is given as
>>zero
>> - maybe that is significant. My inputs seem completely standard:
>> 
>> AIPS 1: IN2NAME    'J0132+4325'               Cleaned map name (name)
>> AIPS 1: IN2CLASS   'ICL001'                   Cleaned map name (class)
>> AIPS 1: IN2SEQ        4                       Cleaned map name (seq. #)
>> AIPS 1: IN2DISK       1                       Cleaned map disk unit #
>> AIPS 1: INVERS        0                    CC file version #.
>> AIPS 1: NCOMP      *all 0                  # comps to use for model.
>> AIPS 1:                                    1 value per field
>> AIPS 1: FLUX          0                    Lowest CC component used.
>> AIPS 1: NMAPS         1                    No. Clean map files
>> AIPS 1: CMETHOD    ' '                     Modeling method:
>> AIPS 1:                                    'DFT','GRID','    '
>> AIPS 1: CMODEL     ' '                     Model type: 'COMP','IMAG'
>> AIPS 1:                                    'SUBI' (see HELP re images)
>> AIPS 1: SMODEL     *all 0                  Source model, 1=flux,2=x,3=y
>> AIPS 1:                                    See HELP SMODEL for models.
>> AIPS 1:
>> 
>> The map was selected using GET2N and does definitely exist. CALIB is
>> working fine in this regard.
>
>Is SMODEL not zero?  Looking at the history writing routine I see an
>error.  It writes the IN2NAME etc when SMODEL(1) is not zero rather than
>when it is zero.  I am fixing that.  It seems that it sets NMAPS to a
>minimum of 1 in the task and I do not see how it could become zero.
>
>Eric Greisen





More information about the Daip mailing list