how to "reset" the network without using "network._reset_topology_reduction_specifications()" method?

[guidoffrate]

Hi,

I am following this example How to Generate Stable Starting Values to generate stable starting points and make the heat pump calculation converge.

I was successful, so perfect!

However, I was wondering why, after a failed calculation, we have to run the method nw._reset_topology_reduction_specifications() (where nw is the network from the example). Secondly, is there another way to perform this reset since the method above is not intended to be used outside the object (it is protected)?

Thank you!

[fwitte]

Hi @guidoffrate ,

thank you for reaching out, and good, that the example is working well for you :).

However, I was wondering why, after a failed calculation, we have to run the method nw._reset_topology_reduction_specifications() (where nw is the network from the example). Secondly, is there another way to perform this reset since the method above is not intended to be used outside the object (it is protected)?

The reason for this is, that the solve method has side effects on Connection objects, specifically in the preprocessing: A topology reduction is performed to make the size of the problem smaller. Among other things, a branch-system is created listing all branches of the topology, that have the identical mass flow. In that specific example there are 3 branches, therefore the number of mass flow variables is reduced to 3.

What then happens is, that all Connection objects of a single branch get their mass flow variable mapped to any one of the Connection objects' mass flows within that same branch. If the simulation then crashes with an error, the variables are not reverted back to their original state, because the function is not called. If you want to continue running the same script (as in the example, because that in the end is all in a single script), you have to reset that topology mapping. I made that function private (protected would be __reset_topology_reduction_specifications()) because I thought it should be out of scope for the standard user.

In general, if you want to run your model and you want to handle errors originating from CoolProp with the ValueError exception handling during the solve method, then you need that method. There is two options I can think of:

• either we incorporate the error handling inside the solve method and call the reset method from there,
• or we make that function public.

What do you think?

Best

Francesco

[guidoffrate]

Thank you for the quick reply!

As you show in the example on generating stable starting points, being able to reset the network is useful even for standard users. Handling the error directly within solve is the most elegant option (nobody sees anything; everything happens under the carpet) but requires the most effort. Therefore, making _reset_topology_reduction_specifications() public is just fine, IMHO.

Best,

Guido

[fwitte]

I'll do that in a future release. Thank you for the feedback, have a nice weekend!