FlowDevice Python APIs incomplete vs. C++ APIs

[CharlelieLrt]

I am implementing a custom reactor network using Cantera's Python interface. This network comprises a FlowDevice (MassFlowController or Valve). For example:

import cantera as ct

gas = ct.Solution('gri30.yaml')
r1 = ct.Reactor(gas)
r2 = ct.Reactor(gas)
F = ct.MassFlowController(r1, r2)
net = ct.ReactorNet([r1, r2])

My custom implementation requires to be able to access methods/attributes of the upstream and downstream reactors, from the FlowDevice F. For example, something that would look like this:

Y_in = F.upstream.thermo.Y
Y_out = F.downstream.thermo.Y

Many of these APIs seem to be implemented in the C++ interface. For example, in the FlowDevice.cpp, I can see:

double FlowDevice::outletSpeciesMassFlowRate(size_t k)
{
    if (k >= m_nspout) {
        return 0.0;
    }   
    size_t ki = m_out2in[k];
    if (ki == npos) {
        return 0.0;
    }   
    return m_mdot * m_in->massFraction(ki);
}

double FlowDevice::enthalpy_mass()
{
    return m_in->enthalpy_mass();
}

where m_in is the reactor upstream to the FlowDevice. These APIs seem to be missing from the Python interface. In particular, I cannot find any enthalphy_mass or outletSpeciesMassFlowRate for the Python FlowDevice. Is there any way to achieve similar behavior using only the Python interface?

More generally, is there any alternative to access the neighbors of a given reactor in a ReactorNet, at the level of the reactor itself. For example something like:

r1_bis = r2.neighbors[0] # Returns r1

[speth]

Is this for use with the ExtensibleReactor model? This question was recently raised on the Users' Group (see this post), and the workaround I suggested was to add some member variables and methods to the ExtensibleReactor-derived class and store references to the upstream reactors as you're connecting the components of the reactor network.

I think this will mostly be resolved as a side effect of #1624, which adds upstream and downstream properties to Python FlowDevice objects.

[CharlelieLrt]

Yes, it is for an ExtensibleReactor for which the eval method is overwritten by a replace_eval. Thank you for your suggestion, I think that is essentially what is done in the Porous media Burner example.

And yes, I believe #1624 will resolve this.