I am a user of JuMP and am aware that the Institute for the Design of Advanced Energy Systems (IDAES) is a recently developed tool built on Python that utilizes the Pyomo optimization modeling language (https://doi.org/10.1002/amp2.10095) for process simulation and optimization. I find IDAES leverages the block-oriented modeling capability of pyomo. I want to know the possibility of building a similar software based on JuMP. Note that this is a vast and intricate engineering project, and I am particularly interested in understanding the possible challenges and advantages of using JuMP. Such as performance and complexity issues.

This is a fairly broad topic. @pulsipher might have some insight.

Some high level thoughts:

- yes, you could build something similar in JuMP
- with care, performance could be similar or better

The main consideration is that JuMP doesnt have Pyomos block structure, so you shouldnâ€™t look to replicate the design of the code. Youâ€™d need to rethink how to build it in a â€śJulianâ€ť fashion.

Some projects to look at

- InfiniteOpt.jl
- PowerSimulations.jl

See also

We have an ongoing project in the Julia Lab (+ collaborations elsewhere) to build a chemical process simulation library in Julia. I am hoping it will be revealed at a football stadium this summer , but weâ€™ll see about that.

Itâ€™s being developed using ModelingToolkit instead for a variety of reasons.

- Normally the best way to solve a DAE is not to solve the equations that the user has specified. Thatâ€™s a long and deep topic with lots of little algorithms that all add up, and itâ€™s the bread and butter of what ModelingToolkit does.
- ModelingToolkit supports acausal component-based modeling, which is a generalization of the â€śblock-oriented modelingâ€ť and allows for a lot of symbolic simplification. The reasons and design is similar in spirit to something like Modelica, and so this work of a chemical process simulator on OpenModelica is a good background as to why this would be used in comparison to say Aspen+ (https://pubs.acs.org/doi/epdf/10.1021/acs.iecr.9b00104).
- The best way to do the forward simulation of such equations is generally not to treat it as an optimization problem, rather to simulate the DAEs or directly solve the nonlinear system, depending on whether itâ€™s a dynamic or steady state problem. So youâ€™d generally want to make use of DifferentialEquations.jl or NonlinearSolve.jl in most cases (or BoundaryValueDiffEq.jl).
- A fully implicit discretization in time does not have error control over the truncation error, which in term means that the solution has a non-trivial error with respect to the chosen
`dt`

that is not estimated or shared with the user. - For inverse problems where you are doing an optimization, itâ€™s problem-dependent whether doing the discretization in time as part of the optimization is good or bad. There are examples that go both ways, and so having the flexibility to choose to treat it via DAE solvers or fully implicit can help (or the mixture, i.e. as a multi-point BVP).
- Importantly, ModelingToolkit comes with a standard library of other components so then you can mix and match the chemical process simulation with other aspects, like a hydraulic system or a power simulation. The core of an acausal modeling system is to help bring different models together.

There are still some downsides, which are being worked out as part of the project. For one thing, we need simpler connections to multi-point BVPs, so while BoundaryValueDiffEq.jl just got a revamp over the last year, ModelingToolkit doesnâ€™t target it effectively. Also, if nonlinear constraints are added then it does need to fall back to a form of feasibility problem that uses optimization, and the codegen to optimizers is currently not as optimized as JuMP (though thereâ€™s ongoing work on Optimization.jl and targeting of JuMP code directly from MTKâ€™s symbolic form).

So, do you mean the software IDAES (bulid up on python and pyomo) is not a good choice for chemical process simulation and optimization, using Modelica is better?

I think thereâ€™s good reasons to take an acausal modeling approach to the development of the system. The OpenModelica results, while not ending up in an actively maintained repository, do show some of the benefits of doing so. And gPROMs is effectively an acausal modeling system as well and I think is a nice and clear demonstration of how acausal modeling can help chemical process simulation be more robust.

Of course, there are trade-offs. The main trade-off being that an acausal modeling system can be wildly more complicated to engineer: simply using the equations given to you by the user is the most straightforward thing to do. Also, it can take a lot of design to get the connection to causal systems right, which is required for building control systems. The other is that the optimization-based approach more naturally lends itself to feasibility solves that can enforce nonlinear constraints. While itâ€™s feasible in a dynamical approach (differential inclusions), itâ€™s definitely not straightforward, and thus any handling of these cases would need to fall back to optimization tooling in some form (or multi-point BVP). But you can still apply the equation transformations to an extent so it can still be useful to mix these techniques with an optimization approach.

Thank you for your enthusiastic reply. Iâ€™ll continue to explore various advanced modeling frameworks. It seems that IDAES is also based on an acausal modeling approach (perhaps I misunderstood your statement; I consider the equation-oriented modeling method as the acausal modeling approach).

Having closely worked with the IDAES team, the main benefit of developing the process simulation framework in an AML environment like Pyomo is being able to conduct advanced analysis and design techniques (e.g., robust optimization, flexibility analysis, stochastic optimization, etc.) which require constrained programming. For these types of problems, the team and myself found that shooting methods (i.e., forward simulating the DAEs) didnâ€™t perform well against simultaneous methods (e.g., discretize then optimize).

Depending on your goals, it would be possible in principle to make something analogous to IDAES in Julia. Perhaps using the SciML framework if simulation and unconstrained optimization is your primary motivation, or using JuMP if you have similar objectives to the IDAES team. However, it would be an enormous undertaking. It has taken 40+ IDAES team members 6+ years to get it to where it is now. As a ChemE researcher and a Julia fanboy, I would love something like this to exist but it seems like too large an undertaking, especially considering that the IDAES framework already exists.

I will also note that one fundamental challenge the IDAES team has is that good open-source thermodynamic property data is few and far between. This definitely gives commercial tools like Aspen a big advantage.

Thanks, sincerely.