ExtensibleReactor variable bounds

[Diogo]

Dear all,

I am trying to simulate a spray combustion case in Cantera, by making use of the ExtensibleReactor (specifically ExtensibleIdealGasReactor) feature. 

To do so, I am adding 3 further variables per reactor (namely liquid temperature, total liquid mass and radius of droplets) and the associated equations, and then solving the network with solve_steady(). I am, however, running into a problem with the variable bounds: they seem to be set from -1e-20 to 1.00 for all variables I add, and this is especially a problem for the temperature, which is obviously not in that range. As far as I can tell, the functions that calculates the bounds (Reactor::upperBound and Reactor::lowerBound in the C++ source) simply take the bounds appropriate for species for all the variables beyond the first three.

Interestingly, the example usage of the extensible reactor at https://cantera.org/3.2/examples/python/reactors/porous_media_burner.html also has temperature as an additional state variable (in this case, that of a solid phase), and yet appears to work if using advance_to_steady_state() (as the example uses) -- but not if I switch to using solve_steady(), then I get the same issues with variable bounds.

I have not managed to find any way of changing these bounds looking through the documentation nor even the source code. Could anyone advise me as to whether this is possible?

I could alternatively try to use advance_to_steady_state(), though that was significantly slower for the test cases I ran before making use of the extensible reactor, or perhaps instead use some non dimensional equivalent of temperature (like T/T_max) as a state variable, but that would make the code harder to understand and modify, which is not ideal.

Thank you!

[Ray Speth]

Hi Diogo,

Thanks for reporting this problem. You’ve found a missing feature of the ExtensibleReactor class, which currently does not support adding delegates for the upperBound and lowerBound methods. I’ve opened an issue in our tracker (https://github.com/Cantera/cantera/issues/2156) for this.

I think the scaling approach you suggest is probably the best workaround for the time being, though I agree it’s not ideal.

Regards,
Ray

​