AmesimKnowledge

Community Knowledge > Headless Automation (AMEOpen)

Three AMEOpen limitations on Amesim 2511, each exercised

All three were found on 2026-09-03 on Simcenter Amesim 2511 while building the AMEOpen tools in amesim-mcp. Two are honest reds, one is a green that was worth proving because it sits next to a red. Each is marked with the models it was tried on. Re-test all three on 2604, the release the Siemens bundle targets.

1. Reading saved results: works, with expanded files (red retracted)

RETRACTED 2026-09-24: the 2026-09-03 red was wrong about the cause. Saved result values DO load through AMEOpen on 2511, when the model is opened with use_expanded_files=True against the run files beside the .ame (_.results and siblings). The .ame archive itself carries no results. The 09-03 attempts read models whose run files were absent. And a trap found on the way: a PLAIN AMEOpen open DELETES the run files beside a model at open (29 files to 6), and an expanded open deletes them at close unless setKeepFilesWhenClosing(True). amesim-mcp now opens expanded plus keep whenever run files exist, and says plainly when there are none to read.

So on 2511:

  1. Results exist only where a run left them, beside the .ame. amesim_result_sets reports values_readable.
  2. amesim_result_values and amesim_plot read them directly; no rebuild or re-run is needed.
  3. When there are no run files, the tools say so instead of calling it a limitation.

Opening a model without the expanded files, from any script, destroys that model's run results. Open expanded with keep, or not at all.

2. addPostProcessedVariable does not persist through save

EXERCISED 2026-09-03. Red.

Re-tested 2026-09-24 with the expanded-files route that fixed result reading: still red. With all 29 run files present, an expanded open with keep-files, addPostProcessedVariable, then save: the variable is in memory, the save rewrites the .ame, .cir, .dll and .sim files but not .views, and an expanded re-open shows no post-processed variable. Correction: the first re-test that morning ran after an earlier step had already deleted the run files, so it tested nothing; this re-run replaces it. Neither ame_apy nor the other shipped scripting modules expose post-processing at all, so no other scripting route exists on 2511.

Adding an expression variable with ProcessingData.addPostProcessedVariable and then saving the model produces a file that shows nothing new on re-open. The amesim_post_processing tool verifies every write by re-opening the file and reports persisted: false when this happens, rather than echoing the in-memory list back as success.

3. Global parameters do persist

EXERCISED 2026-09-03. Green.

Create, set and delete of global parameters through AMEOpen, followed by save, survive a re-open: the amesim_global_parameters tool re-opens the file after each write and reads the value back. This is the control that shows the save path itself works, which is what makes limitation 2 a statement about post-processing rather than about saving.

Why the greens are listed with the reds

A write that returns without error is not evidence it landed. Each of these three was settled by re-opening the file and reading the artifact, not by reading the return value. Carry that habit into any new AMEOpen write.

Source: amesim-mcp/README.md (AMEOpen tools), tc-automation-skills amesim-model-authoring SKILL.md, roadmap item rm-0ga28abd · retrieved 2026-09-03