Having mutable Python objects as default arguments causes trouble, because it uses the same object each time the function is called.

In [1]: def append_a(lst=[]):
   ...:     lst.append("a")
   ...:     return lst
   ...:

In [2]: lst = append_a()

In [3]: lst = append_a()

In [4]: lst
Out[4]: ['a', 'a']

We might expect the second instance of lst to contain a single element because it's using the default argument of [], but because it uses the same instance of the list object each time the function is called, it contains two elements.

The way we work around this is by using None as the default argument, then creating an object if the argument is None:

def __init__(self, model, solver=None, **kwargs):
    if solver is None:
        solver = SolverFactory("ipopt")

Also, if you expect a solver object to be passed, you should make solver_obj the name of the function argument. It would be even better to add it as a config argument instead of an argument to __init__.

I assume that ipopt_watertap has some set of default options different than those in IDAES.

Thanks Doug! I didn't realize default arguments for each instance builds on top of the previous ones. I've set the default solver argument to None.

I'm not too familiar with the differences between ipopt and ipopt-watertap other than the fact that using ipopt has caused issues in the past.

You can find WaterTap solver options in the repo: https://github.com/watertap-org/watertap-solvers/tree/main

@MarcusHolly It's a tricky issue, and it would have caused major headaches for me if I hadn't been alerted to it by senior team members.

Could you please also change the name from solver to solver_obj? Typically if we had solver as the default argument, we'd pass the string "ipopt" instead of an IPOPT solver object.

Sure