7.7.6 Post-processing

The solutions provided by the upstream modules have been stored in a convenient internal model which is solution-type agnostic. As the solution combiner reads all solutions to select those to apply combination it also transforms the internal solutions into models that are similar to those in the archive. Thus it produces 4 different tables, nss_two_body_orbit, nss_acceleration_astro, nss_non_linear_spectro and nss_vim_fl, which encapsulate several nss_solution_types. Table 7.6 shows each table and all the available nss_solution_type contained.

Solutions with types OrbitalPoorlyContrained, StochasticAstro, ThirdDegreeTrendSB1, StochasticSB1 and StochasticSB2 were not planned to pass to the output for the Gaia DR3, so if they were not combined to derive a solution that was acceptable they were rejected at this stage. During this operation the software assigns the uncertainties to the parameters, and was also in charge of transforming the covariance vector into correlation vector and cleans the diagonal, adds the number of astrometric, photometric or spectroscopic observations used and creates the bitIndex and passes the flags that occurred during the processing of the source by each module. The form of the correlation vector corr_vec is described in detail in the corr_vec data model documentation. The bit_index is a boolean mask that provides to the user a way to extract which fields are fitted in each nss_solution_type and being available in the corr_vec. Its full description and possible values can be found in the bit_index documentation. The flags that came out of the processing in the case of uncombined solutions are copied directly to the output. However in the case of combined solutions the flags of the input models and the combination processing are aggregated and passed to the output. The flags field is a long number that which bit translation is presented in the flags documentation.

As sources may exhibit their binarity in more than one ways, it is likely to have sources identified by their astrometry, photometry and spectroscopy in any combination and processed by the corresponding module producing a solution with different nss_solution_type. Thus, each source may have multiple inputs in a table or in different tables but always with different nss_solution_type. Multiple solutions within the same table may occur only in the nss_two_body_orbit table as it is the only table that contains nss_solution_types from more than one non-single star processing units. A different case of multiplicity is the OrbitalTargetedSearch sources as these sources where processed twice, one with the normal processing pipeline and one separately excluded by the combination procedure and passed directly to the output.

The post-processing phase has also been used to filter out solutions which were lately found as possible spurious.