How shall I acknowledge Gaia? When do I acknowledge Gaia?

If you have used Gaia data in your research, please follow the credit and citation instructions as found here. When using Gaia DR1 data, we ask you to also cite certain Gaia Data Release 1 papers, as is indicated here. When using Gaia DR2 data, we ask you to also cite Gaia Data Release 2 papers, as indicated here. When using Gaia's Early Data Release 3 papers, we ask you to also cite Gaia's Early Data Release 3 papers as indicated here. When using Gaia Data Release 3 data, we ask you to also cite Gaia Data Release 3 papers, as indicated here. When using Gaia's Focused Product Release data, we ask you to cite the respective Gaia Focused Product Release papers as indicated here.

-

Both the random and systematic errors have been included in the published "parallax_error" column in Gaia DR1 through the error "inflation" determined through a comparison with external data (see Equation 4 in Section 4.1 in Lindegren et al. 2016). So, what happened for TGAS stars with parallax standard errors below 0.3 mas? Did we forget to inflate their errors? No: some errors can be smaller than 0.3 mas because a different factor was applied for each star.

The confusion is related to the 0.3 mas magic number, which might not have been explained sufficiently well. At some point, two particular AGIS test solutions using different sets of input observations (a different half of the focal plane) were created. The residuals showed significant structure, i.e., correlated errors. The typical difference was about +/-0.1 mas, but was much higher (or lower) in particular regions of the sky. The magic number 0.3 mas takes these regions into account but should not be interpreted as an RMS value for the whole sky. The problem is that we cannot quantify (and thus remove) these errors more precisely. Further details can be found in Lindegren et al. 2016, Appendices B and C.

So, summarising:

• Published standard errors of individual parallaxes do not need to be increased, they already have the systematic error included;
• Average parallax errors (e.g., based on several stars in a star-forming region) should not be trusted if below around 0.3 mas.

Gaia DR2 astrometry consistently uses the ICRS reference system and provides stellar coordinates valid for epoch J2015.5 (roughly mid-2015, where J stands for Julian year). Equinox J2000.0 is a currently obsolete concept linked to former, dynamical reference systems such as FK5 which were tied to the celestial equator at a particular time.

As of 1 January 1998, the International Celestial Reference System (ICRS) is the standard celestial reference system adopted by the International Astronomical Union (IAU). The ICRS is the set of prescriptions and conventions together with the modelling required to define, at any given time, a triad of orthogonal axes. The ICRS has its origin is at the barycentre of the Solar System, with axes that are space-fixed and kinematically non-rotating with respect to the most distant sources in the Universe. In practice, the ICRS is materialised by the International Celestial Reference Frame (ICRF) through the coordinates of a defining set of extra-galactic objects (quasars).

Prior to astronomers being able to define and use the ICRS and ICRF, dynamical reference systems were used based on observations of star positions tied in some way to moving objects in the Solar System. These reference systems refer to a mean equator and equinox at a given reference epoch (typically J2000.0), requiring precession/nutation models and corrections to deal with the time-variable fundamental plane. To within ~25 mas, mean J2000.0 equatorial coordinates are the same as ICRS coordinates such that, for "ordinary" applications, they can in practice be considered to be the same. For high-accuracy applications, the appropriate frame conversion shall be used.

Members of the scientific community will have access to Gaia data through intermediate catalogues, which will be released in the course of the mission (a release scenario is available).

Formal 'data rights' (for example, through a Call for Proposals) will not be assigned to any scientist involved in any aspects of the mission, including those scientists who participate in the data processing. Early access to the reduced data could, however, be awarded to individuals and groups participating in the data analysis, its validation, and documentation, according to procedures to be established by the Gaia Science Team, in consultation with the AWG and the executive committee of the Data Processing and Analysis Consortium.

The Gaia Data Rights are defined in the Gaia Science Management Plan ESA/SPC(2006)45 (SMP).

The Data Processing and Analysis Consortium (DPAC) is a large pan-European team of expert scientists and software developers. It is responsible for processing the Gaia data with the final objective of producing the Gaia catalogue.

DPAC has been in place since 2006 and has the task to develop the data processing algorithms, the corresponding software, and the IT infrastructure for Gaia. It also executes the algorithms during the mission in order to turn the raw telemetry from Gaia into the final scientific data products that will be released to the scientific community.

More information about the consortium and its structure is available here.

Planned maintenance to the Gaia Archive is announced through Gaia Cosmos and/or through a pop-up warning at the Gaia Archive. If you cannot access the Gaia Archive, and the unavailability of the Gaia Archive is not announced there, please contact us through the Gaia Helpdesk.

The first aid solution to most issues with the Gaia Archive GUI (from seemingly disappeared tables or strange behaviour after a query or problems signing in or out), is to close your browser, clear your cache and then retry. In most cases, this will solve things and you will be able to continue working in no time.

A second solution might be to switch browsers. Some browsers show more hickups than others in combination with the use of the Gaia Archive GUI.

Assumed is that you entered the Gaia Archive with a registered account. A registered account has the benefits of a dedicated user space with more space and larger quota. If you get an error message that you have exceeded your file quota, but you did not according to the information in your account, first check if you have jobs that failed to complete. You could see whether deleting the jobs that failed. solves the issue. Even though they seem to take up no space (0 bytes), sometimes they do and deleting them will free up space.

Another quick test to try and see if you can solve the exceeded file quota yourself, is to clear your cache (so close your browser and start a new private window) and then check again.

This table provides a link between the HEALPix identifier (level 6, so Nside = 2^6 = 64) and equatorial, Galactic, and ecliptic coordinates. The text file has four header lines and 49152 lines, each with seven columns separated by commas:

1. HEALPix identifier [nest scheme, Gaia default]
2. Right ascension [deg]
3. Declination [deg]
4. Galactic Longitude [deg]
5. Galactic Latitude [deg]
6. Ecliptic Longitude [deg]
7. Ecliptic Latitude [deg]
8. HEALPix identifier [ring scheme]

The conversion from Gaia source_id to HEALPix number with nest pixel ordering is described here. The built-in Archive function GAIA_HEALPIX_INDEX(order, source_id) can be used to do the transformation within ADQL queries, more details at the Archive Help - ADQL syntax (part 3). Additional functions available. Read here about ring and nested HEALPix ordering.

There are limits on how much data can be retrieved via ADQL (TAP) and how long a query can last. They are different for anonymous and registered (authenticated) users.

Anonymous access (as documented here):

• Synchronous query time-out: 30 s
  • Maximum number of rows if execution time <30s:   3,000,000
  • Maximum number of rows if execution time >=30s:       2,000
• Asynchronous query time-out: 90 min
  • Maximum number of rows: 3,000,000

Authenticated users (after login):

• Synchronous query time-out: 60 s
  • Maximum number of rows if execution time <60s:     unlimited
  • Maximum number of rows if execution time >=60s:         2,000
• Asynchronous query time-out: 120 min
  • Maximum number of rows: unlimited
• User space:
  • Jobs (ADQL query output): 20 GB
  • User tables: 1 GB

The DataLink maximum number of sources that can be retrieved is equal for registered and anonymous users: 5,000 per query.

Anybody can self-register for a Gaia ESA Archive user account through this page and then "SIGN IN" using the button in the top-right corner of the Gaia Archive, after which the reported user quota apply. In exceptional cases, upon demonstrated need, users can request (temporary) changes to their quota by sending a motivated request to the Gaia Helpdesk.

There are two ways to do this:

1. Basic tab: create a list of RA DEC coordinates (no header, one entry per line, separated by spaces) and upload them to the Archive as explained in this tutorial.
2. Advanced (ADQL): follow the White Dwarfs Exploration tutorial here.

The file to be uploaded to the basic tab of the Gaia Archive online search tool requires a specific format. The description of the format can be found by hoovering the mouse over the "Select a file with Target Names" and clicking once the question mark appears.

The input file has no header and one entry per line. Three different name resolvers are tried: Simbad, NED and Vizier. An intermediate job with the retrieved source properties (name, coordinates, parallax and proper motion, if available) is created and cross-matched against the Gaia Archive. A mixture of object names and positions in the sky (see previous FAQ) is allowed.

This problem most likely originates from the way Python is installed. Native Python distributions (e.g. those downloaded from python.org) include an “Install Certificate” script that install a set of SSL certificates. However, this is not the case if the user is running the Python distribution that comes along with the Conda package. A workaround is to execute the following command in a terminal:

export SSL_CERT_FILE=/lib/pythonX.Y/site-packages/certifi/cacert.pem 

Where "pythonX.Y" should be changed by your running version of Python (e.g. "python3.8").

The simplest way to do this is to manually select all the jobs that are listed in the Archive and then press the "Delete selected jobs" button on the bottom right corner of the Archive webpage. An alternative to this potentially tedious task is to use the Astroquery.Gaia Python module (link).

The steps to do this are detailed below:

from astroquery.gaia import Gaia

Gaia.login()

jobs = [job for job in Gaia.list_async_jobs()]
# To print all the jobs owned by the user:
for job in jobs:
    print(job.jobid)

# To remove all the jobs at once:
job_ids = [job.jobid for job in jobs]
Gaia.remove_jobs(job_ids)

First check the internet and perform a search with your question. You probably find that the answer to your question is already around on one of the Gaia information pages.

Please also have a look at the Gaia Archive help pages which contains lots of helpful information and tutorials or perform a search through the Gaia Data Release Documentation and the Gaia Data Release papers (Gaia DR1, Gaia DR2). The question might be hidden in the information on some other Gaia Cosmos page or Gaia pages of our DPAC partners. When not sure what information is around for a certain data release, check out the overview pages for each release: Gaia Data Release 1, Gaia Data Release 2, Gaia Early Data Release 3, Gaia Data Release 3 and Gaia Focused Product Release.

If the internet search is not providing you with answers to your question, feel free to contact the Gaia Helpdesk. The Gaia Helpdesk helps out with questions on the Gaia Archive, use of the Gaia Archive, content of the Gaia Archive and more.

Many of the catalogues hosted by the Gaia Archive (including the entire Gaia DR1, DR2, and eDR3 source catalogues) are available for bulk download in plain text (comma separated value, csv) format via the "Download" button visible in the landing page of the Archive. Because of the large volume of the data, the catalogue content is split in multiple files. To download all these files at once, it is suggested to use the "wget" command from a terminal. For example, the entire Gaia eDR3 source catalogue can be downloaded to the user local machine by typing the command:

wget --recursive --no-parent 'http://cdn.gea.esac.esa.int/Gaia/gedr3/gaia_source/'

The Astroquery.Gaia Python module (included in Astroquery, an Astropy affiliated package) is under continuous development. When a new Astroquery version is released it can happen that, during a few weeks, the Astroquery.Gaia documentation is updated although its associated Python module remains the same when trying to install it via e.g.

$ pip install astroquery

In order to install the most up-to-date version of Astroquery you can type:

$ pip install --pre astroquery

If Astroquery is already installed in your machine, then make sure to include the --upgrade install option:

$ pip install --pre --upgrade astroquery

The binary_masses table is described in Gaia Data Release 3: Stellar multiplicity, a teaser for the hidden treasure (Gaia Collaboration, Arenou et al. 2022). Indeed, a few thousand entries in this table have fluxratio <= 0 and 2996 actually also have fluxratio_upper <= 0. Most of such cases are a natural outcome of the estimation process for fluxratio that has been used, analogous to the presence of negative parallaxes.

Symbolically speaking, with R denoting the flux ratio F₂/F₁, the (linear) semi-major axis of the astrometric photocentre equals a₀= a (M₂/(M₁+M₂) - F₂/(F₁+F₂)) = a₁ – a R / (1+R), where a denotes the relative semi-major axis. As a result, R is estimated using 1 / R = a / (a₁-a₀) – 1.

In the processing for Gaia DR3, R has been estimated using a₀ from the astrometric processing of non-single stars, a₁ = a₁ sini / sini from the spectroscopic and astrometric processing, a from the period, M₁ from the Hertzsprung-Russell diagram, and M₂ from the spectroscopic mass function. Clearly, R is an estimated quantity with uncertainties (fluxratio_lower and fluxratio_upper). Although the true R is physically positive, estimates of it can be negative within the quoted uncertainties. Extreme cases, meaning when the flux ratio and its uncertainties are very unlikely compatible with being positive, point at special systems (for instance ternary systems) and/or inconsistencies in the astrometric and spectroscopic Gaia DR3 data processing of the object (for instance, when a₀ >> a₁, R would be negative, and in such cases, the spectra of the two components would not necessarily be resolved so that the “spectrocentre” variations could be measured instead). Such cases should obviously be treated with care.

Why do the Gaia measurements in the Archive include insignificant digits?

Indeed, all non-integer, non-Boolean, and non-character fields in all tables in the Gaia ESA Archive contain data that are stored and displayed to their full numerical precision, i.e., without taking into account the number of significant digits warranted by the uncertainties on the quantities. Although this seems not in line with common scientific practice, where measurements are typically provided with a number of significant digits that is compatible with their uncertainty estimates plus one extra digit, this has been a deliberate choice that has been made after careful consideration.

The key requirements in the discussion have been that data shall be immutable against the selected storage format (binary in the Archive database and ASCII in the bulk-download repository) and that data shall be stored with full numerical precision. In theory, usage of "numeric" datatypes at database level could support storage of data with a number of significant digits that varies from column to column but such a solution would have a strongly negative indexing performance impact and would produce quantisation effects in plots – especially when zooming in over a small dynamic range of a rounded quantity – without significant advantages, for instance through reduced storage needs or increased data transfer rates.

That still leaves the option to round the display resolution of the data on the fly while keeping the data stored in full numerical precision. Such rounding, however, cannot be applied on a per-column basis but would have to operate on a per-value-error pair (one row, two columns) since the rounding depends on the relative uncertainty of the measurement which often varies with source brightness. This, in turn, would require a complex (and risky) workflow which would require significant architectural changes in the Archive and which would come at a high performance price. More importantly, such a concept would always have a fundamental flaw in the area of user tables (or compound fields computed by users from published columns) by allowing inconsistencies in the resolution of catalogue data saved in the user area in comparison with the results of a query to the catalogue.

All in all, it has been decided to store and to display all measurements with full numerical precision and leave it up to the users, and their particular science cases, to apply the appropriate rounding.