Looks good. Two remarks:

• Should we check somewhere that the length and order of problem.types and decision_variables match (and throw a useful error if it isn’t? Or will that always be the case?
• Is there any test coverage on this code?

1. fair point. At a minimum, some assertion might be a good idea. It can only happen if you use a different model for to_problem than the one you used for the optimization.
2. optimization.py is one of the parts of the workbench with the least code coverage. As part of the larger rework of the optimization, I want to address that as well. This is just a quick bug fix and not per se the place to address this coverage issue.

I rechecked the code. There is no need for a check because problem.types and problem.parameter_names will always match. the bigger issue might be a mismatch between problem.parameter_names and what is in the row. This would entail a try-catch around the getattrr calls. The other error could be that there are more columns in the archive than the combined length of parameter_names and outcome_names. This can happen if the model used for to_problem does not match the model used to create the optimization results for which you are rebuilding the population. I'll add an explicit check for this as well.

coverage: 80.926% (-0.2%) from 81.097% when pulling ac6b326 on bugfix_optimization into cccad48 on master.