Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Greybox model DOF counitng in degrees_of_freedom function #1512

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

avdudchenko
Copy link
Contributor

@avdudchenko avdudchenko commented Oct 26, 2024

Fixes

The current degrees_of_freedom function does not properly account for GreyBoxModel as a set of constraints, resulting in an incorrect number of DOFs being presented.

Summary/Motivation:

With increased usage of GreyBoxModel (specifically Reaktoro-pse) there is a need to support DOF counting when building IDAES model with GreyBoxModels

Changes proposed in this PR:

-add the capability to add unfixed input and output vars on GreyBox model to ComponentSet produced by unfixed_variables_in_activated_equalities_set
-add a counter for the number of "equalities" in gray box model in number_activated_equalities by adding number_grey_box_equalities method

Counting the number of equalities in GreyBox model:
GrayBox models do not provide traditional Pyomo Constraints that bind inputs to outputs as such, we need to assume how many GrayBox model DOFs there are.

In most cases (at least I can't think of any exceptions) GreyBoxes must be 0DOF in the eyes of Pyomo/IPOPT as each output must be some sort of function of provided inputs, regardless if the internal model in the GreyBox is 0DOF, an optimization, or it exposes internal constraints to solve the problem.
As such, it should be safe to assume that the number of outputs equals the number of equality constraints.

Legal Acknowledgement

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

  1. I agree my contributions are submitted under the license terms described in the LICENSE.txt file at the top level of this directory.
  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.

@avdudchenko avdudchenko changed the title Add support for Graybox model DOF counitng in degrees_of_freedom function Add support for Greybox model DOF counitng in degrees_of_freedom function Oct 26, 2024
@codecov-commenter
Copy link

codecov-commenter commented Oct 26, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.01%. Comparing base (53f756b) to head (d9ff557).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1512      +/-   ##
==========================================
+ Coverage   76.99%   77.01%   +0.02%     
==========================================
  Files         382      382              
  Lines       61994    62074      +80     
  Branches    10147    10165      +18     
==========================================
+ Hits        47732    47809      +77     
- Misses      11854    11858       +4     
+ Partials     2408     2407       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

) + number_grey_box_equalities(block)


def number_grey_box_equalities(block):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

number_of_X is less ambiguous in English.
Can add -> int to indicate return type and, if it's possible, the expected type of block.
In docs: "Method to" is superfluous and at any rate this is a function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


def number_grey_box_equalities(block):
"""
Method to return the number of equality constraints in GreyBox
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say, "Compute total number of equality constraints for all GreyBox objects in this block."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Member

@andrewlee94 andrewlee94 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this, it is a case we have not considered and Greybox models are becoming more important. To start with, I had a few suggestions for more tests and modularization of the code.

However, a more significant request would be to add these tools and (and some test cases) into the diagnostics toolbox as well. We should at a minimum check that the DoF and model statistics output (number of variables and constraints) accurately reflect the model with a Greybox present. It might also be nice to add additional sub-rows in the model statistics for greybox components when they are present. Finally, we should look for any edge cases that might occur with the rest of the toolbox and if there are other things we need to consider when using greybox models.

@@ -529,7 +555,7 @@ def deactivated_inequalities_generator(block):
block : model to be studied

Returns:
A generator which returns all indeactivated equality Constraint
A generator which returns all in deactivated equality Constraint
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "in" should be removed here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

# Checks for greyboxes, and if they exist will add
# input and output vars to var_set if they are free
# inputs and outputs are defined names for greybox class and should always exist
for grey_box in _iter_indexed_block_data_objects(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to have a number_of_greybox_variables function to do this so that users can check that separately and so that we can test the code in isolation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added one for variables, and unfixed variables.

@@ -685,6 +689,42 @@ def test_degrees_of_freedom(m):
assert degrees_of_freedom(m.b2) == -1


@pytest.mark.unit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also have test for the functions to collect the number of greybox variables and constraints.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added tests

@Robbybp
Copy link
Member

Robbybp commented Oct 28, 2024

In most cases (at least I can't think of any exceptions) GreyBoxes must be 0DOF in the eyes of Pyomo/IPOPT as each output must be some sort of function of provided inputs, regardless if the internal model in the GreyBox is 0DOF, an optimization, or it exposes internal constraints to solve the problem.
As such, it should be safe to assume that the number of outputs equals the number of equality constraints.

IIRC, outputs just get translated to equality constraints of the form y = GB(x), but the greybox can define other equality constraints as well. So the number of equality constraints is at least the number of outputs, but can be greater.

@avdudchenko
Copy link
Contributor Author

@Robbybp : Right, so you can include equality constraints in a graybox and send them to the solver (ipopt) - but the variables in those constraints are not actually in pyomo space- and thus we can't count them (hence why here I am only looking at inputs and outputs and ignoring any internal equality constraints). (e.g. looking at this example)

At this point, we just want to look at the graybox as a constraint that binds exposed pyomo inputs to outputs on it, and assume that the users properly setup the internal graybox model to have the correct DOFS... ideally we would have some metadata on the graybox that tells us its internal # of DOFs so we can include it in the total count. But I opt to avoid that for now... unless we want to add support for this now.

Comment on lines 401 to 406
equalities = 0
for grey_box in _iter_indexed_block_data_objects(
block, ctype=ExternalGreyBoxBlock, active=True, descend_into=True
):
equalities += len(grey_box.outputs)
return equalities
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As written, this will be incorrect for grey box models that have a nonzero number of "explicitly defined equality constraints" (as opposed to the equality constraints that are created to define the outputs). I think all that's needed to correct this is:

equalities += grey_box.get_external_model().n_equality_constraints()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, did not think about this scenario! Updated to test graybox with suggestion, this now includes an example constraint that binds 2 inputs together.

        def input_names(self):
            return ["a1", "a2", "a3"]

        def output_names(self):
            return ["o1", "o2"]

        def equality_constraint_names(self):
            return ["a12"]

        def evaluate_equality_constraints(self):
            a1 = self._input_values[0]
            a2 = self._input_values[1]
            return [a1 * 0.5 - a2]

@avdudchenko
Copy link
Contributor Author

Thanks for this, it is a case we have not considered and Greybox models are becoming more important. To start with, I had a few suggestions for more tests and modularization of the code.

However, a more significant request would be to add these tools and (and some test cases) into the diagnostics toolbox as well. We should at a minimum check that the DoF and model statistics output (number of variables and constraints) accurately reflect the model with a Greybox present. It might also be nice to add additional sub-rows in the model statistics for greybox components when they are present. Finally, we should look for any edge cases that might occur with the rest of the toolbox and if there are other things we need to consider when using greybox models.

So I started adding display to diagnostics tools

  • the key question is should we include gray box stats with all others (e.g when counting blocks - should gray blocks count to total block count?, same with variables etc?, or should they be separate category only?)

Comment on lines 1070 to 1075
for in_var in grey_box.inputs:
if not grey_box.inputs[in_var].fixed:
var_set.add(grey_box.inputs[in_var])
for out_var in grey_box.outputs:
if not grey_box.outputs[out_var].fixed:
var_set.add(grey_box.outputs[out_var])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here, I think you need to make sure that these variables don't already appear in var_set. If the ExternalGreyBoxBlock is constructed with the inputs or outputs argument, then the block will contain references to the user-provided variables, which may have already been counted.

@lbianchi-lbl lbianchi-lbl added the Priority:High High Priority Issue or PR label Oct 31, 2024
@lbianchi-lbl
Copy link
Contributor

This is just waiting for @avdudchenko to extend the reporting functionality for diagnostics. This should be in the November release.

@avdudchenko
Copy link
Contributor Author

avdudchenko commented Nov 1, 2024

Ready for another round of reviews, I updated model statistics and diagnostics to try and treat greybox models as part of full model,
so variables and equities from greyboxes will be added with other stats as well, in addition to providing additional grey box model outputs via the diagnostic toolbox, which will show this:

    Activated Blocks: 1 (Deactivated: 0)
    Free Variables in Activated Constraints: 4 (External: 0)
        Free Variables with only lower bounds: 0
        Free Variables with only upper bounds: 0
        Free Variables with upper and lower bounds: 0
    Fixed Variables in Activated Constraints: 3 (External: 0)
    Activated Equality Constraints: 5 (Deactivated: 3)
    Activated Inequality Constraints: 0 (Deactivated: 0)
    Activated Objectives: 0 (Deactivated: 0)
    GreyBox Statistics
        Activated GreyBox models: 1 (Deactivated: 1)
        Activated GreyBox Equalities: 3 (Deactivated: 3)
        Free Variables in Activated GreyBox Equalities: 4 (Fixed: 1)

@Robbybp
Copy link
Member

Robbybp commented Nov 1, 2024

I'm curious what happens in the structural analysis when you have a greybox model. I can't imagine the under/overconstrained subsystems are handled correctly. Do you know what happens in this case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:High High Priority Issue or PR WaterTAP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants