[alma-config] parameters for IMAGR, and integration times

[Steven]

Hello, I've  gratefully received some comments re parameters form Bryan,
which I address below. What concerns me more immediately however are the
implications of Stephane's message which I received today, reproduced below.

>> Steven wrote:
>> The A array simulations have been redone with an integration time of 60
>> seconds rather than the 180 seconds used to date, and for the other
arrays,
>> as this was felt to be too long for the longer baselines. The redone
results
>> have been posted to the site, accessible from
>> http://www.stevenheddle.co.uk/ALMA/ALMA_IND.HTM
>>
>> Cheers,
>>     Steven
>>
>>
>
>Hi Steven,
>
>I do not believe this is correct. The Nyquist sampling for
>a 10 km baseline is 8 seconds... It is 27 seconds for a 3 km baseline.
>So your UV data are fairly heavily undersampled at their longest baselines.
>This will add significant sidelobes, and perhaps explain why you get
>large negative sidelobes than theory says.
>
>Stephane

My problem is mainly the practical one of dealing with the UV data files
this implies- at 60 seconds integration time the files are already 48MB, so
at 8 seconds they will balloon to approximately 360 MB per file. As it
stands (60 seconds) I reckoned I could shoehorn the A array simulations
(including CLEANing)  into 6GB of AIPS disk, but am now faced with the
prospect of requiring 45GB for only the A arrays! Also I was not aware that
there was a problem with large negative sidleobes, but if there is (or
indeed any other problems) please tell me as soon as possible.
Are these the integration times I should be using? Are there other issues
such as noise which work against such short integration times? What
integration times are commonly used on the VLA with its >20 km baselines?
This is clearly a fairly fundamental issue, so an instant consensus would be
great, and allow me to generate some CLEANed images before the next
telecon... and an endorsement of my BMAX, BMIN strategy would be great too.


Returning to the other parameters...

Thanks for the comments. I should clarify the use of the nuvco3mm set of
parameters included in my message of 11th August
- they simply form a known state of parameters, most of which are useful as
they stand, which hopefully requires
as little modification as possible. The attached file in the earlier message
shows all the commands issued to AIPS in producing the simulation results
posted- this file is generated by calls to scripts which take nuvco3mm as
the starting point, and then modify the parameters to take into account
variable such as declination, length of track, aips disk to use, wavelength,
input array, desired output etc. Thus hopefully I can answer most of Bryan's
points by saying 'It's okay, I change this to x before doing y...'
To know what really happens in the simulations, the attached file on the
11th August message is gospel.

Here goes...

> with regards to some of steven's IMAGR inputs (in his email from
> 11aug2000):
> >DPARM(5)=1
> >DPARM(6)=4
> >FUNCTYPE 'LN'
>
> i presume that these are for LWPLA (for printing)?

 That's right, but during the command file generated, they may be changed to
other parameters and reset depending on the task in use.

> >SELBAND 1000
> >SELFREQ 2.99793E+05
>
> these shouldn't really be necessary.  they should just be set at
> the defaults, which allows IMAGR to get it from the input dataset.
> maybe there is a practical reason for doing this though?
>
This corresponds to 3mm (hence nuvco3mm) as I was doing simulations at that
wavelength at the time.In the current set of simulations SELFREQ is changed
to 345GHz. I didn't set it at the defaults due not being sure whether the
fact that our SIL is derived from images obtained at other frequencies might
lead to problems- ignorance is my defence, in fact.


> >CPARM(1)=12
>
> ahh.  this implies that you have an old version of IMAGR.  you
> should probably import the newest one, in which CPARM, and some
> other parameters, are replaced by IMAGRPRM.  in the newer IMAGR,
> you can, for instance, do multi-scale CLEAN if you want.  very
> powerful...  in any case, setting the aperture size should be
> unneccessary.  this is only important for multifrequency synthesis,
> where you can make a frequency dependent PB correction if you know
> the aperture size.  in fact, i'm not even sure what PB correction
> is implemented in IMAGR (uniform illumination maybe?).
>
> >CMETHOD 'DFT'
>
> while this minimizes the errors, in practice, i don't know anybody
> that does straight DFT with VLA data.  the number of visibilities
> prohibits it.  so gridded FFTs are always used.  on the one hand,
> we might say that we should do the most accurate thing available,
> but on the other hand, we might say that we should do what most of
> the observers (and the pipeline) will do with ALMA data.  DFT is
> more accurate, but gridded FFT is what will be used, of necessity,
> until computers get *alot* faster (try doing a 1024X1024 image of
> 1 million visibilities - you'll have a long wait!)...
>
You can bet that I've been GRIDding in all the CLEAN work I've been
planning!


> >FACTOR 0
>
> for complicated images, you will probably want to make this something
> like FACTOR=-.5 or so.  this makes minor cycles CLEAN less deeply.
> costs CPU, but gets you much better results on complicated extended
> structure.  you might also want to set PHAT=.02 or so, but this is
> probably not a big issue since the u-v coverage for all of the ALMA
> configurations is so good that this shouldn't be much of an issue
> (and its use is 'deprecated' in the current IMAGR).
>
Okay, I'll do this when it comes to the CLEANing.

> >APARM(6)=0
> >APARM(8)=1
> >APARM(9)=1
> >APARM(10)=0.05
>
> unclear to me which tasks this is for...
I'll get back to you on that one

> >GUARD(1)=-1
> >GUARD(2)=-2
> i would just leave these at default.
I made a mistake here, with GUARD(2) actually -1 as well. I found when doing
earlier CLEAN work that everything
crashed and burned for the defaults, so it has been -1 ever since.

> >UVWTFN 'NO'
>
> as i mentioned yesterday, i would use 'NA', but i think that in our
> case the two are equivalent...
This is another typo from me, I indeed do use only 'NA' as mentioned later.

> >GAIN 0.25
>
> this is too high a loop gain.  i would use the default 0.1, or perhaps
> even lower (0.05?).
I've been (and will be) using 0.1 in my prototying so far, so okay!

> >MINPATCH 51
>
> again, for CLEANing complicated extended structure, you will want to
> increase this.  it's not as big an issue as for VLA data, because we
> don't have sidelobes nearly as bad, but just to be safe, i would set
> this at some large fraction of the total image (like 256 or so).
Fair enough, if everybody's happy I'll do this.

> >UVWTFN 'NA'
>
> i'm a bit confused by two specifications of UVWTFN...
See above.

Thanks to all for the input. It is important that we are all happy with what
is being done, which is why I am posting things like the batch file used to
create the simulations. I have a lot of catching up to do on you guys (in a
non-gender specific sense) in this kind of work so I want everyone to have
access to the details of parameters etc. so there is no doubt what is going
on. Any questions please ask.


Cheers,
    Steven