support simModSuite 2026

[cwsmith]

SimModSuite 2026.0-260411 replaces GM_createFromAssemblyModel() with ModelBuilder APIs. This PR makes those changes and moves and renames the header that provides the SimModSuite version to the top level dir of the repo (apf_simConfig.h -> simModSuiteConfig.h). This is a breaking change... but I don't know if anyone will care unless they are using our header to determine which SimModSuite APIs to call etc.

A couple alternatives:

• keep apf_sim/apf_simConfig.h.in and have other packages depend on it... this seems messy as gmi_sim doesn't/shouldn't depend on apf_sim
• drop support for SimModSuite prior to 2023 (we support 15.0.191017 and later) and use the simmetrix SimModSuiteVersion.h header - still a breaking change, but better in the long run to not rely on our own header for the same functionality

@bobpaw Thoughts?

[cwsmith]

/runtests

[github-actions]

Build Log
Simmetrix Test Result: success
Simmetrix + CGNS Test Result: success

[bobpaw]

SimModSuite 2026.0-260411 replaces GM_createFromAssemblyModel() with ModelBuilder APIs. This PR makes those changes and moves and renames the header that provides the SimModSuite version to the top level dir of the repo (apf_simConfig.h -> simModSuiteConfig.h). This is a breaking change... but I don't know if anyone will care unless they are using our header to determine which SimModSuite APIs to call etc.

Moving the file up sounds good to me. It can be a minor version bump if the apf_simConfig.h file is changed so that all it contains is #include <simModSuiteConfig.h>. Many compilers also support the #warning directive (standard since C23 [1]) that can be used to issue a deprecation notice. I suggest that the name be prefixed like other PUMI headers since neither PUMI nor Simmetrix use header subdirectories.

• keep apf_sim/apf_simConfig.h.in and have other packages depend on it... this seems messy as gmi_sim doesn't/shouldn't depend on apf_sim

I agree with the logic here.

• drop support for SimModSuite prior to 2023 (we support 15.0.191017 and later) and use the simmetrix SimModSuiteVersion.h header - still a breaking change, but better in the long run to not rely on our own header for the same functionality

The simModSuiteConfig.h could point to SimModSuiteVersion.h if it was found at configure time. It may also make sense to parse that file for version information instead of using the current install path heuristic. I did something similar a long time ago with the PDCurses library [2].

1. https://en.cppreference.com/c/preprocessor/error
2. https://github.com/bobpaw/FindPDCurses/blob/master/FindPDCurses.cmake

[bobpaw]

Shouldn't this PR target develop?

[cwsmith]

Thank you.
pumi_ or PUMI_ prefix for the header? I'm leaning towards pumi_.

regarding use of SimModSuiteVersion.h:
To keep things simple, I'd rather just have one approach: the current extraction from the install path or directly using SimModSuiteVersion.h.