Beam area computation: units mismatch?

[vleugelcomplement]

Hello,

Thanks for BBarolo, a really randomAdjective(1) piece of software!

We have stumbled upon what could be a mismatch of assumed units between the code and the docs in the beam area computation function. It looks like calcArea expects bmaj and bmin in degrees (because CDELTis are usually degrees per pixel), while the docs explicitly state that they should be in arcseconds.

So, could you please clarify, is it an intended behavior and we are missing something important or is it just a typo?

[editeodoro]

Hello!

Yes, that is the intended behavior. The bmaj and bmin that goes into the calcArea function are not exactly the BMAJ and BMIN parameters given as user inputs and described in the documentation. There is a conversion made in the checkBeam function. So basically, what goes inside calcArea is always in degrees.

I hope this clarify the apparent mismatch.

Enrico

PS: I really appreciate that you noted the randomAdjective function...;-)

[vleugelcomplement]

Thanks for the response!

For our inputs the puzzle is probably somewhat more convoluted.. I see (by injecting some printf's) that bmaj and bmin are being read at header_read function, where they are converted to arcseconds only if BMMAJ/BBMIN keyword contains the letter 'D' (it looks like the docs are silent about this quirk). This function ends with just a call to calcArea, which evaluates the beam area to some nonzero value, so it passes the check in checkBeam function.

Could you please further clarify, what is the purpose of BMMAJ keywords or where can we learn more about them (and should we use them at all)?

P.S. really appreciate the fantastic piece of ASCII art that greets novice users :)

[editeodoro]

In general, the beam information is in the header of a FITS file. The relevant FITS keywords are BMAJ and BMIN, which are commonly used and FITS standard, with units in degrees. However, in the years, people have used alternative keywords, like (BMMAJ, BBMIN) or (CLBMMAJ, CLBMMIN). The header_read function try to read them all and in general it assumes they are in degrees.

However, the BMMAJ/BBMIN keywords were used in a weird way in the WHISP HI survey back in the days. In this survey, they used a 'D' when the beam was in arcsecs instead that degrees. When I wrote the code, I was working with these data, so I added the workaround that you found. This is NOT FITS standard however! I can imagine some data may exist where they just indicate a 'D' instead of an 'E' in the exponential notation. If only astronomers could follow simple standards....:-) Do you happen to have BMMAJ and BMMIN with a 'D' notation but in degrees?

All the above are relative to FITS keywords. Sometimes, a FITS file does not have any of the above information. In this case, the user can specify the BMAJ, BMIN and BPA in the parameter file (or beamFWHM alternatively), in this case in arcsecs. When it enters the checkBeam function, the code checks first if there is any of above FITS keywords has been found. If not, it uses the parameters inputed by the user (after converting them to degrees).

I hope I did not add further confusion! Let me know if you have any further doubt.

[vleugelcomplement]

Thanks again!

I got it! We have BMAJ/BMIN in a fits header, while the docs describe beam parameters specified by parameter file. So, it looks like we have just misread the docs, sorry for this fuss..

[editeodoro]

Great, no problem at all, always happy to help! I am closing this.

Enrico