Experiment should log time of execution and its status #403
Assignees
Comments
|
Is this referring to putting the information in a database table, or just a log message? If database we did talk about this before as a 'batches' table: #289 I kind of like the name 'experiment_runs' for a table name. |
|
It is worth thinking through how this relates to partial config and runs. What is they just run timechopping or and label creation? Should there be any row at all in this case? Or a row that has the name of the most recent phase that was run? |
thcrock
added a commit
that referenced
this issue
Mar 18, 2019
At long last, the experiment runs table. It contains a variety of metadata about the experiment run, such as installed libraries, git hash, and number of matrices and models built/skipped/errored. Similarly, the experiments table is augmented with data that doesn't change from run-to-run (e.g. number of time splits, as-of-times, total grid size) A variety of methods on the Experiment act as 'entrypoints'. The first entrypoint you hit when running an experiment (e.g generate_matrices, or train_and_test_models) gets tagged on the experiment_runs row. - Add Experiment runs table [Resolves #440] [Resolves #403] and run-invariant columns to Experiments table - Add tracking module to wrap updates to the experiment_runs table - Have experiment call tracking module to save initial information and retrieve a run_id to update with more data later, either itself or through components (e.g. MatrixBuilder, ModelTrainer) that do relevent work - Have experiment save run-invariant information when first computed
thcrock
added a commit
that referenced
this issue
Mar 18, 2019
At long last, the experiment runs table. It contains a variety of metadata about the experiment run, such as installed libraries, git hash, and number of matrices and models built/skipped/errored. Similarly, the experiments table is augmented with data that doesn't change from run-to-run (e.g. number of time splits, as-of-times, total grid size) A variety of methods on the Experiment act as 'entrypoints'. The first entrypoint you hit when running an experiment (e.g generate_matrices, or train_and_test_models) gets tagged on the experiment_runs row. - Add Experiment runs table [Resolves #440] [Resolves #403] and run-invariant columns to Experiments table - Add tracking module to wrap updates to the experiment_runs table - Have experiment call tracking module to save initial information and retrieve a run_id to update with more data later, either itself or through components (e.g. MatrixBuilder, ModelTrainer) that do relevent work - Have experiment save run-invariant information when first computed
thcrock
added a commit
that referenced
this issue
Mar 18, 2019
At long last, the experiment runs table. It contains a variety of metadata about the experiment run, such as installed libraries, git hash, and number of matrices and models built/skipped/errored. Similarly, the experiments table is augmented with data that doesn't change from run-to-run (e.g. number of time splits, as-of-times, total grid size) A variety of methods on the Experiment act as 'entrypoints'. The first entrypoint you hit when running an experiment (e.g generate_matrices, or train_and_test_models) gets tagged on the experiment_runs row. - Add Experiment runs table [Resolves #440] [Resolves #403] and run-invariant columns to Experiments table - Add tracking module to wrap updates to the experiment_runs table - Have experiment call tracking module to save initial information and retrieve a run_id to update with more data later, either itself or through components (e.g. MatrixBuilder, ModelTrainer) that do relevent work - Have experiment save run-invariant information when first computed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Experimenshould log:created_atstart_running_atend_running_atfinal_status(i.e.COMPLETED,FAILED,WAITING)The text was updated successfully, but these errors were encountered: