Most teams that automate Aspen Plus arrive at the same place: a Python script built on pywin32, or a VBA macro, talking to the simulator through its COM automation interface. The approach is real and it works. The variable tree gives you a path to almost everything, and a few hundred lines of code can sweep a parameter, run the solver, and write results to a spreadsheet.
Reflux drives Aspen Plus through that same COM interface. So the honest comparison is not about access to the simulator, which is identical, but about what sits on top of that access and what happens when something goes wrong.
The script path, and why it is popular
A COM script is direct. You find node paths in the variable explorer, hardcode them, set values, call the run method, and read results out of the tree. For a task you run the same way every time, this is hard to beat: no new tooling, no approval process, and full control over exactly what happens.
Where homegrown scripts wear down
The failure modes are consistent enough that most teams can name them from experience.
- Brittle node paths. Scripts bake tree paths in as strings. Rename a block or move to a colleague's variant of the model, and the script either throws or, worse, quietly reads a node that still exists but no longer means what it did.
- No read-back verification. Most scripts set a value and move on. If the write did not take, or landed in a different unit basis than intended, every downstream result is wrong and nothing flags it.
- Silent failures. A run that fails to converge often still leaves values in the results tree. A script that does not check solver status will report stale or unconverged numbers as answers.
- Single-author knowledge. The script encodes one engineer's understanding of the model and the interface. When that person changes teams, the automation usually stops evolving and eventually stops being trusted.
None of this is an argument against scripting. It is a description of the maintenance cost, which is invisible when the script is written and very visible eighteen months later.
What a copilot layer adds
Reflux takes a natural-language request and turns it into inspectable actions against the simulator: reading blocks, streams, and components, editing parameters and stream specifications, building topology, running the solver, and reading convergence status and results. The difference from a script is not the vocabulary of actions. It is the discipline wrapped around them.
- Inspection before mutation. Reflux reads the existing flowsheet first and ties each proposed change to the specific block, stream, and result a reviewer needs to see. No hardcoded paths assumed to still be valid.
- Verified writes. Every write is read back from the simulator and checked before Reflux reports it as applied. If the simulator did not accept the change, you find out immediately, not in the results.
- Gated runs. Runs are held until required inputs are complete, and results pass quality gates before Reflux reports success. An unconverged run is reported as unconverged.
- Convergence context. When a run fails, Reflux reads the run history and status the simulator reports and connects errors to the specific inputs and blocks involved, rather than leaving you an exit code.
- A shared surface. The same capability is available from Slack, Teams, a local control panel, the CLI, or an MCP client, so the automation belongs to the team rather than to whoever owns the script file.
Real changes still sit behind explicit review. The point is not to remove the engineer from the loop; it is to hand the engineer something worth reviewing.
When a plain script is still the right call
If you have a fixed nightly batch job, one flowsheet, one known case, the same node paths every time, a script is the simpler tool. It is deterministic, trivially schedulable, and has no dependencies beyond Python and the simulator. Add a solver-status check and a read-back after each write, and it will serve you for years.
The copilot earns its place where the work varies: exploratory changes, troubleshooting someone else's model, questions phrased in engineering terms rather than node paths, and any workflow where a second person needs to see what changed and why. That is most day-to-day simulation work, which is why scripts tend to accumulate around the edges of it rather than cover it.
Aspen Plus today, built to extend
Reflux supports Aspen Plus today, through the same COM automation interface Python and VBA scripts use, behind an adapter architecture designed to extend to other process simulators. If your team already has a folder of automation scripts, treat them as evidence of demand. The copilot covers the variable work those scripts were never going to grow into.
Request a demo to see Reflux work through one of your flowsheets, including the write receipts and run gates described above.