Make the solver an attribute of the Model class

[raoulcollenteur]

I would like to store the Solver object as an attribute of the Model class. If something goes wrong now within the call to the solver we can't access the whole object which is annoying for debugging. This will also help in developing new solvers I plan to work on next month.

This would also mean we don't have to initiate a solver object every time we solve. This will only be an internal change for now.
Within the solve method it would look something like this:

self.solver = Solver(args)
self.solver.solve(args) or ml.solver.minimize(args)

and then we can access the solver as:

ml.solver

Anyone against this proposal?

Ps. looks like I'll need to block a day or two to do some programming on Pastas next week so other enhancements I could implement in the solver are welcome. :)

[raoulcollenteur]

Possibly add the long standing issue #40 to this.

[raoulcollenteur]

lmfit 0.9.13 seems to cause problems when MinimizerResult.covar does not exist. Needs to be fixed as well.

[dbrakenhoff]

I think this is a good idea!

Semi-related to this: can we add the objective function value to the fit report?

I did this in my WellModel PR because of the earlier issues with optimization, and this makes it easy to compare between two solve results. It's also not weird to provide the value of the objective function in the fit report, I think. And there was a nice space for it next to the type of solver in the fit report.

[raoulcollenteur]

I'll start a new branch for these changes in a bit. Let's make a To Do list.

• Store solver as attribute of model
• Add solve method to solvers
• Fix covar bug for LmFit
• Calculate parameter correlations from covariance matrix
• Add correlations to fit_report
• Make all "vary" parameters real booleans
• ��Move objective function out of solver class
• Add objective function value top fit_report

EDIT: solver-branch now created to work on the solvers.

[mbakker7]

And move objective function out of solver class

…

On Thu, Aug 1, 2019 at 1:40 PM Raoul Collenteur ***@***.***> wrote: I'll start a new branch for these changes in a bit. Let's make a To Do list. - Store solver as attribute of model - Add objective function value top fit_report - Fix covar bug for LmFit - .... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#133?email_source=notifications&email_token=AAKM3SD6BPMBM4ANZKEOTGDQCLDSXA5CNFSM4III6BX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3KJFTI#issuecomment-517247693>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKM3SHB6J7VATBB62UZCJLQCLDSXANCNFSM4III6BXQ> .

[dbrakenhoff]

I was discussing some pastas results with Ruben (specifically the solver quitting after 2 iterations resulting in evp = 0.0 when solving with freq="14D", while solving on a daily basis yields an EVP of 95%) and we figured it would be nice to have an option in the solver to log the parameter values for each iteration.

So for example, if the log_level was set to debug, log the starting values and the subsequent parameter values least squares decides on, and also maybe log some of the output that least squares generates after it's done (e.g. parameters hitting bounds etc.)

[raoulcollenteur]

This is already possible by using using the callback argument implemented in the Solver but you'd have to define your own callback method. I used this for the example you mentioned.

[dbrakenhoff]

Cool, that works.

[raoulcollenteur]

Update, I have started to implement the above changes. I think it is already starting to look good. You can now type:

ml.solver.some_attribute

and get some information that is stored in there. Maybe it would be better to use the name ml.fit..?

I have also changed the behaviour that once a certain solver is chosen (e.g., lmfit) this solver is the default for the model. I think this makes sense.

Couple of things to do still. Big thing is how to implement the objective functions but I'll think about it and come up with some proposal.

[raoulcollenteur]

I'll start a new branch for these changes in a bit. Let's make a To Do list.

• Store solver as attribute of model
• Add solve method to solvers
• Fix covar bug for LmFit
• Calculate parameter correlations from covariance matrix
• Add correlations to fit_report
• Make all "vary" parameters real booleans
• ��Move objective function out of solver class
• Add objective function value top fit_report

EDIT: solver-branch now created to work on the solvers.

Bringing the final two changes to another projects in issue #40 .

Just did a PR with the changes.