Make solph work with pyomo >= 0.6

[uvchik]

At the moment the use of Pyomo >= 0.6 leads to very high computing times ( up to 100 times longer). @gnn found out, that this is caused by the root logger but only if the logging level is DEBUG. The problem is located in the Model class.

1. Therefore I changed the default logger level in oemof.tools to INFO, because the logger from oemof.tools is used in almost every solph example. In some examples the logger is explicitly set to DEBUG, so changing the default value will not help.
2. As it is also possible to set the logger in a different way, I added a function to check the level of the logger in the Model class. Now an exception will be raised if the root logger level is set to DEBUG (default. WARNING). This exception can be avoided if the model is initialised using debug=True: model = solph.Model(energysystem, debug=True). This can be done with a small model if the debugging mode is needed. If it was not intended to use the debug-level the level can be changed:

import logging
logging.getLogger().setLevel(logging.INFO)

This will cause long computing times or an exception :

from oemof.tools import logger
logger.define_logging(
    screen_level=logging.DEBUG,
    file_level=logging.WARNING,
)

If the new logger of oemof.tools is released, using the default values will fix the problem

logger.define_logging()
# or
logger.define_logging(
    screen_level=logging.INFO,
    file_level=logging.WARNING,
)

• Related issues?
  Exclude pyomo version that causes a too long computing time #760
  Release/v0.4.3 #766

• Things to do:

  • Fix tests
  • Adapt examples, if the DEBUG level is explicitly set
  • Write tests for the Exception
  • Change docstring of oemof.tools logger to make clear, that the root logger is touched by the function
  • Make a release of oemof.tools to make it easy to set the dependency from oemof.solph

In the long run we should find out the reason of the problem, because forbidding the logging level is more a workaround than a real solution of the problem. But it is good that it makes it possible to use the actual version of Pyomo.

[p-snft]

In the long run we should find out the reason of the problem, because forbidding the logging level is more a workaround than a real solution of the problem. But it is good that it makes it possible to use the actual version of Pyomo.

I guess, it is because we use a non-standard way for initalisation. Working on #814, I've found that Pyomo's documentation describes pretty strict RAII where the variables (including limits) are not touched after initalisation. In fact, we iterate over most variables and change them. Depending on the internal optimisation of Pyomo, this might lead to significant performance losses.

PS: If this is the reason, the fix at our side would require a lot of refactoring. Still, it would not be API breaking.

[pep8speaks]

Hello @uvchik! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2022-03-28 07:26:01 UTC

[uvchik]

In my tests this works as fast as before.

@p-snft I am not sure if there is some more potential to speed up the process, but at least it not works with the actual version of Pyomo as good as before.

[p-snft]

Thanks for solving the issue. Speed is fine for me, again.