-
-
Notifications
You must be signed in to change notification settings - Fork 224
One way stream connections (no backflow) #3678
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Stream connectors effectively correspond to upwinding discretizations of advection dominated PDEs: https://en.wikipedia.org/wiki/Upwind_scheme In that sense, you numerically always need a backflow equation if you're going to integrate the system, since not switching equations would be numerically unstable. But yes, if you can guarantee that a certain direction is taken then the system can be greatly simplified: then we only need to generate for one direction. So I think this is possible and it would definitely need to have an assertion in there that the user's assumption is correct as otherwise bad things can happen. |
I'd like to understand...is your concern the need to specify the Part of my concern here is that in building such a system, you may want to reuse components that are built to handle flow in both directions. If you didn't do that, then you would potentially end up having to create two libraries, one that supports reversing flow and one that didn't...each with potentially the same components. But if you leave aside the need to specify an unused value for |
Broadly, it's that
A big part of the appeal for us is that MTK's equations are understandable by the chemical engineers working with me. A physical backflow would destroy our reactor. What kind of equations should I write to represent that? To my colleagues, this is just noise. I get the appeal of component libraries, but at the current POC stage this is not what we are aiming for.
Yes, ideally a user with a forward-flow model should be able to integrate bidirectional flow components from a library. The backflow equations would just be ignored. Not sure how to implement that in practice. By the way, thank you for Modelica By Example! I was pulling my hair reading the MTK docs until I found it. It should be prominently featured IMO, or translated to MTK. |
Uh oh!
There was an error while loading. Please reload this page.
A lot of chemical plants have the product flowing in only one direction. Modeling those with
stream
connectors is natural, but under MTK (and vanilla Modelica) it requires also specifying the backflow version of all stream quantities.To wit, here I have one source of product flowing into two reactors, in parallel:
Without the
inlet.conc ~ 9999
equation, MTK complains that it has more unknowns than equations. This is understandable, but it has been a major source of headache on our side since we've started using MTK. If a reactor operates in the forward direction, are we expected to always specify a hypothetical backflow case? Consider this simple equation (in the forward direction):Complicating it with a physically-impossible backflow is quite depressing, not to mention error-prone. The user-side alternatives are:
inlet.conc ~ -999999
inlet.conc ~ 0
inlet.conc ~ outlet.conc
I use the first one. I sprinkle
inlet.conc ~ -999999
in my components when MTK complains of a lack of equations, and I delete them when there is a surplus of equations. It usually works 😱Proposal
connect(a.inlet, b.inlet, backflow=false)
. Thenexpand_connection
could ignore the backflow equations, and ideally add anassertion
that the flow is in the right direction.Related
According to https://stackoverflow.com/questions/78580149/how-to-turn-off-the-possibility-of-media-back-flow-when-using-the-modelica-strea
I am quite interested to hear about how others are approaching this. Perhaps there is a simpler solution that I missed?
The text was updated successfully, but these errors were encountered: