Control system/regulator for tank pressure

[Christian Svensson]

Hello and thanks for the great work on this software. I'm quite new to both programming and numerical solving, so I hope this question makes the slightest bit of sense.

I am currently implementing some functions for modeling the pressure change inside a fuel tank, which is currently only dependent on the fuel mass rate from the network and the current heat transfer rate (dependent on flight conditions). It does not return anything back to the network. It calculates the the pressures for the time steps in the segment according to "P = P[0] + np.dot(I, dPdt)", where "dPdt" is a function of the fuel flow vector and heat rate as mentioned.

Now I want to implement some kind of pressure control system, where if the calculated pressure inside the tank at a certain time step exceeds a "P_max", threshold an extra mass flow vector becomes non-zero to lower the pressure (it's venting boil-off gas from a cryo liquid basically). The pressure calculations are now returning an additional mass rate back to the network.

My concern is that if I feed the solver an unknown, mass flow gas, and a residual that is the "over-pressure" for the time steps in the vector that have p>p_max, then the solver might "see into the future" and correct the over-pressures in a way that is unrealistic. 

Has anyone done something similar in SUAVE or for this type of numerical scheme? For time-marching this would be quite easy but I'm a bit lost here, so any suggestions or solutions to similar problems would be very helpful.

In my head there would be some kind of way to make a residual which only acts on the first over-pressure, introduces a correction by making the mass flow gas in this time step non-zero, and iterates this mass flow so the pressure becomes exactly P=Pmax. After this it converges the subsequent time step's pressures, and looks for other over-pressures.

Thanks,

Christian

[Emilio]

Solvers tend to do crazy things like that.

If I understand correctly this is like charging a battery? You eventually hit capacity and stop? If so, take a look at this scenario when a solar panel is charging. Now this wouldn't work if the battery was cycled multiple times in one segment.

Let me know if that's the correct analogy here.

-Emilio

[Christian Svensson]

Hey, thanks for the answer.

Yes, this looks like how I was solving it before I realized it might not be the correct way to do it . Finding out a "overcharge" or "overpressure" and then differentiating over time for all segment points to get the dp/dt would be incorrect, because the first correction/gas venting might cause the subsequent time step's pressures to be well below p_max, and therefore not needing any corrections. 

I have implemented quite an ugly solution (like described in the original post), which entails scanning for and only correcting the first over-pressure, introducing a gas venting mass flow at this time step, and letting this propagate into the coming time steps. It works, but a big problem is needing more segment control points to prevent late corrections, which causes the pressure to oscillate. Dividing the segments more or changing the amount of control points on the fly (essentially restarting the current segment with more points) would help. Is the latter possible to do?

In any case I think this is a interesting problem to solve in SUAVE, so let's see if I succeed fully or not.

[Emilio]

Have you had any success with your approach?

Thinking out loud and back to the concern about seeing into the future, is there any problem with this? I think adding extra variables and residuals is the easiest way to solve it. If the solver decides to preemptively make an adjustment or adjust knowing the future will have some conditions changing, wouldn't an operator do something similar?

-Emilio

[Christian Svensson]

Hey Emilio,

Yes, my approach works, but is quite slow and cumbersome because the venting mass flow is solved through an inner fsolve inside my "tank.energy_calc()". Then the mass flow is fed back to the vehicle mass_rate in the network, so SUAVE's mission solver and my iterations are kinda fighting each other (mass flow is corrected by inner loop, but then maybe SUAVE wants to change e.g. throttle a little bit, which causes the pressure to change and then the pressure correction and so forth). I hope you understand what I'm trying to convey. But it's only one inner iteration per "SUAVE iteration", so given enough segment points it usually converges. In the pic below I have one example where the max. allowable pressure in the tank is capped at 2.5 bar and 1.5 bar respectively. I think it was 16 segment points for the last segment (the more points the smaller are the overshoots/oscillations, because it actually gets closer to correcting the pressure at the right time).

I have also tried creating an unknown and letting SUAVE play with the vent mass flow. Unfortunately it's quite unstable. I think it is because sometimes when the vehicle body forces are unconverged, which is usually solved by power coeff. and throttle, SUAVE tries to solve this force imbalance by reducing/increasing the vehicle mass via the ventilation mass flow. But this ends up being totally unrealistic mass flows (100s of kg/s or wrong sign), which then causes problems in my tank.energy_calc() where the pressure goes haywire and then causes RefProp (I use it to get the H2 properties as a function of pressure) to crash the whole program. I have solved this by creating a "filter" if-statement which only makes the vent mass flow vector non-zero if it is showing reasonable values. But this approach is not working atm, it looks like the SUAVE solver is not exploring the "realistic" unknown-space, so it never sees any good change to the residual/obj. function.

Regarding seeing into the future, if it would work and is safe on a real-life mission then ofc it's fine to do here. It's just me not knowing how it would be done IRL. I'll try to read in the literature.

[Christian Svensson]

Is it possible to make the unknown and residual exclusive to each other? So that it doesn't try to fix the force imbalance with the mass flow.

[Emilio]

This is very interesting.

About decoupling, the only good way to do that is with an inner solver. Which I believe we've basically discussed. Similar to how a propeller needs convergence prior to solving the mission at each iteration.

I think the proper way of solving this is to solve it as an optimization problem. The residuals become constraints. I think you'll need to step back and think about your objective and constraints carefully, to avoid the "look ahead" issue you've alluded to at the beginning. With an optimization problem, the number of residuals and the number of unknowns no longer have to be equal. However, it will take longer to solve and possibly be more unstable.

I can't think of an easy answer here. 

-Emilio

[Christian Svensson]

It is indeed quite an interesting problem to solve with SUAVE's numerics. I have a new method now, still an inner-loop method, but I have stopped solving for the mass flows with fsolve. It has proven too slow and requires a lot of control points to converge. Even then it is not very robust.

I wrote down the problem on paper and with some clever use of the integration and differentiation matrices in SUAVE I was able to isolate the pressure time gradient and then the unknown mass flow. This way the mass flow is a Chebyshev polynomial, which is neat. 

Here's a test where the aircraft is standing still on ground with fuel cell turned off. The max pressure is set to 1.3 bar, and it looks like the new method yields the same mean ventilation mass flow and fuel mass decrease (at 220 minutes). The method "sees the future" a little bit, but I think the pressure curves kinda look the same. So I will continue with this method. 

I also tried using the old method (the jaggedy venting mass rate) and then after calculating the mass flow using a filter like Savgol to smooth the solution out. It actually gets rid of most of the oscillations and does help the convergence, but solving the unknown mass flows with fsolve was still a bottle neck.

[Christian Svensson]

I forgot to mention that the new method still "looks" for the first over-pressure and corrects the pressure one at a time and then propagates the changes forward in time.