Hello everyone,
First of all — thank you for maintaining this developer community. I've been reading quietly for a while, and this is my first post. Please forgive me if I'm putting it in the wrong category; the moderators are welcome to move it.
I'm a graduate student at Tianjin University (China). My undergraduate major was artificial intelligence, and I now work on RF/microwave and advanced packaging. Over the past year and a half, in my spare time outside research, I built an open-source framework that automates RF simulation work end-to-end, with HFSS (via PyAEDT) as its primary solver and trust anchor:
https://github.com/geer1895/rfauto (GPL-3.0, single-maintainer so far)
It started from pure selfishness: every design iteration meant redrawing geometry, babysitting a solve for minutes to hours, and copying numbers out by hand. I wanted that loop to be code. A year later it has grown into a working tool, and since the recent AgentEngineer / Autopilot announcement from Synopsys (with Ansys now part of Synopsys, and simulation & analysis workflows — including an EMC agent for PCB EMI/EMC analysis — in the portfolio), I finally worked up the courage to share it here and ask for guidance.
What the framework does
The core chain is: device template → closed-form synthesis for starting dimensions → parametric modeling → solve → quality gates → optimization → report.
- HFSS as the reference. Full-wave solving and arbitration run on HFSS through PyAEDT. The same geometry can be re-solved on a second engine (openEMS and other open-source solvers are wired in behind a common adapter layer — 16 engines in total, commercial ones strictly opt-in) and the results are cross-checked. Where engines disagree, HFSS is the anchor.
- Quality gates on every result. Energy and passivity checks, grid-artifact diagnostics, per-template acceptance values, physics-invariant tests. A result that fails a gate is reported as failed — never silently passed. Every number carries its provenance.
- Optimization loops. TPE, CMA-ES, multi-objective NSGA-II, plus a surrogate-model path so you search a fitted model instead of re-solving. Batch campaigns run unattended with budget admission, quotas and watchdogs.
- The rule I care about most: AI drives but doesn't invent. The framework exposes a CLI (254 commands) and a full MCP server (149 tools), so Claude Desktop, Cursor, or your own agent can operate it. But agents only schedule, plan and explain — every frequency, loss and dimension comes from a deterministic solver or a closed-form engine. Anything an agent wants to change goes through a sandbox draft and validation gates before it touches the workspace. I settled on this rule early, and everything since has reinforced it.
- Scale, honestly: 21,900+ automated tests (CI badge), 71 parameterized device template families (couplers, power dividers, filters, antennas, transitions…), and a built-in fake solver so the whole framework can be tried with zero licenses. It has driven several hundred real HFSS solves in my own research so far, and my development log holds 400+ numbered pitfall entries — most of them learned the hard way, outside the documentation.
Field notes from a year of "extreme" automation
A few things I kept bumping into, offered humbly as one student's field notes — they may be of interest to anyone working on scripting or agent-driven workflows:
- Session robustness is the real long-horizon problem. One failed API call — for example, a wave port with an invalid integration-line layout — can leave the whole session in a state where
GetBoundaries() / GetVariables() return None; every later call fails, cleanup code dies before release_desktop(), and the orphaned ansysedt.exe quietly holds license seats until killed by hand. I recently filed a reproducible report (minimal repro included) on the PyAEDT GitHub. For unattended, agent-driven runs, this failure class was the single biggest practical obstacle.
- The documentation thins out exactly where automation gets serious. Long-run session management, failure recovery, multi-engine cross-validation — these are barely covered anywhere, and I had to learn them from crashes. If a "pythonic automation beyond tutorials" corner ever exists in the docs, users like me would treasure it.
- Error messages that carry the root cause are load-bearing. When a generic exception hides "the actual cause only shows in the log", a human debugs it in an afternoon; an agent simply fails. As more of the workflow becomes agentic, discoverability and root-cause transparency feel like features, not polish.
- A usability note, offered respectfully. Having used COMSOL for some coursework, I found several everyday operations smoother there — parameter-sweep setup, geometry repair, tracing an error to its cause. HFSS solvers are the authority in our field; that is exactly why everything in my framework is anchored to HFSS. But for scripting-heavy users, the small frictions add up.
What I'm asking for
- Guidance. As far as I can find, there is no comparable open-source project orchestrating the full HFSS design chain with agents under a "numbers only from solvers" rule — which means I have nobody more experienced to ask whether the architecture has blind spots I can't see. If any developer or experienced user here would spare a look and point out where I'm being naive, it would help this project enormously.
- The right feedback channel. Beyond GitHub issues (good for clear-cut bugs), is there a recommended route for enhancement-type feedback from academic users — usability observations, and thoughts on how LLM agents and the Ansys toolchain should integrate?
- And if the framework is useful — as a real-world sample of PyAEDT pushed to its limits, as a testbed for agent-driven simulation ideas, or simply as a student project wanting to become a community project rather than a solo archive — it is open, and I would be glad to collaborate.
Thanks for reading this long post, and thanks to everyone here whose past answers carried me through this year.
— a student from Tianjin University
