#110 closed defect (fixed)
Do not assume a beam if one is not given
Reported by: | MatthewWhiting | Owned by: | MatthewWhiting |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Input | Version: | 1.1.10 |
Severity: | normal | Keywords: | |
Cc: |
Description
If the beam information is not in the FITS file, the alternative behaviour is to use the beamFWHM etc parameters. However, if these are not provided, it uses a default size.
Tobias has pointed out that this default behaviour is actually to produce incorrect integrated fluxes. A better behaviour is to not calculate the integrated fluxes (perhaps just the total flux).
Method:
- If no beam info, check beamFWHM etc
- If these are the default (eg. negative values), set a flag to false
- Only calculate integrated fluxes if this flag is true
Change History (5)
comment:1 Changed 13 years ago by
Status: | new → assigned |
---|
comment:2 Changed 13 years ago by
comment:3 Changed 13 years ago by
This is just about done, using the new Beam and DuchampBeam? classes that we put in FitsHeader? & Param.
It works quite nicely. The only thing left to look at is whether we should not bother trying to read the beam info from the FITS file if the units are not eg. Jy/beam (ie. if they are, say, Jy/pix, then we don't need the beam, and we don't want to complain unnecessarily if the beam info isn't present.
This used to be the case with needBeamSize(), but I changed it and removed it from the reading-in bit, so revisit that...
comment:4 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Looking again at this - I think the degree of warning that we have in 1.1.11 is fine. The only time anything is printed is if there is no beam in the FITS file *and* the user has requested one of beamFWHM or beamArea (in which case it just notifies the user that that parameter is being used instead).
This ticket can be closed.
comment:5 Changed 12 years ago by
Milestone: | Release-2.0 |
---|
Some observations: