Our main services are automatization of astrophysical datasets querying, modeling physical parameters, and developing Python/R scientific code.
The main goal of the Yatsuani software developed is to automatize the process of the astrophysical data acquisition for defined ephemerides (RA/DEC/time). We are using following telescope data products: Gemini, CFHT, JCMT, HST, BLAST, MOST, DAO, MACHO, OMM, FUSE, UKIRT, NEOSSat, and VLASS.
We develop IT solutions in three-tier architecture model. This model is commonly used in the astrophysical IT systems dedicated for multi-teams and/or multi-datasets. The selection of this architecture is intended to allow any of the three tiers to be upgraded or replaced independently in response to changes in requirements or technology. For example, a change of ephemerides source or data structure would only affects the interface between the hidden layer and this source. The architecture of the software developed is presented below.
Astrophysical Objects Database – stores data of the objects with known names. I.e. if we run the program for target Yatsuani, all observations for this target would be stored here: time, RA, Dec, source FITS File, Source Instrument.
- Ephemerides Database – stores astrophysical data of the observations that compare with queried ephemerides in the form: time, RA, Dec, source FITS File, source Instrument.
This layer is composed of the five functionalities and two interfaces. Interfaces provide a connection between the software and external sources of data.
- I.e. we develop CADC Interface – provides two-way communication with the Canadian Astrophysical Database Center: database querying and FITS files URL access.
Functionalities cover all necessary logic, structurize ephemeris data or generating queries.
We are providing result data in the formats expected by external software like DS9, Astrometrica, or another.
Modeling physical parameters
The software solutions delivered by our firm meet the following requirements: a) may be run in various hardware configurations, b) should run cyclically or on-demand, c) should provide autoconfiguration function, d) the program should provide information about all previous observations of targets (specified by names) collected in astrophysical databases, e) should prepare and structurize the list of ephemerides provided in local and provided in an external URL folder, f) should validate FITS files based on header data: coverage between the field of view (FOV) and area of interest (AOI) defined by RA, DEC, and their uncertainties, g) should provide visualizations of downloaded FITS files and AOI as graphic files or PDF, and region files in DS9 or analogous software.
We are using the following external libraries like astropy, numpy, matplotlib etc.
There are two main use scenarios provided. First: simple run on the local machine, second continuously running on the cloud-based virtual machine (i.e. Microsoft Azure).