When Aegean is run on a large image it crashes and also brings down the term.app that it is running in.

Mosaic-1.fits size:
1.296322560 GB
18000*18000 pixels

Computer Spec:
Processor - 2.9 GHz Intel Core i7
Memory - 8 GB

Command line input:
python aegean.py Mosaic-1.fits --rms=35e-6 --outfile=AegOut.M1 --table=AegM1.reg

(Using Aegean.r982)

When using multiple cores (2-4 on my machine) I get different source counts (often none at all) when compared to similar source-finding with a single core. Running a test on all the test images yields the following source counts:

1904-66_AIR.fits: 1 core: 51, 4 cores: 0
1904-66_AIT.fits: 1 core: 53, 4 cores: 0
1904-66_ARC.fits: 1 core: 52, 4 cores: 0
1904-66_AZP.fits: 1 core: 51, 4 cores: 0
1904-66_BON.fits: 1 core: 51, 4 cores: 23
1904-66_CAR.fits: 1 core: 51, 4 cores: 0
1904-66_CEA.fits: 1 core: 50, 4 cores: 0
1904-66_COD.fits: 1 core: 51, 4 cores: 23
1904-66_COE.fits: 1 core: 51, 4 cores: 0
1904-66_COO.fits: 1 core: 50, 4 cores: 22
1904-66_COP.fits: 1 core: 51, 4 cores: 24
1904-66_CSC.fits: 1 core: 54, 4 cores: 0
1904-66_CYP.fits: 1 core: 50, 4 cores: 21
1904-66_HPX.fits: 1 core: 58, 4 cores: 0
1904-66_MER.fits: 1 core: 49, 4 cores: 0
1904-66_MOL.fits: 1 core: 49, 4 cores: 21
1904-66_NCP.fits: 1 core: 50, 4 cores: 23
1904-66_PAR.fits: 1 core: 52, 4 cores: 0
1904-66_PCO.fits: 1 core: 54, 4 cores: 0
1904-66_QSC.fits: 1 core: 48, 4 cores: 0
1904-66_SFL.fits: 1 core: 50, 4 cores: 0
1904-66_STG.fits: 1 core: 53, 4 cores: 0
1904-66_SZP.fits: 1 core: 52, 4 cores: 0
1904-66_TAN.fits: 1 core: 48, 4 cores: 0
1904-66_TSC.fits: 1 core: 47, 4 cores: 21
1904-66_ZEA.fits: 1 core: 53, 4 cores: 0
1904-66_ZPN.fits: 1 core: 41, 4 cores: 41

FWIW I'm using a Mac with OSX El Capitan, 10.11.6. The python version is 2.7.11 installed through Anaconda with the latest Aegean version as well.

Sometimes I source-find on a master image to get a bunch of sources. I then play around with these in e.g. TopCat and make some sub-selections based on various criteria. When I write out from standard software like TopCat, I can only use standard output formats like vot and fits. However, if I then want to use that catalogue as an input to futher source-finding/fitting with Aegean, I need to use Aegean's native ".cat" format, which is not easy to create. Would it be possible to use other format tables as an input to Aegean's fixed-position source-characterisation mode?

The wiki needs to be clearer about how you can input a catalogue which has psf_ columns instead of specifying --ratio or --catpsf when performing priorized fitting:

https://github.com/PaulHancock/Aegean/wiki/Priorized-Fitting

Better --help text also appreciated, or a link to the wiki.

MIMAS currently breaks when the --area flag is invoked.
This seems to be a bug introduced recently as it was working about a month ago (ie Dec 2017).

$ MIMAS +c 0 -30 10 -o test.mim
20679:INFO This is MIMAS v1.3.0-(2017-09-10)
20679:INFO Wrote test.mim
$ MIMAS --area test.mim
20694:INFO This is MIMAS v1.3.0-(2017-09-10)
Traceback (most recent call last):
  File " ... MIMAS", line 6, in <module>
    exec(compile(open(__file__).read(), __file__, 'exec'))
  File " ... MIMAS", line 126, in <module>
    region = MIMAS.pickle.load(open(results.area))
AttributeError: 'module' object has no attribute 'pickle'

Currently there are two methods that Aegean will use to scale the input catalogue psf: a single ratio using --ratio or a reference map using --catpsf. However if the input catalogue was created by Aegean then the catalogue itself contains the psf_{a,b,pa} information and should thus be used if either of the other inputs are not supplied.

AeRes can be used to add sources to an image instead of subtracting them. At the moment this means that the user is required to enter sources with the negative intended flux.

It would be nice to have an option such as --add that would cause AeRes to do the negation internally and add sources from a catalog, without the user having to munge their own catalogs.

So I'm getting a very unexpected result: I'm running Aegean on some simulated data, and looking at the output catalog, and the values for a, b, psf_a, and psf_b are all very unexpected. In the documentation (https://github.com/PaulHancock/Aegean/wiki/Output-Formats) it says all these quantities are in degrees, but if I compare the output values (particularly for the psf) to the input FITS header (again, particularly the beam keywords), the numbers are completely different.
To be specific, here's my FITS header:
BMAJ = 0.00406575
BMIN = 0.003565888888889
BPA = 88.6496

And here's my table output (via my ipython-based exploration of the data):
In [37]: meanQ_cat['psf_a'][0]
Out[37]: 14.636699999999999
In [38]: meanQ_cat['psf_b'][0]
Out[38]: 12.837200000000399
In [39]: meanQ_cat['psf_pa'][0]
Out[39]: 88.649600000000007

Values of a,b, and pa are all consistent with the PSF values for most fitted sources.
The PA is fine, but in the major/minor axes there's a factor of 3600 difference, which I think suggests the cause: a missing conversion from arcseconds to degrees? (Or, alternatively, one could simply change the documentation of the outputs...)

Aside from this, everything seems to work great so far, so thank you for your hard working developing this.

When fitting with a synthesised beam that has a position angle that is PA ~+/- 90, the minor axis of a point sources can be confined to be larger than the synthesised beam major axis.

Thanks to Josh Marvil for bringing this to light.

Using --island and --table=out.reg doesn't produce any island contours.
The output table contains all the correct information but the .reg file contains only a header.

Problem:
Occasionally Aegean will seem to freeze for a very long time. After a few hours Aegean will finally produce output. The output suggests that a very large island is being fit.

Cause:
It seems that the primary cause of this problem is large islands. Islands that have ~30 or more pixels will take a long time to fit regardless of the number of components being fit. This is due to the use of the covariance matrix which scales as the square of the number of pixels in the island.

Aegean is able to find sources in all stokes parameters, however when a total polarisation image is formed Aegean does not work well at all.

total polarisation is calculated as p^2 = Q^2 + U^2, which is now a positive definite quantity that has a non zero bias, and definitely a non Gaussian noise profile. The curvature of the 'p' image is also much different from any of the other stokes parameters. These factors work together to make Aegean give incorrect results.

Surveys like POSSUM are already using Aegean to source find I,Q,U,V images, and would benefit from being able to also find sources in p.

The ratio of int_flux/peak_flux is not 1.00 even for single component islands.

Recent changes to Aegean (v19rc1-78-gc4461b1) bring the value of this ratio to about 1.05, but there is an obvious bias.

I expect this ratio should have an average value of 1.00.

Either this expectation is wrong or Aegean is doing something incorrect.

BANE doesn't like files with NAXIS>4, and will try to quit early. However it doesn't exit cleanly due to sys.exit() being called within a sub-process. I think the master process just hangs.

As described above:
'''
BANE.py 1117906288-I.fits
14128:INFO This is BANE v1.2-(2015-06-24)
14128:INFO using grid_size (10, 10), box_size (60, 60)
14128:INFO on data shape (3072, 3072)
14128:INFO using 64 cores
14128:INFO done
14128:INFO Wrote <open file '', mode 'w+b' at 0x7efc17b9b9c0>
14128:INFO running second pass to get a better rms
14128:INFO using 64 cores
Traceback (most recent call last):
File "/usr/local/bin/BANE.py", line 4, in
import('pkg_resources').run_script('aegean===v1.9.6-53-g7db7f35', 'BANE.py')
File "/usr/local/lib/python2.7/dist-packages/pkg_resources.py", line 636, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources.py", line 1557, in run_script
exec(code, namespace, namespace)
File "/usr/local/lib/python2.7/dist-packages/aegean-v1.9.6_53_g7db7f35-py2.7.egg/EGG-INFO/scripts/BANE.py", line 789, in
mask=options.mask, compressed=options.compress)
File "/usr/local/lib/python2.7/dist-packages/aegean-v1.9.6_53_g7db7f35-py2.7.egg/EGG-INFO/scripts/BANE.py", line 622, in filter_image
mask_img(bkg, ref)
File "/usr/local/lib/python2.7/dist-packages/aegean-v1.9.6_53_g7db7f35-py2.7.egg/EGG-INFO/scripts/BANE.py", line 347, in mask_img
data[mask]=np.NaN
IndexError: too many indices for array
'''
This also seems to happen when there are no pixels to be masked.

Setting option --nomask avoids this problem.

Error looks like this

File "/home/hancock/V-Py/bin/AegeanTools/source_finder.py", line 1107, in _refit_islands
    square = idata[xmn:xmx, ymn:ymx]
TypeError: slice indices must be integers or None or have an __index__ method

Doesn't occur when using numpy v1.11 or earlier.

Seems to only happen when priorized fitting is requested, not for regular source finding.

In some cases the err_ra and err_dec are identical and this looks like a mistake.

The errors that are calculated are as described by Condon'97. The assumption has been made that the errors are uncorrelated, which is not usually true. In some cases this results in the same (or identical) error in ra/dec. There is no description in the Condon paper as to how to deal with the correlated errors. What we are seeing is not an error in calculation but the result of an improper assumption.

Since I am planning to move beyond the Condon description of errors I am not planning to fix this bug.

The following command should work according to the help documentation
MIMAS -o nogal.mim +c 263.47375 -26.69649 40 -r gp.mim
however the output contains a region consistent with the +c option, as if the -r was not supplied.

If the number of data points that are calculated by BANE exceeds 2^24 then you will get this strange error. This seems to be a limitation of scipy.interpolate.griddata. The number of points that BANE calculates is roughly the number of pixels in the image divided by the grid size squared.

npix = NAXIS1 * NAXIS2 / grid[0] / grid[1]
if npix >=2**24:
   crash_and_die = True

It would be nice to have a warning issued that a crash is going to occur, before embarking on a 1hour+ computation that is only ever going to fail.

Older versions of astropy give type errors when writing VO tables.

Version 0.2.3 definitely does not work.
Version 0.4.1 definitely does work.

Not sure which astropy version has the critical upgrade, but it might be worth requiring 0.4. Since this error happens at the end during the write-out step, it would be helpful to do the version test before the source-finding runs, so that the user doesn't wait some time to find out the process isn't working.

There are some instances when the forced fitting option should allow for the position of the source to be fit as well as the flux of the source.

It would be nice to have a feature where the user can supply a list of positions (and maybe some allowable constraints on how much these can vary), and return a list of sources that are fit at these locations. This would effectively be a situation in which the user is supplying the initial parameters (and constraints) for the fitting routine.

Currently, Aegean is not able to operate on image cubes (data with more than 2 real axes). Being able to work on a single frequency slice of an image cube would be beneficial to many people's science. Currently this functionality is achieved by splitting the fits cube into a sequence of 1-d images and running Aegean on them separately.

WARNING: AstropyDeprecationWarning: "clobber" was deprecated in version 1.3 and will be removed in a future version. Use argument "overwrite" instead. [astropy.utils.decorators]

This is not currently a problem, but will be in the near future.
Hopefully the use of 'overwrite' is backwards compatible!

The column type for the fits tables can change depending on the contents of the column.

Specifically the err_x columns can revert to integer types if all the errors are -1, but will be floats if one of the errors are not -1.

This causes troubles, for example, when combining catalogues using topcat.

Something is wrong with this:

BANE.py $mosaic
24601:INFO This is BANE v1.0
Traceback (most recent call last):
File "/scratch/partner1002/code/bin/BANE.py", line 482, in
options.out_base = os.path.splitext(options.out_base)[0]
File "/ivec/apps/gcc/4.4.7/python/2.6.9/lib/python2.6/posixpath.py", line 95, in splitext
return genericpath._splitext(p, sep, altsep, extsep)
File "/ivec/apps/gcc/4.4.7/python/2.6.9/lib/python2.6/genericpath.py", line 91, in _splitext
sepIndex = p.rfind(sep)
AttributeError: 'NoneType' object has no attribute 'rfind'

Typical output looks like:

7025:INFO This is BANE v1.2-(2015-06-24)
7025:INFO using grid_size (17, 17), box_size (102, 102)
7025:INFO on data shape (10801, 15748)
7025:INFO using 8 cores
7025:INFO done
7025:INFO Wrote <open file '', mode 'w+b' at 0x191eae0>

output is produced as expected, i.e. a file like _bkg.fits.

If the PSF file contains data, but the major axis is None at the given location in the map, then instead of returning None the a Beam object is constructed using the information in the image file.

All files should have a copy of the licence copied into them. The docstring is used often but this makes auto documentation a pain. I suggest that the licence be copied into the top of the file as python comments.

The option --out previously caused a not-so-nice-format catalogue to be written to a file.
This is no longer the case, instead --out does nothing at all, and there is no way to make this not-so-nice-format catalogue.
The default options for Aegean are now to not print a catalogue of any kind!

Symptom:
Some sources in a catalogue have all the uncertainties set to -1 but the flags column is still zero.
Something has gone wrong but we can't tell what.

Cause:
Uncertainties are calculated in pixel coordinates and then converted to sky coordinates.
If a source has one uncertainty as NaN in pixel coordinates then during the conversion into sky coord uncertainties, all the parameters will have their uncertainties reported as -1.
No flags are set when this happens

It should be possible to have -1 uncertainty in ra or dec, but still have known uncertainties in a/b/pa or vice-a-versa.

Found a minor bug in the --help documentation:

--outbase=OUTBASE If --save is True, then this specifies the base name
of the background and noise images. [default: inferred
from input image]

The default is aegean-background.fits etc, not inferred from the input
image as the helptext says.

Would it be possible to add a user defined prefix to all columns in the output table of Aegean? This would be useful to track any column when more than one table is combined together using software such as topcat.

lmfit v0.8.3 and 0.8.1 work fine
lmfit v0.3 doesn't work
lmfit v0.9 doesn't work
intermediate versions haven't been tested

A fix for v0.9 is on it's way.
I'm not going to bother fixing the problem with v0.3 just yet.

Desired feature: For Aegean to be able to fit across multiple images at the same time.
Examples:

• given a set of I, Q, U, V images, fit a single location/shape but 4 flux values
• given an image I and a variance image S use the combined SNR to detect sources
• given a cube of images, fit a single position, multiple fluxes (ie make an SED)

When running in --island mode Aegean currently outputs a limited number of parameters for each island.

The shape parameters are currently limited to the size of the island in pixels (x_width, y_width), and the total number of pixels in the island.

I have had requests from people about adding extra parameters to this output, namely the width of the region in degrees, or something that resembles the parameters of an ellipse.

This post is to act as a gathering point for anyone who want to put in further requests for island parameters: tell me what you want and how to calculate it in the comments and i'll include it if at all possible.

--telescope is needed for ZEA projected images, but not for SIN projected images, and if a psf map is supplied then --telescope is ignored.

It would be nice if Aegean could look at the image projection, determine if the --telescope option is required, and then warn the user if it is missing when required, or that it is being ignored when not required.

This error:

/home/hancock/V-Py/bin/AegeanTools/source_finder.py:1106: VisibleDeprecationWarning: using a non-integer number instead of an integer will result in an error in the future
  square = idata[xmn:xmx, ymn:ymx]

happens a lot with newer versions of numpy.
It would be nice to remove the problem.

Has been happening for a while, it currently occurs in Aegean v2.0b-81-g6b1142c -(2016-09-08)

It would be very useful to be able to tell Aegean to only run on a subregion of the image.
For many images the usable region is a circle or ellipse in the center of the image. In images that have poor sensitivity and large noise outside of this 'usable' area, Aegean will spend a good fraction of the total run time finding junk sources that are later discarded.

It would be good to be able to specify this sub region either in sky coords, or in pixel corrds.

If you try to stop BANE by using ctrl+c, it doesn't die. Somehow the process rises from the dead, but it doesn't finish running properly.

For some reason I'm getting an error running BANE on galaxy:

29730:INFO This is BANE v1.4.6-(2016-09-01)
29730:INFO using grid_size (17, 17), box_size (102, 102)
29730:INFO on data shape (5214, 4661)
29730:INFO using 20 cores
Traceback (most recent call last):
File "/group/mwasci/code/bin/BANE.py", line 5, in
pkg_resources.run_script('AegeanTools==v2.0b-46-g24246a4-master-',
'BANE')
File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 492, in
run_script
"""
File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 1350, in
run_script
return open(self.fn(self.module_path, resource_name), 'rb')
File
"/group/mwasci/code/lib/python2.6/site-packages/AegeanTools-v2.0b_46_g24246a4_master-py2.6.egg/EGG-INFO/scripts/BANE",
line 66, in
mask=options.mask, compressed=options.compress)
File
"/group/mwasci/code/lib/python2.6/site-packages/AegeanTools-v2.0b_46_g24246a4_master_-py2.6.egg/AegeanTools/BANE.py",
line 404, in filter_image
bkg, rms = filter_mc_sharemem(im_name, step_size=step_size,
box_size=box_size, cores=cores, shape=shape)
File
"/group/mwasci/code/lib/python2.6/site-packages/AegeanTools-v2.0b_46_g24246a4_master_-py2.6.egg/AegeanTools/BANE.py",
line 332, in filter_mc_sharemem
pool.map(sf2, args)
File
"/pawsey/cle52up04/apps/gcc/4.3.4/python/2.6.9/lib/python2.6/multiprocessing/pool.py",
line 148, in map
return self.map_async(func, iterable, chunksize).get()
File
"/pawsey/cle52up04/apps/gcc/4.3.4/python/2.6.9/lib/python2.6/multiprocessing/pool.py",
line 422, in get
raise self._value
ValueError: Can only assign sequence of same size
^[[0;33mWARNING^[[0m: AstropyDeprecationWarning: Python 2.6 will no longer
be supported from Astropy v1.2.0 and above [astropy]

But it works fine if I use a single core:

29756:INFO This is BANE v1.4.6-(2016-09-01)
29756:INFO using grid_size (17, 17), box_size (102, 102)
29756:INFO on data shape (5214, 4661)
29756:INFO using 1 cores
29756:INFO done
29756:INFO Wrote ', mode 'w+b' at 0x1732270>
29756:INFO running second pass to get a better rms
29756:INFO using 1 cores
29756:INFO Wrote mosaic_20140610_080-088MHz_r-1.0_recomb_polyapplied_bkg.fits
29756:INFO Wrote mosaic_20140610_080-088MHz_r-1.0_recomb_polyapplied_rms.fits

I'm just doing $aprun BANE --noclobber --compress $file

with this BANE:

nhurleywalker@galaxy-1:~/queue> which BANE
/group/mwasci/code/bin/BANE

Version:
3982:INFO This is BANE v1.4.6-(2016-09-01)

Loaded modules:
Currently Loaded Modulefiles:

1. slurm/14.11.8-pawsey-3 15) pmi/5.0.4-1.0000.10161.132.4.ari 29) traceback2/1.3.0 43) distribute/0.6.49 57) blist/1.3.6
2. pawseytools/1.9 16) dmapp/7.0.1-1.0502.11080.8.76.ari 30) unittest2/1.1.0 44) matplotlib/1.5.0 58) scipy/0.16.1
3. rsync/3.1.1 17) gni-headers/4.0-1.0502.10859.7.8.ari 31) numpy/1.10.1 45) astropy/1.1 59) lmfit/0.9.1
4. modules/3.2.10.3 18) xpmem/0.1-2.0502.64982.5.3.ari 32) cython/0.23.4 46) memory_profiler/0.40 60) healpy/1.9.1
5. eswrap/1.1.0-1.020200.1231.0 19) job/1.5.5-0.1_2.0502.61936.2.32.ari 33) pkgconfig/1.1.0 47) m4/1.4.17 61) scikit-learn/0.17
6. switch/1.0-1.0502.60522.1.61.ari 20) dvs/2.5_0.9.0-1.0502.2188.1.116.ari 34) cray-hdf5/1.8.13 48) flex/2.6.0 62) gsl/1.16
7. craype-network-aries 21) alps/5.2.4-2.0502.9774.31.11.ari 35) argparse/1.4.0 49) bison/3.0.4 63) boost/1.49.0
8. gcc/4.8.2 22) rca/1.0.0-2.0502.60530.1.62.ari 36) six/1.10.0 50) sip/4.17 64) cmake/2.8.12.2
9. craype/2.1.2 23) atp/1.7.3 37) h5py/2.5.0 51) pyephem/3.7.6.0 65) cfitsio/3370
10. craype-ivybridge 24) PrgEnv-gnu/5.2.82 38) emcee/2.1.0 52) doxygen/1.8.9.1 66) wcslib/5.11
11. cray-mpich/7.0.0 25) python/2.6.9 39) python-dateutil/2.4.2 53) java/jdk1.7.0_45 67) readline/5.1
12. cray-libsci/13.0.0 26) lapack/3.5.0 40) pytz/2015.7 54) fftw/3.3.4.3
13. udreg/2.3.2-1.0502.10518.2.17.ari 27) setuptools/18.4 41) mock/1.3.0 55) pigz/2.3.3
14. ugni/6.0-1.0502.10863.8.29.ari 28) linecache2/1.0.0 42) nose/1.3.7 56) psycopg2/2.6.1

Desired usage is:

• mask.fits contains image values that are either 1/0, where 1 means good data, and 0 means bad.
• file.fits contains actual image information, not all of which is useful.
• masked.fits is a file that is effectively the useful regions of file.fits

Suggested use case:
MIMAS.py --fitsmask mask.fits file.fit masked.fits
or
aegean.py file.fits --mask mask.fits [other options]

It would be nice to be able to inspect a file and determine whether the sources within the file have been fit normally or if they are the result of a priorized fit from another file.

An extra column to note the argument to --priorized would probably do the trick.

I run Aegean with the --island option and cross-match the resulting _isle and _comp tables with an exact match on the island column. When I plot the integrated flux as derived from the component fit against the integrated flux (divided by eta) as derived from the island floodfill, the results are out by a factor of three. Seedclip is 8 and floodclip is 5, so at the faint end it might be somewhat understandable (although eta should fix that) but it doesn't make a lot of sense at the high end. Linear and log plots attached.

Hi, I've been trying aegean.py according to the wiki.
However it always return error as follows:

python aegean.py Test/Images/1904-66_SIN.fits
aegean:INFO This is Aegean v1.9.6-127-g088562b-(2015-10-02)
aegean:INFO Found 4 cores
aegean:WARNING Your O/S doesn't support select.poll(): Reverting to cores=1
aegean:INFO Using 1 cores
aegean:INFO Finding sources.
aegean:INFO Calculating curvature csigma
aegean:INFO Calculating background and rms data
aegean:INFO beam = 864.00'' x 864.00'' at 0.00deg
aegean:INFO seedclip=5
aegean:INFO floodclip=4

Aegean version v1.9.6-127-g088562b-(2015-10-02)

on dataset: Test/Images/1904-66_SIN.fits

isl,src bkg rms RA DEC RA err DEC err Peak err S_int err a err b err pa err flags

Jy/beam Jy/beam deg deg deg deg Jy/beam Jy/beam Jy Jy '' '' '' '' deg deg WNCPES

===========================================================================================================================================================================================

Traceback (most recent call last):
File "aegean.py", line 2270, in
mask=options.region, lat=lat, imgpsf=options.imgpsf)
File "aegean.py", line 1501, in find_sources_in_image
res = fit_island(island_data)
File "aegean.py", line 1373, in fit_island
result, model = do_lmfit(idata, params, B=B)
File "/Users/yw_astro/Software/Astro_Soft/Aegean-master/AegeanTools/fitting.py", line 383, in do_lmfit
result = lmfit.minimize(residual, params, kws={'x':mask[0],'y':mask[1],'B':B,'errs':errs}, Dfun = jacobian)
File "/Library/Python/2.7/site-packages/lmfit/minimizer.py", line 773, in minimize
return fitter.minimize(method=method)
File "/Library/Python/2.7/site-packages/lmfit/minimizer.py", line 705, in minimize
return function(*_kwargs)
File "/Library/Python/2.7/site-packages/lmfit/minimizer.py", line 546, in leastsq
lsout = scipy_leastsq(self.__residual, vars, *_lskws)
File "/Library/Python/2.7/site-packages/scipy/optimize/minpack.py", line 371, in leastsq
shape, dtype = _check_func('leastsq', 'func', func, x0, args, n)
File "/Library/Python/2.7/site-packages/scipy/optimize/minpack.py", line 20, in check_func
res = atleast_1d(thefunc(((x0[:numinputs],) + args)))
File "/Library/Python/2.7/site-packages/lmfit/minimizer.py", line 257, in __residual
out = self.userfcn(params, *self.userargs, *_self.userkws)
File "/Users/yw_astro/Software/Astro_Soft/Aegean-master/AegeanTools/fitting.py", line 376, in residual
model = f(*mask) # The actual model
File "/Users/yw_astro/Software/Astro_Soft/Aegean-master/AegeanTools/fitting.py", line 343, in rfunc
for i in range(params.components):
AttributeError: 'Parameters' object has no attribute 'components'

I'm not sure whether it's a problem of lmfit, but I've already tried to reinstall it both from the source code or by pip for many times...
Another problem is that the select.poll() in BANE.py seems to be failed on my mac( osx 10.11), is this a general problem for python on Mac or sth. wrong with mine?

Thank you.

This error occurs when trying to create a footprint file from a .mim file.

The file exists in the git repo, however it is not installed in the right place when using pip install.

setup.py needs to be updated to make this work properly.

As the title suggests: an image that has coordinates defined in galactic lat/lon (and probably in ecliptic lat/lon) will have tables written that claim to be ra/dec coordinates. The values of the columns are correct, but the labels are not.

It would be nice if Aegean could warn users about this or, even better, relabel the columns when required.

If Aegean is run with --maxsummits=0, not fitting is done, just estimation.

The output _comp.reg file contains all the expected information however the _isle.reg file has only a header. The actual island information is missing.

The Aegean user guide has not been imported as it was not part of the SVN repository. The guid is out of date and needs to be remade. Github wiki is probably the best place to put the updated version of the user guide.

Hi Paul,
We encounter a issue when we processing VLA data using aegean, which do not have BEAM informations.
Such as BMAJ,BMIN and BPA key.

So the simplest way is to dig out these key from HISTORY section and then write them to the FITS header @ly201601.

Then it works good.

So it maybe useful if you can add this script before processing FITS data.

Test scripts can refer #27.

--lat=LAT The latitude of the tlescope used to collect data.