Open philipp1337 opened 3 years ago
Hi! Thank you for reporting this. Although the errors and failures here are suboptimal, they aren't totally unexpected. The *ConstPressureReactor
classes adjust the volume of the reactor to keep the pressure constant. On the other hand, the *Reactor
classes are constant volume, so the outlet mass flow rate adjusts to keep the pressure constant. In general, you want to use the latter class when you are modelling flow through a device. The most robust setup that I've found is: Reservoir
->MassFlowController
->Reactor
->PressureController
->Reservoir
, with the master
attribute of the PressureController
set to the MassFlowController
instance. You can use an IdealGasReactor
instead of Reactor
if the ideal gas model is appropriate. Hope that helps!
Should we consider using a constant-pressure reactor with both inlets and outlets an error? I'm trying to think of a case where a user would want the behavior where the reactor volume is varying wildly, as opposed to the behavior from the setup using a PressureController
.
I'm not in favor of an error, or at least, not in favor of an error that can't be disabled by users. Just because we can't think of a case where this would be useful doesn't mean there aren't any. It does seem like this comes up quite frequently though, so we should have some better user interface here.
My 2 cents are that a ConstPressureReactor
in combination with a PressureController
combines two approaches where each has a mechanism to hold the pressure constant (the former adjusts volume, the latter adjusts mass flow rates). Using both at the same time is asking for trouble (not just numerically, where negative mass flow rates are indeed problematic; I also cannot think of an experimental setup where this would work). For the constant pressure reactor scenario, you'd have to imagine a cylinder with a frictionless piston and two ports: the inlet has a mass flow controller and the outlet has a pressure controller. This is imho an ill defined problem, and in practice you'll have two controllers 'fighting' with each other. So myself, I'd be in favor of not allowing for the configuration that led to this issue report.
I also cannot think of an experimental setup where this would work
What I'm saying is that it doesn't matter if there's an experimental setup where this would work. IMO what matters is that there is an experimental setup or a thought experiment where a ConstPressureReactor
and a PressureController
would be an appropriate model, which doesn't necessarily correspond to any physical components. In that case, IMO, users should have an escape hatch to say, no I really know what I'm doing and I'm willing to deal with the consequences (e.g., numerical instability).
ETA: That said, clearly the number of messages we get about this specific problem here and on the Users' Group warrants some sort of response. I just want to temper it down from a "thou shalt not do this!" response 😄
I want to simulate burning methane in an IdealGasConstPressureReactor. I use different mass-flows and equivalence-ratios using two vectors you can see in my example code below. However, using ReactorNet.advance_to_steady_state breaks the solver at certain points, leading to huge reactor masses and volumes and therefore CanteraErrors. If I varying the equivalence-ratio leads to different combustors failing, varying the mass-flows to each reactor has no effect on this. Using a ConstPressureReactor also leads to the same results, using an IdealGasReactor eliminates the error while the pressure before and after the reactor stays about the same (0.1% differences).
Steps to reproduce
My example code:
Behavior
System information