Open kelle opened 1 year ago
Maybe we add one column to the Sources table- "Has Companion"
Answer: No.
Source and Companion should also be in the Relationships table described in #230
Could also include separations, orbital periods, dynamical mass, etc. Maybe should be renamed "Companion Parameters" instead of "Benchmark".
For reference, here is a ticket on AstrodbKit to improve the inventory logic so Companion parameters are fetched when searching for a Source: https://github.com/dr-rodriguez/AstrodbKit2/issues/59
Many ages are reported as ranges. Maybe we want to have upper and lower bounds for this table in addition to value and uncertainty.
Seems reasonable, but we'll have to be careful database schema definition of the tables. For example, for something with only lower/upper boundary, would value be NULL? If so, then the database table cannot specify that value should be NOT NULL as otherwise that will prevent these entries from being added. There isn't a database-specific mechanism to recognize that either value or both lower/upper is set, but we can code that into the python-specific tests we do.
In the schema, make the values all nullable. Use tests to make sure a value OR a range is present for every row.
David looking into options. See https://github.com/dr-rodriguez/DSII_LocalGroupDB/issues/4.
With regards to that issue, the idea was to use https://docs.astropy.org/en/stable/uncertainty/index.html#creating-distributions which allows us to build a Table out of astropy distributions and then fetch the median/mean from that. It would require more setup, but it might be possible.
Related to #230 which is about multiple systems where all of the components are UCDs. But this issue is about multiple systems where the companion is NOT a UCD and where we care more about some parameters of the companion which may be adopted for the Source, like age and metallicity.
I propose we handle this similar to the way we handle modeled parameters with a long table.