Migrate dashboard

[mhyee]

We have a bunch of old test models on the dashboard, and a new batch of test models. We'll need to update the models.

However, I want to keep the data somewhere, for reference. The models and results are still uploaded in S3 and should be fine. But all the data (timing, etc) will be lost when we clear out the dashboard.

I propose that we take a snapshot of the database and back it up. Then, we take a snapshot of all the HTML and upload it somewhere, for archival purposes. Snapping the HTML should be sufficient, because there is no dynamic content.

Once this is done, we need to re-upload the test models.

[mhyee]

Dashboard snapshotted and archived here: http://old-fydp-dashboard.mhyee.com/

I also removed all the submit request and upload links, so it's read-only.

Next step is to clean out the existing dashboard and upload the new models.

[mhyee]

Current dashboard cleared and put in maintenance mode. Will be recreating and uploading the models later. The plan is to then run them all for correctness on the oldest Moolloy commit that works, and then re-upload the solutions. Then we'll go in and manually mark all the runs as correct (which they are, by definition, since we're comparing all results to them.)

[mhyee]

Models are now uploaded. I will be commiting the upload script shortly. (No pull request.)

The next step is to queue up the tests; I will be doing this shortly. After that, I'll have to download all the models and package and upload their solutions.

EDIT: We'll also want to enable certain models for CI testing. And set all the tests to "passed."

There's one point of discussion, though.

I've uploaded decadal.als and sqlitesplc2011.als. decadal doesn't finish because it requires over 55 GB of memory. sqlite is equally bad, with over 12,000 solutions. We probably don't want to run them, until we make significant improvements to memory usage.

I'm considering deleting them from the dashboard completely. That way, we don't accidentally queue them up. Another option is to keep them on the dashboard, but delete the models. However, we'll have untested models on the dashboard, which might raise some questions when people look at the dashboard.

Thoughts? @AtulanZaman @cpkleynhans @joseph2625

[cpkleynhans]

I think it would be useful to at least get the correct solutions to all of our problems. 55 GB is not too bad as long as we only run a single worker on that machine. Is this 55 GB using PGIA, CGIA, IGIA or just regular GIA?

I agree that we don't want to show untested models on the dashboard. It might be worthwhile to add a hidden field to the models table and not display hidden models by default. That way they still exist and we won't need to upload them again, but the model isn't visible.

[mhyee]

I'm not sure decadal or sqlite ever completed. sqlite has far too many solutions because it has few constraints. We have ten other versions of sqlite with more constraints, which cuts down on the number of solutions. So I think there's an argument for deleting the bad sqlite model -- both from the dashboard and from our test models repo.

Decadal is not as clear cut. It's never been completed, but I think the issue is how poorly it was modelled. There should be a better way to rewrite the Alloy model, but I'm not sure how.

The 55 GB is under regular GIA.

I'm reluctant to add extra functionality, especially if it's only for two special cases.

[mhyee]

I've removed the sqlite and decadal models from the dashboard. I also removed sqlite from the test-models repo.

Currently, most of the models have completed and we have solutions. Some of the very large ones have not, however. Once we have time limits for workers, I can queue up those problems (under PGIA, our best algorithm for these types of problems) and hopefully get some solutions.