You might be hitting the array registration issues. This is something that got fixed with Symbolics v3 but it’s currently going to be blocked until the bumping Symbolics / SymbolicUtils / TermInterface bump by ChrisRackauckas · Pull Request #2948 · SciML/ModelingToolkit.jl · GitHub is done. I’m hoping that piece is all completed by the end of the week, in which case @Vinicius_Viena is unblocked and the Clapeyron integrations should all be working.
1 Like
Hi!
Calling unregistered Clapyeron functions will likely fail as symbolics will trace down inner function calls.
Here’s a related thread about it, but using coolprop for single component systems: Media properties and component encapsulation in MTK - #7 by Sushrut_Deshpande.
A symbolic extension is being done in Clapyeron with symbolic registration of relevant functions. To make it functional though, the updates Chris mentioned are necessary.
Indeed I have faced the same issue when calling Clapeyron functions.
Any idea when ProcessSimulator will be open for public release? If my understanding is correct it has already connected Clapeyron functions with ModelingToolkit.
The ModelingToolkit updates just went through last week, so the team should be unblocked now 
1 Like
I just opened:
I will want to setup a call, next Tuesday? There’s a lot there (mostly in a PR branch right now), but there’s still a lot more to do, and it seems like there’s a good amount of folks that want to join. DM me if interested.
3 Likes
Latest version of the ProcessSimulator can be found in the second half of this video:
2 Likes
Just want to say, as a long time Clapeyron user, am very happy to see this! Looking forward to playing with it soon.
1 Like
Out of curiosity, what will be the capabilities for black-box modelling of unit operations? All I really want for Christmas is a tool that allows me to define individual unit operation functions (reactor, absorber, HX) as julia code, define how they link (this stream flows from here to there), and solves the whole system, either automatically tearing (sequential) or by automatically bringing everything together (equation oriented). It looks like this project is closer to the latter, but it doesn’t look like it could handle arbitrary Julia functions inside unit operation blocks? I understand there’s a tradeoff: with arbitrary julia functions, you’d lose most of the numerical magic possible with ModelingToolkit.jl …
Unless I misunderstand you, ModelingToolkit is already that tool? MTK might be rough around the edges, but on our side, we have some (basic) code working that does what you ask for using stream connectors. It works well, once you understand MTK’s idiosyncrasies and limitations. See Acausal Component-Based Modeling · ModelingToolkit.jl
From my understanding, ProcessSimulator.jl aims to be a library of prebuilt components. If you’re willing to write your own, the capabilities are already there.
it doesn’t look like it could handle arbitrary Julia functions inside unit operation blocks
You can’t have a complex equation with an arbitrary function and expect MTK to do fancy algebra to simplify / invert it. But for an equation like dx/dt = x ^ 2 + f(x), f can be an arbitrary function (even an interpolation between data — see the DataInterpolations usage in the linked tutorial) and DifferentialEquations.jl will just integrate over it.
1 Like
To clarify. Suppose I had a very simple system with three components, a mixer, a reactor, and a separator. I’d like to be able to write 3 functions:
function Mixer(mixerinputs)
#Do Arbitrary Julia Stuff Without Any Cares in the World
return mixeroutputs
end
function Reactor(reactorinputs)
#Do Arbitrary Julia Stuff Without Any Cares in the World
return reactoroutputs
end
function Separator(reactorinputs)
#Do Arbitrary Julia Stuff Without Any Cares in the World
return reactoroutputs
end
I’d then have a separate file that defines the stream geometry so, for instance, mixeroutputs might go to reactorinputs, some variables in separatoroutputs might recycle back to mixerinputs. The tool would then take all this structure and these arbitrary julia functions, and figure out how to solve them as a whole. This would probably require tearing and sequential solving, as if we’re allowed to do arbitrary things inside each function, I don’t think it would be possible to collate the various unit operations into one large set of equations.
My question is if such Black-box modelling is a capability or possible capability in this Julia Process Simulator suite? If not, that’s fine. The only way I could imagine it working in an equation-oriented approach is if you had automated generation of surrogates (e.g. piecewise linear surrogates, like OMLT allows for) which could then be fed into a larger equation-oriented structure.
The reason I ask is that this kind of iterative, write-your-own-unit-operation code, is relatively common among a certain class of chemical process design engineers, and at present there aren’t any nice tools for automating the tearing and linking things up with a GUI, let alone automatic surrogate generation from black box models with subsequent integration into an equation oriented framework. IDAES has been pushing this way slowly, but it’s still a work in progress.
1 Like
like OMLT allows for
Since you mentioned OMLT (I assume we’re talking about the same thing), I’ll drop a link to GitHub - lanl-ansi/MathOptAI.jl: Embed trained machine learning predictors in JuMP
Yeah it all works together. For example, there’s ModelingToolkitNeuralNetworks.jl which allows for blocks defined as neural networks and you can train those as well. Here’s an example of doing the universal differential equation workflow on an acausal block model:
ModelingToolkit then has a system for declaring tunability so you can set some parameters as fixed and others to learn.
This is done via the function registration system. You can make any function a node and register properties like inverses, discontinuities, etc. which are then specialized by the solvers. See for details:
DataInterpolations is pre-registered so it just works with the system. Other things like property models using a spline you make on your own, you will need to do the registration.
Yes exactly, and that’s what is unique here. It’s a fully acausal modeling system, but it’s built within its own host language, Julia. This means that every function it handles by default, like sqrt, is added to the modeling system in exactly the same way that you can. There’s no difference between built-ins and the things that you can do. ModelingToolkitStandardLibrary.jl builds the basic standard library and also serves as a tool to show you how to do it. And since the host language is a fully featured language, unlike something like Modelica or GPROMs, you can pull anything from it. You can register a function calls to JuMP to embed convex optimizers for convex model-predictive control, you can register neural network training into the ODE right hand side for all I care. You can create events which log information and visualizations as a way to create animations. You can use the entire imperative language just by registering it in or using functional affect callbacks.
Not entirely since these IIUC cannot do the training. So you can train effectively a lookup table and embed it, but you cannot do something like the UDEs through this approach. It’s a 50% solution but it does help in some of the process modeling cases, but not others.
2 Likes
This is exciting - I’ll definitely be looking into this once ProcessSimulator.jl is out! Thanks!
Actually, to follow up on this, is there anyone I could reach out to discuss access to ProcessSimulator.jl at this time? I’m pitching a multi-year academic project, and would like to explore its potential vs my default IDAES/OMLT setup. Integration with Clapeyron is a HUGE draw if everything else works. Would be happy to contribute in modest ways (e.g. adding worked examples to docs, etc.).
I’m always happy to chat (and collaborate on grants).