Decouple Costing in LSRRO Flowsheet

[MarcusHolly]

Summary/Motivation:

In #1768 , Python 3.11 linux tests were failing when making these changes. The goal of this PR is to isolate the problematic code so that the aforementioned PR can be merged without issue. This PR will be addressed at a later time

Changes proposed in this PR:

• Decouples costing from the build function for the LSRRO flowsheet

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.

[adam-a-a]

@bknueven any thoughts on why our old test file on lsrro paper analysis would indicate that for python 3.11/Linux, LSRRO solves successfully during an expected failure to converge (NaN)?

[bknueven]

@bknueven any thoughts on why our old test file on lsrro paper analysis would indicate that for python 3.11/Linux, LSRRO solves successfully during an expected failure to converge (NaN)?

Not really. It looks like this re-orders the way costing is added, which will result in a different order in the NL file, which will result in a different order in the Jacobian matrix, which will subtly change the individual back-solves Ipopt does. Not sure why that's only happening on Python 3.11 and Linux, however. Probably this case was always on the edge, so whatever differences in the numerical libraries exist might be just enough to get it to converge instead of failing.

If it's easy to run this case locally, you might find that it "fails" after meeting a constraint tolerance of 1.01e-8 or something similar.