Component-based model for N reactors connected to a tank

Say I’ve got 10 chemical reactors, which all flow into a single tank. The reactors all have different production rates for some species S. I’m interested in the concentration of S in the reactors and in the tank. I guess I should have a Reactor component (then I can have an array of 10 reactors), and a Tank component. How should they be connected? What should be my through/across variables?

I’m a novice here (and not an engineer), but starting from the RC-circuit analogy, my thought is that concentration neither sums like I nor is it shared like V. Mass flow of S and mass flow of H2O do sum, so they feel alright for through variables, but then I guess I’d need two corresponding across variables…? In the modelica book, they use pressure, but there’s only one of those. Maybe I should use two MassFlow components for my two chemical species (S and water), then add an equation that their pressures are equal…? Does that even make sense?

I’m lost! :slight_smile: An example would be very appreciated.

From preliminary experiments on my side, it looks like A) one can have a flow-only connector and it works just fine, B) it can cause a (spurrious?) error message, C) it can be fixed by adding a dummy across variable.

From this, simply modeling mass-flow-of-H2O and mass-flow-of-S should work.

You have referred to some Modelica resource for inspiration, hence I will continue: in the language specification in the Chapter 15 on Stream connectors they write

The two basic variable types in a connector – potential (or across ) variable and flow (or through ) variable – are not sufficient to describe in a numerically sound way the bi-directional flow of matter with convective transport of specific quantities, such as specific enthalpy and chemical composition […] This is not possible with across and through variables though. This fundamental problem is addressed in Modelica by introducing a third type of connector variable, called stream variable […]

I guess in ModelingToolkit (assuming that’s the package that you are considering) pretty much the same fundamental limitation holds. Whether a solution is already implemented or not, I do not know, but apparently the coupling between components must be based on three variables and not just two.

ModelingToolkit also has @variables k(t) [connect = Stream], but the difficulties referred to in the cited modelica documentation might not come into play in this example? IIRC it only becomes relevant with flow that can change direction, which does not appear to be possible with the reactors and the tank described in the OP?

1 Like

Honestly, I do not know. Sorry if my comment led to confusion. I am not fluent in these fluid things beyond simple mechanics. I only remember that often two variables like volumetric flow and pressure (in analogy with current and voltage), whose product is power, are not enough if thermal content or mass fractions need to be considered in addition to the fluid doing some (mechanical) work, which triggered my comment. I see, here probably the mechanics of the problem is irrelevant.

I just talked with @Vinicius_Viena about the state choice for this kind of system for the development of:

Specifically, this change is going on in:

I think it could be interesting to gather a few folks into a call because it seems there is some parallel development efforts in this. DM me if interested.

That seems to be a similar problem for process pressure-driven simulation where flow direction are pressure drop equations are coupled. It might be fruitful to have discussion on it. Totally up for it.

I have been looking into some references (this is a good one) Pressure-driven dynamic process simulation using a new generic stream object - ScienceDirect. Also this one from modelica (https://doc.modelica.org/Modelica%204.0.0/Resources/Documentation/Fluid/Stream-Connectors-Overview-Rationale.pdf). Yet, it’s not clear for me how to implement such things in the context of chemical process simulation where hydraulics and other more complicated phenomena (reaction, phase change) are coupled.

We have a (unidirectional) flow loop of tank → N reactors → tank (with the reactors in parallel), and it really highlights some of the challenges. In the tank -> reactor flow direction, then the reactor inlets (aka ports) all share the same concentration (the concentration of the tank). However, in the reactor -> tank flow direction, the concentration of the reactor outlets have to be put in a weighted average to compute the tank inlet’s concentration.

But the connect pattern is identical in the two cases! Thus it would seem that we cannot use the same through/across connectors in the tank → reactor direction as we do in the reactor → tank direction. Unless I missed something again.

Thus, what should we do?

  • Use different connectors for the two scenarios.
  • Use stream connectors?
  • Connect the N reactors to N separate ports on the tank. Then we can implement the inflow / outflow logic there. I feel like I’ve seen an example of this in the documentation somewhere?
  • Use equations outside the components (i.e. “give up” on components)

Thoughts?

Yes, that is what the documentation suggests:

The two basic variable types in a connector – potential (or across ) variable and flow (or through ) variable – are not sufficient to describe in a numerically sound way the bi-directional flow of matter with convective transport of specific quantities, such as specific enthalpy and chemical composition.

but I haven’t figured out a way to do this otherwise.

I asked ChatGPT about doing it without stream connectors and it suggested the Connect the N reactors to N separate ports on the tank solution, so I would assume that it’s fairly standard.

Also this one from modelica (https://doc.modelica.org/Modelica%204.0.0/Resources/Documentation/Fluid/Stream-Connectors-Overview-Rationale.pdf ). Yet, it’s not clear for me how to implement such things in the context of chemical process simulation where hydraulics and other more complicated phenomena (reaction, phase change) are coupled.

Yes, I share that feeling. For unidirectional flow, the many-port solution gives complete flexibility about how to combine the quantities. It’s a shame that it’s uglier…