fgerzer
commented
8 years ago Developed in branch restoring_i133
For now, I have resolved to storing all the information in json files - this includes the candidates, meaning that we have data duplication between the exp.json and the results.csv. The exp.json takes precedence.
Right now, reloading is possible by passing the --continue_path argument to the REST_start_script, or the continue_path argument to start_apsis. This takes the path to a writing directory of lab_assistant, for example "/tmp/APSIS_WRITING/2016-02-21_22.59.02". In this path, it reloads the data from several json files: lab_assistant.json stores the global start time and the storage path for each of the experiment assistants. In the storage path for each experiment assistant, there are two json files: exp_assistant.json stores the experiment directory, the optimizer arguments, the optimizer class (as a string; this makes reloading custom optimizers difficult at the moment), the write frequency and the writing directory. experiment.json stores the experiment information. This includes the parameter definition (as a dictionary), the three candidate lists (each candidate as a dictionary), the experiment id, the notes and best candidate. Note that the latter is automatically recomputed on loading, meaning we don't actually have to store it and do so as a convenience for manual inspectation.
Right now, we are storing all results of an optimization in a csv file. It would be very useful to be able to easily restore the state of the experiment from that file. This requires implementation of