Skip to content

Commit

Permalink
Updating paper
Browse files Browse the repository at this point in the history
  • Loading branch information
athob committed Nov 21, 2023
1 parent 58d4fd1 commit 4b9a40e
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions paper.md
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@ The ``ananke`` pipeline by @Sanderson:2020, though powerful, lacks user-friendli

![Schematic illustrating the inner framework of the ``py-ananke`` pipeline. The modules ``py-EnBiD-ananke`` and ``py-Galaxia-ananke`` are referred to by their import names ``EnBiD_ananke`` and ``Galaxia_ananke``, with their respective ``C++`` backend softwares ``EnBiD`` and ``galaxia-ananke``. The pipeline framework is illustrated from input to final output from left to right, showcasing the different objects and their purposes.\label{fig:framework}](ananke_framework.pdf)

The implementation of ``py-ananke`` is designed to streamline the ``ananke`` pipeline, and to prevent the need for the user to manually handle the interface between ``Python`` and the ``C++`` backend software. It notably introduces dedicated wrapper submodules (hosted in repositories that are separate from that of ``py-ananke``, but linked as ``git`` submodules), namely ``py-EnBiD-ananke`` and ``py-Galaxia-ananke``, specifically developed to handle the installation and utilization of these ``C++`` subroutines, namely ``EnBiD`` [@EnBiD:2006;@EnBiDCode:2011] and a modified version of ``Galaxia`` [@Galaxia:2011;@GalaxiaCode:2011] called ``galaxia-ananke``. These submodules relieve users from the need to directly manage the ``C++`` software while isolating the ``C++`` wrapping process. This allows ``py-ananke`` to focus on processing inputs and outputs using pure ``Python``. Figure \autoref{fig:framework} illustrates the inner framework process of the full pipeline, showcasing the various module and submodule classes and where they are used in an input to output fashion from left to right.
The implementation of ``py-ananke`` is designed to streamline the ``ananke`` pipeline, and to prevent the need for the user to manually handle the interface between ``Python`` and the ``C++`` backend software. It notably introduces dedicated wrapper submodules (hosted in repositories that are separate from that of ``py-ananke``, but linked as ``git`` submodules), namely ``py-EnBiD-ananke`` and ``py-Galaxia-ananke``, specifically developed to handle the installation and utilization of these ``C++`` subroutines, namely ``EnBiD`` [@EnBiD:2006;@EnBiDCode:2011] and a modified version of ``Galaxia`` [@Galaxia:2011;@GalaxiaCode:2011] called ``galaxia-ananke``. These submodules relieve users from the need to directly manage the ``C++`` software while isolating the ``C++`` wrapping process. This allows ``py-ananke`` to focus on processing inputs and outputs using pure ``Python``. \autoref{fig:framework} illustrates the inner framework process of the full pipeline, showcasing the various module and submodule classes and where they are used in an input to output fashion from left to right.

## ``py-EnBiD-ananke``

Expand All @@ -90,7 +90,7 @@ The ``py-EnBiD-ananke`` submodule handles the installation of ``EnBiD`` and inte

The full description of ``Galaxia`` is detailed in @Galaxia:2011, but to summarize, ``Galaxia`` uses a given galactic model to generate a population of synthetic stars that composes it, with its associated astrometric and photometric catalog. The original pipeline had a more general purpose as the input galactic model can be generated via an N-Body simulation as much as it can be specified as a set of density distributions. However, for our purpose with our modified version ``galaxia-ananke``, the pipeline uses cosmological simulation star particle data provided by the user, specifically the mass, position, velocity, age, metallicity & abundances, as well as phase space densities for each star particle.

``galaxia-ananke`` generates the synthetic stars by sampling phase space to reproduce the distribution representing overlapping phase space kernels centered at each particle, invertly scaled with the particle density, and by sampling mass to reproduce a @Kroupa:2001 initial mass function. Each synthetic star carries the other properties of the parent particle such as age and metallicity, with which the masses are used to interpolate photometry from pre-computed isochrone tracks (details on those are described in the section [Dependencies]{label="Sec:Dependencies"}). Finally, astrometry is determined by converting the phase space coordinates to celestial coordinates given a user-specified observer phase space position.
``galaxia-ananke`` generates the synthetic stars by sampling phase space to reproduce the distribution representing overlapping phase space kernels centered at each particle, invertly scaled with the particle density, and by sampling mass to reproduce a @Kroupa:2001 initial mass function. Each synthetic star carries the other properties of the parent particle such as age and metallicity, with which the masses are used to interpolate photometry from pre-computed isochrone tracks (details on those are described in the section \autoref{sec:dependencies}). Finally, astrometry is determined by converting the phase space coordinates to celestial coordinates given a user-specified observer phase space position.

The ``py-Galaxia-ananke`` submodule handles the installation of ``galaxia-ananke``, a modified version of ``Galaxia``, and interfaces with its pipeline. The ``galaxia-ananke`` source code lives in a separate repository which is linked as a ``git`` submodule in the repository of ``py-Galaxia-ananke``. At installation, ``py-Galaxia-ananke`` builds and packages the executable of ``galaxia-ananke`` from its source code directly from its ``git`` submodule, as well as the operational data for ``galaxia-ananke`` which includes the collections of isochrones sets. All the resulting ``galaxia-ananke`` packaged data is eventually placed in a dedicated cache folder that is created in the site-specific directory of the running ``Python`` installation.

Expand All @@ -114,7 +114,7 @@ The implementation of ``py-ananke`` involves six classes, with only one - ``Anan
The latter two driver classes require respectively extinction coefficients and error models that are photometric-system-dependents and can be specified by the user. Also, ``py-ananke`` is designed with dedicated source files to contain default implementations, which currently only hold default for the Gaia photometric system. Future updates will continue to expand this further.

# Dependencies
\label{Sec:Dependencies}
\label{sec:dependencies}

``py-ananke`` makes use of the following ``Python`` packages:

Expand Down

0 comments on commit 4b9a40e

Please sign in to comment.