Separator degrees of freedom

[juanbaquero4]

Hi y'll,

Hope you can help me with this issue. I am trying to run a water injection process in order to solve a MILP optimization to improve energy efficiency.

I am trying to add a separator unit to split the water stream in two directions, however, after coding the parameters, the number of degrees of freedom is 4, and after adding the arcs is - 5, and don't understand how to overcome this issue. Also , is neccesary to define the split_fraction and I am having an issue with this. There is the code:

m.fs.S25 = Separator (default={"property_package": m.fs.properties,
                                "outlet_list": [m.fs.Inj_4 , m.fs.PV_25], 
                                "num_outlets": 2 })

Where:

from idaes.generic_models.unit_models.product import Product
m.fs.Inj_4 = Product (default={"property_package": m.fs.properties})
f_pad = 100
m.fs.Inj_4.inlet.flow_mol[0].fix(f_pad) 

and:

m.fs.PV_25 = Valve (default={"property_package": m.fs.properties})
fin = 202 # mol/s # 🤷‍♂️ how to fis this value as the difference from the product to Water_PAD from the total transfered from the pumps or from the CV of the valve
pin = 1895058 # Pa # 🤷‍♂️ how to fix this with a pressure from from pumps 24 (arcs?)
pout = 1007058 # Pa # 🤷‍♂️ how to set this from the CV of the valve 
tin = 340 # K
hin = iapws95.htpx(T=tin*units.K, P=pin*units.Pa) # J/mol
#* Calculate the flow coefficient to give 1000 mol/s flow with given P
cv = fin/numpy.sqrt(pin - pout)/0.5
#* set inlet
m.fs.PV_25.inlet.enth_mol[0].fix(hin)
m.fs.PV_25.inlet.flow_mol[0].fix(fin)
m.fs.PV_25.inlet.flow_mol[0].unfix()
m.fs.PV_25.inlet.pressure[0].fix(pin)
m.fs.PV_25.outlet.pressure[0].fix(pout)
m.fs.PV_25.Cv.fix(cv)
m.fs.PV_25.valve_opening.fix(0.3)

and:

m.fs.pa = Arc(source=m.fs.pump_24_A.outlet, destination=m.fs.S25.inlet)
m.fs.pb = Arc(source=m.fs.pump_24_B.outlet, destination=m.fs.S25.inlet)
m.fs.pc= Arc(source=m.fs.pump_24_C.outlet, destination=m.fs.S25.inlet)

[andrewlee94]

Hi @juanbaquero4, I can see a number of problems to start with. Before I being however, I will note that you appear to be using IDAES v1.13 - as of February we will be releasing IDAES v2.0 and the v1 series will no longer be supported. We strongly encourage you to make the transition as soon as possible.

1. Firstly, when you are creating the arcs, you have three different outlets (from pumps) going to the inlet of a single separator. You can only have a single Arc connected to each Port, otherwise the problem will be over-specified. From what I can see, I think you need to have a Mixer in there to combine the streams from all the pumps first.
2. Next, you have a number of issues when you define the separator. Firstly, you only need to define one of num_outlets and outlet_list - num_outlets creates the specified number of outlets with default names, whilst outlet_list lets you provide a list of custom names. In the case where you provide both, we make sure they are consistent, and then just use outlet_list. More importantly however, outlet_list should be a list of names for the outlets, not a list of things you want to connect to - you need to create the Arcs later to do the connections. In this case, I think that the names will be converted to strings and used as the names for the outlets, but there could be unexpected behaviour from this.
3. For the degrees of freedom, I would need to see the full flowsheet, but one thing you did not show in your code above was fixing the split fraction for the Separator. You need something like m.fs.S25.split_frac['to_PV_25'].fix(0.5) - i.e. specifying that 50% of the flow goes to the outlet named 'to_PV_25'.
4. Next, I think you are a bit confused about how to define the flowsheet connectivity. From the definition of the separator, you are saying that one stream enters and then gets split between the value (PV25) and some unit Inj_4. However, the next thing you do is to fix the inlet states of PV25 - normally you would fix the inlet to the separator (or whatever is further upstream) and then solve for the inlet state of the valve. That is not to say you can't do this (equation oriented modeling lets you do things like this), but you need to know what you are doing and this doesn't match the general description of the process you gave.

[andrewlee94]

@juanbaquero4 The first problem is see with your example notebook is that the solver reported an infeasible solution - thee is no point at looking at any results beyond that point as the solver has told you it has not converged. This means that it is possible for there to be mismatches in the results.

you will need to dig into your model and work out why it is reporting an infeasible solutions. The first thing to do with an infeasible solution is to check for any bound violations in the model - this is the most common cause of infeasible solutions. You should go though the full model and look for variables that are approaching bounds and work out why, and then either revise the operating conditions to avoid the violation or relax the bound. However, you should always ask yourself why the bound was there before relaxing it - in property packages for example bounds often indicate the range over which the model correlations were fitted and thus represent the "trust region" of the model - relaxing those bounds mean you are now extrapolating with all the risks associated with that.

The second thing you should do is run the final solve with tee=True and inspect the output from IPOPT. There is a lot of information in there that can be useful for suggesting what might be causing the solver to fail.

[juanbaquero4]

Hi @andrewlee94 thank you! I made some changes in the model however the mistake persists in t=1. I changed the values for initial conditions and cheking the report, the initial conditions corresponds correct values. Thus, I am thinking the error from the calculation in t=1 comes from unit.model pump calculations, so I coded the constratint to calculate discharge pressure and efficiency (used in previous models), however, this error pops out:

InitializationError: fs.P_4 failed to initialize successfully. Please check the output logs for more information.
-> m, solver = create_model(time_set=[0, 5], nfe=10, tee=False)
-> m.fs.P_4.initialize()
->flags = blk.initialize_build(*args, **kwargs)
->super().initialize_build(state_args=state_args, outlvl=outlvl, solver=solver, optarg=optarg

The constraints were built as follows:

    @m.fs.P_4.Constraint(m.fs.time)
    def Pdesc_calculation(P_4, t):
        return (
            (P_4.outlet.pressure[t]) == (
            (-3874*P_4.control_volume.properties_out[t].flow_mol**2)+
            (-37153*P_4.control_volume.properties_out[t].flow_mol)+
            (2860479))
        )
    
    @m.fs.P_4.Constraint(m.fs.time)
    def eff_calculation(P_4, t):
        return (
            (P_4.efficiency_pump[t]) == (
            (-0.0068*P_4.control_volume.properties_out[t].flow_mol**2)+
            (0.1483*P_4.control_volume.properties_out[t].flow_mol)+
            (0.00252))
        )
    

I tried to built a function to recall the constraints as it is made from valve, however as it is documented for unit.model Pressure Changer, the isentropic.performance.curve is allowed to turbine not to pumps.

here is the code: https://github.com/juanbaquero4/pump-example.git

As always, I inmensily appreciate your help.

[andrewlee94]

@juanbaquero4 Before you rush off to change the model, you need to look at why the initialization failed; there are many different reasons the model might have failed to solve and each have a different fix. You should start by looking at the final solver status, as well as the number of variables and constraints in the problem and then look over the solver output logs to see what they are telling you.

[juanbaquero4]

@andrewlee94 As you suggested I took a review of all the variables in the model, I tried to change the ways to calculate to variables for the unit pump and I noticed the following:

• In t= 0 with nef=1 , the solver found a optimal solution and the variables were correct in all the units

• int = 1with nef =1, the solver finished due the # of iterations, I checked the results and the pump.outlet.pressure displayed in the graph does not correspond to the value that should be calculated from function (Pdesc). Instead to rise it declines, even with the recycle PV_4 close. (t=1 the value of flow is 11 so the pressure should rise)

• ¿how is possible to check the values as report, I've tried with the fucntion m.fs.report (1), but displayed the same result for m.fs.report(0), also I tried to print the values for instance in this case the flow value(m.fs.P_4.control_volume.properties_out[t].flow_mol), but does not work.

• If nfe is changed to a value different to 1, the values of flow_pump and inlet_flow.pump inmediatly rises from a value of 10 to 5000, the same for pump.outlet.pressure do not understand the reason why those values are taken for the unit_pump.

I am really struglling trying to understand. I would really appreciate your help, I've been deeping on the model but I couldn't find a way to make it converge.

here is the code: https://github.com/juanbaquero4/pump-example.git

As always thank you!

[andrewlee94]

There is not much point in trying to inspect the model results if the final solve was not successful - any result you do get back will be representative of the failed state at best. It can be useful for debugging infeasible models, but not for cases of max iterations. What you need to be looking at is the solver logs and see why it is failing.

From a quick look at the logs for the final solve I see a few signs of your problem. First of all, I note that you have two degrees of freedom in the model (80 variables but only 78 constraints); this is almost definitely not what you want as it mans the model is under-defined (you can do optimization on dynamic models, but you need to get the deterministic model working first). In these cases, there often is no answer to your problem hence the maximum iterations. Secondly, I see a lot of steps with regularization (lg(rg), should be "-"), small alpha values (should be 1) and high line search values (ls, should be 1). This tends to suggest that the model does not have a well defined feasible point and that the partial derivatives in the area around the current iteration are very small - this would be the case for an under-defined problem.

You might want to start with a smaller flowsheet to start with - I would suggest starting with just the valve and controller with a defined inlet condition. Once you understand how to get a single unit model working properly, you can then start working backward.

One other thing that just came to mind, is that you might need to think about the behaviour of the INJ unit. You may need some sort of pressure-flow constraint here too as otherwise the flow in htis stream might be undefined.

[Robbybp]

Edited to put the code in blocks with fixed-width text, FYI.