Pyomo.DoE bugfixes

[djlaky]

Fixes # .

1. Ensured square solve (e.g., fix the experiment inputs) when solving each scenario block.
2. Added self.tee to sequential compute FIM method

Summary/Motivation:

Fixing some bugs found in Pyomo.DoE over the past month.

Changes proposed in this PR:

• Adding fixing/unfixing of experimental design decisions to ensure a square solve for each finite difference scenario
• Added a reference to the internal tee value in the compute FIM methods

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[djlaky]

@smondal13, @adowling2

Bug we saw this morning that was fixed but not pushed.

[adowling2]

@djlaky Is this ready for review by the Pyomo team?

[adowling2]

This looks good to me.

[djlaky]

@djlaky Is this ready for review by the Pyomo team?

Yes. This should be ready for review @blnicho @jsiirola

[blnicho]

Is there any model checking before this that ensures fixing b.experiment_inputs will result in a square model?

[blnicho]

Also, is there any chance that a user will have already fixed some of these inputs in which case we shouldn't unfix them?

[djlaky]

I think there is not a chance of this. The understanding of Pyomo.DoE is be that all the experiment inputs (as labeled) should be fixed during initialization and free during the optimization call. If they should be fixed, the user should not include them in that suffix.

@adowling2, can you check to make sure what I said is correct?

[djlaky]

Is there any model checking before this that ensures fixing b.experiment_inputs will result in a square model?

There is not.

Since the blocks are built on cloning the model from 'get_labeled_model()', the model output from this call needs to be square.

Also, is there a way to tell if the model is square using the 'res' object in line 1127? That would be the best case, then the user can get an error if their model is not square and I can write a test in the suite.

[adowling2]

I like the idea of this failing gracefully if the user tries running it with a non-square model. I have less of an opinion on if the check happens here or somewhere else.

[adowling2]

Maybe we have a custom function that inspects the build model and summarize the number of measurements, equations, parameters, inputs, etc. and estimates the degrees of freedom. I am thinking "If someone contacted me asking for help with ParmEst or Pyomo.DoE, what would I am to know about the model? I'm s there a way we can make the first debugging step to run "model_diagnostics" or similar and report the output.