Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What kind of a output format should be used for the parameter files? #45

Open
3 tasks
rbiswas4 opened this issue Sep 8, 2016 · 0 comments
Open
3 tasks
Labels

Comments

@rbiswas4
Copy link
Owner

rbiswas4 commented Sep 8, 2016

Currently, we understand well that the light curve information should be stored in two output objects to normalize them. The first one is homogeneous data as found in light curves (ie. time, flux, fluxerror). The second one stores model truths. This normalization is sensible because the first table has one record per observation of an astrophysical object leading to (numObs times numObjects records, though some may be suppressed due to being trivially outside a transient object's lifetime) , while the second has one record per object. For a single class of objects these may be stored in arrays and serialized to disc in the form of csv/hdf/relational databases.

The situation is more complicated if there are different classes of objects. The light curve storage and serialization is still the same, but the serialiation of model truths is much harder as the parameters of different objects form an inhomogeneous set of records.

How should we attempt to serialize these data? Should we be using

  • many relational database tables with one table per class of object?
  • Many groups in a hdf file, with each group representing a class of objects and therefore homogeneous?
  • All files in a noSQL database ?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant