Vizier search often emits UnitsWarning: Unit 'e' not supported by the VOUnit standard.

[orionlee]

When performing Vizier search, it often emits the following (arguably useless) warning.

UnitsWarning: Unit 'e' not supported by the VOUnit standard.  [astropy.units.format.vounit]

It appears that if the search result contains data with the unit of electron (e.g., flux), the warning is emitted.

Example

The following code snippet would emit the warning.

def search_nearby(ra, dec, catalog_name="I/345/gaia2", radius_arcsec=30):    
    c1 = SkyCoord(ra, dec, frame="icrs", unit="deg")
    columns = ["RAJ2000", "DEJ2000", "Source", "Gmag", "FG"]

    result = Vizier(columns=columns).query_region(
        c1,
        catalog=[catalog_name],
        radius=Angle(radius_arcsec, "arcsec"),
    )
    return result[catalog_name]

ra, dec = 263.59892769, 74.47212807
result = search_nearby(ra, dec)
result

If one removes column "FG" (G-band mean flux, with the unit of e-/s) from result, there will be no warning.

Environment:

Astroquery: 0.4.6
Astropy: 5.0.3

Some older version of Astroquery + Astropy does not emits the warnings, e.g.,
Astroquery: 0.4.2
Astropy: 4.2.1

[keflavich]

I think electrons per second is not a VO-supported unit, as the warning suggests - this isn't just a syntax issue, but a totally unsupported unit. I'm not sure there's anything we can do about this.

@aoberto are there any discussions within CDS about how to handle non-VO-compliant units?

[bsipocz]

somewhat related to #2349. In the ideal world the data providers would release fits files that adhere to fits standards and votables that are VO compliant, but being pragmatic I think we could add some workarounds into astroquery, either by silencing these warnings within astroquery, or fix the units ourselves (for heasarch I think the latter makes sense, vizier is a bit different as there could be a lot of non-vo compliant content that were pulled from papers).

[orionlee]

My use case is to pull data Gaia catalog for interactive uses. The warning just creates noises for end users.

I could silence those warnings on end. But it seems to me that the use case is common enough (pulling data from Vizier. I suspect there are many other catalogs that contain data with electrons as an unit, in addition to Gaia), that astroquery should handle it as well.

[bsipocz]

When working with gaia you may want to use astroquery.gaia instead than pulling the whole catalogue from vizier.

Anyway, the noise is good, it has its well-intended purpose, and I don't think we should start fixing things for the purpose of silencing those, basically, astroquery shouldn't be the one making decisions for the user (you can always decide to silence warnings), or cleanup for the data provider.
But we should consider adding some workaround during our parsing steps until the data providers fix their non-standard usage.

[eerovaher]

The intent of the code in VizierClass.parse_vizier_votable() seems to be that VOTable-related warnings should be silenced unless the user specifies verbose=True:

astroquery/astroquery/vizier/core.py

Lines 753 to 759 in db3f08b

	def parse_vizier_votable(data, verbose=False, invalid='warn',
	get_catalog_names=False):
	"""
	Given a votable as string, parse it into dict or tables
	"""
	if not verbose:
	commons.suppress_vo_warnings()

However, only VOWarning instances are suppressed and the reported UnitsWarning is not such an instance:

astroquery/astroquery/utils/commons.py

Lines 338 to 345 in db3f08b

	def suppress_vo_warnings():
	"""
	Suppresses all warnings of the class
	`astropy.io.votable.exceptions.VOWarning`.
	"""
	warnings.filterwarnings("ignore", category=votable.exceptions.VOWarning)

If there is agreement that astroquery.astroquery.utils.commons.suppress_vo_warnings() should also suppress VOTable-related UnitsWarning instances then I can open a pull request for that.

[bsipocz]

Hmm, that is very interesting and makes me really wonder whether this should really be fixed upstream to make those in fact VOWarnings rather than UnitsWarning? E.g. W50 looks to be there for this case.

[eerovaher]

I looked a bit more into this and came to the conclusion that the reported issue is caused by a bug in astropy, see astropy/astropy#13017 (comment) for details.

[Firestar-Reimu]

But I still see warning now like:

WARNING: UnitsWarning: Unit 'al' not supported by the VOUnit standard. Did you mean alm or alx? [astropy.units.format.vounit]
WARNING: UnitsWarning: The unit 'G' has been deprecated in the VOUnit standard. Suggested: 0.0001T. [astropy.units.format.utils]

(Why do you only support SI units?)

[bsipocz]

As the labels indicate, this is an upstream and rather complicated issue, there isn't much we can do about it in astroquery. Do filter the warnings out as a workaround at the user level if they are too bothersome.

[ManonMarchand]

Just to add to the conversation, right now there is no plan to change the units in already published VizieR tables.