MuPRO SDKDevelopment meeting · Combined monthly reviewAll reports

ISSUE 01 · COMBINED MONTHLY REPORT / 2026.08.12 — 2026.09.12

MuPRO SDK monthly review
and next two weeks

Data processing, component contribution and verification foundations have improved. The next phase focuses on completing the programmatic muFerro workflow from input preparation and execution to result retrieval.

Meeting: 2026-09-12Review: 08.12 — 09.12Plan: 09.13 — 09.26Evidence cutoff: 2026-09-12 18:17 UTC
Meeting schedule: Travel to a conference in Shenyang during the previous fortnight extended the interval between MuPRO meetings to one month. This issue combines the calendar month ending today; subsequent reports return to a biweekly schedule.

01 / Monthly overview

  • The materials computation data workflow is more complete. Optional parallel HDF5 output was added, alongside improvements to structure and material import, native field file I/O, batch processing, plotting and VTK interoperability.
  • Contribution and verification now have a common entry point. The registry covers 36 components across modules, runtime, C API and apps, including 11 apps. Build and test checks use actual dependencies, allowing contributors to run checks relevant to a component.
  • The dynamic phase-field program is integrated with original-source comparisons. muAFM and an antiferromagnetic module were added. Independent basic science tests also found a magnetic-field calculation defect that comparisons with the original program could not detect.
  • The release direction is agreed. Deliver the complete muFerro workflow for alpha.1 first. Alpha/beta releases need not wait for every scientific standard to be approved; stable releases must complete all mandatory scientific approvals and actual-build acceptance within the frozen scope.
  • The Shenyang conference advanced discussions with Computherm. Following detailed discussions with Weisheng Cao, the previous key has been recovered. The plan is to update muPREDICT to the new mode before reconnecting with the team on the new PanPhaseField SDK.

Current assessment: The engineering foundation has reviewable results; the complete programmatic delivery is still under development. The first alpha's main gaps concern the run contract, explicit paths, progress, results and acceptance of external invocation.

02 / Work over the past month

Results are grouped by topic below. “Committed” means the implementation is in the current Git history. “Locally verified” still includes uncommitted changes and does not imply remote delivery or publication.

1. Parallel HDF5 output Committed · Mid-August

The new L1_HDF5 supports scalar and multicomponent fields, multiple time steps, metadata and optional compression, with MPI partitioned writes and readback checks. Visualization tools can read fields and time series directly from HDF5, providing a lossless container for larger computations.

HDF5 is off by default; existing DAT/VTI paths remain available. Module capabilities have been verified, while HDF5 output still needs to be wired into each app. Evidence: 14a283f, HDF5 integration record.

2. Customer documentation and internal engineering records separated Committed · Mid-August

The customer site moved to web/ using Astro/Starlight; docs/ holds internal contracts, plans and acceptance records. Publication auditing remains part of the site build. Repository ownership was inventoried, and historical reports and dormant source were archived.

The documentation migration is complete, with a remaining content gap: ignore rules omitted PR-105's 13 module reference pages, which are still missing from the repository. Evidence: 8618d52, da9c391, 2101864; reference page recovery record.

3. SDK architecture, dependencies and scientific evidence Committed · Early September

runtime moved to the repository root and continues to compile into the same library as the numerical modules. Third-party dependencies have pinned sources and hashes; muparser replaced the scalar expression engine. The module registry, actual source dependencies, capability index and scientific case contracts are connected. Verification tools can retain inputs, source, run results and candidate evidence.

Source layering does not establish independent module execution or support for multiple runtimes. Candidate evidence does not grant scientific approval. Evidence: 8c0dbeb, f21f1e8, cc3876a, db11789, 7228a51; verification tool guide.

4. Preprocessing, result reading and run lifecycle Committed · Early September

Added structure/material file import, a standalone structure generation entry point, MPI data I/O and readers for native application field formats. Improved batch processing and plotting for DAT/HDF5/VTI/PVTI, plus visualization CLI/MCP access. Fixed axis order, field components, CSV, logging, allocation statistics and runtime lifecycle issues, with acceptance checks using real SDK consumers and independent readers.

The engineering inventory covered the 10 apps present at that time. Numerical behavior changes and impacts on historical results are recorded separately. Evidence: 3a47aac, f742fd1, e9a7f03, 2d9b41b; September 8 completion record.

5. Prerelease gates and CI evidence archives Committed · September 9–10

Confirmed distinct acceptance scopes for alpha, beta and stable releases, with muFerro first. Implemented binding to the actual build, installation, acceptance results and original package bytes. Fixed CI evidence uploads that failed on special filenames by archiving before upload, then verifying downloaded contents.

Local acceptance of release tools does not mean alpha.1 is complete. Actual muFerro acceptance scope, the aggregate configuration matrix and trusted scientific approval receipts still need to be connected; no SDK release was executed. Evidence: 23a6168, f5b1b46; release and archive acceptance.

6. Tiannan Yang's dynamic phase-field program Locally verified · September 11–12

Integrated the supplied two-sublattice magnetic program as apps/muAFM, adding L3_Antiferromagnetic for coupling, film boundaries and related calculations. Retained 17 original source files and provenance hashes. Across 18 cases, 1/2/3 ranks and Debug/Release, 108 original-versus-SDK comparisons passed, as did independent consumption after installation.

The current status is exploratory and preserves specific original-program behavior. This adds an application capability without expanding the muFerro-first alpha.1 launch scope. Evidence: muAFM integration record, application contract.

7. Independent findings from basic science checks Locally verified · September 12

Added 18 checks across three magnetic modules, covering analytic Maxwell modes, anisotropy energy gradients, LLG time-step convergence and norm, and two-sublattice invariants. Independent analytic answers detected overwritten transverse magnetic-charge derivatives. The ordinary L2 path was fixed; agreement with the original program could not reveal this defect.

The AFM compatibility path explicitly retains the original behavior. Original-source comparisons cannot establish the correctness of spatially nonuniform magnetostatics. Basic mathematical checks can continue, while material parameters, temperature laws and general noise/multiphysics model validity still require scientific judgment. Evidence: basic science checks and numerical changes.

8. Contribution interfaces, daily Skill and tool layout Locally verified · September 12

All 11 apps are registered and own their root build entry points. contribute.py provides static checks without a compiler and selects component and downstream tests from the real build graph. Added a project/module/app self-check Skill. Reorganized 23 tool, data and test paths, retaining compatibility wrappers for old commands. Meeting reports now have a canonical directory.

Configuration versus state, field ownership, lifecycle and failure semantics remain under refinement; the unified invocation workflow has not yet been delivered. Evidence: contribution guide, interface review, tool ownership, root directory responsibilities.

9. Shenyang conference and Computherm discussions Discussions completed · Follow-up pending

During the Shenyang conference, detailed discussions took place with Weisheng Cao of Computherm. The previous key has been recovered, and preparations are under way to reconnect on the new PanPhaseField SDK.

Sequence: Update muPREDICT to the new mode first, then reconnect on PanPhaseField SDK. The muPREDICT update is a prerequisite for this integration work.

Source: conference details supplied by the owner on 2026-09-12. The exact scope of the new mode, SDK version and coordination schedule have not yet been developed. This records discussions and intent, not a completed integration.

03 / Current development and verification

Recorded by actual execution date and configuration. Test counts from different configurations cannot be added to measure project completion.
ScopeEvidence as of this reportInterpretation and limits
Intel Debug803 / 803 passed · 09.12All-app configuration, HDF5 OFF; local evidence
Intel Release802 / 802 enabled checks passed · 09.122 existing Debug-only checks disabled; local evidence
Intel core Debug652 / 652 passed · 09.12Base configuration, HDF5 OFF; local evidence
HDF5 core Debug735 / 735 passed · 09.08Accepted earlier this month; not rerun this round; historical configuration and consumer evidence
Python tools258 tests + 113 subtests verified · 09.12Initially 257 passed and 1 MCP stdio test timed out. A targeted rerun against current source passed after local communication was allowed. These are two separate records.
Installed and relocated consumersDebug/core SDK and Python tools passedDebug consumed 22 modules and checked 11 apps; core consumed 13 modules; local summary
Original-source agreement / basic science108 original-source comparisons; 18 new checks passed per all-app configurationThese evidence categories remain separate and grant no model or standard approval.

The September 8 engineering acceptance batch recorded Debug 720, Release 719 and core 650. App registration, AFM and independent checks were subsequently added, producing the table above. Changes in test counts reflect changes in acceptance scope and do not estimate a software completion percentage.

Track three states separately: Engineering regressions have passing evidence; the scientific registry has 1 candidate, 0 approved and 35 not_standardized declarations; the complete installed alpha.1 workflow still awaits acceptance. It cannot currently be described as ready for release.

The September 10 record verified CI archive upload and download. This report did not query online jobs again or infer current runner health. Support claims do not extend beyond Linux/Intel. Original failures and retries are retained; numerical solvers were not rerun to write this report.

04 / Next two weeks: 09.13 — 09.26

Proposed primary acceptance goal: Run muFerro from an installed package in any working directory using explicit input/output paths; read progress while it runs and retrieve final results with provenance. Failures must explain their cause, and repeated runs must remain isolated.

The plan follows TASK dependencies P3/P4/P11 → P1/P10 → P5/P6 → P7/P8. Priorities and completion criteria are defined; named assignees and capacity must be confirmed at the meeting. This report makes no new alpha release date commitment.

Week 1 · September 13–19: Case preparation and diagnosable failure

  1. Run contract and three manifests (P3/P4/P11). Define the complete input file set, case identity, unique identity for each run, result/completion records and retryable/terminal failure classes. Deliver: A minimal contract, schemas and validation entry point. Accept when: Reproducible negative cases cover missing or modified inputs, stale success markers, retry after failure and concurrent directory overwrites. Retryability cannot be inferred from a status-code name alone.
  2. Minimal explicit muFerro entry point (P1). Implement input validation and options including --input, --output-dir and --help, reusing the existing solver workflow. Accept when: A case can be prepared and launched outside the repository; help returns before MPI initialization; invalid input produces a clear failure result.
  3. Close out already verified changes. Prepare review and commit material for muAFM, the contribution framework, scientific fixes, tools and documentation. Accept when: Each topic has a defined scope, actual evidence and compatibility notes; numerical changes are identified separately; original source and all 108 comparison records are traceable.

Week 2 · September 20–26: Connect results and verify the installed package

  1. Progress during execution and scalar results (P10/P4). First expose one quantity of interest (QoI) from existing muFerro output, declaring its name, units or unspecified units, calculation definition and source file without choosing a new formula. Accept when: Progress is readable before completion; the final value matches existing output; missing/nonfinite results and incomplete output cannot be read as success.
  2. Installed workflow and capability documentation (P1/P5/P6, feeding P0). Run a real case from the relocated SDK, checking inputs, run/result manifests, exit status and the complete result set. Complete the capability index, help and executable Skill for this workflow. Accept when: Success, invalid input, runtime failure and repeated runs are reproducible; the index accurately states supported scope; acceptance is bound to the actual installed package.
  3. Regression and meeting delivery. Check affected modules, downstream apps and installation boundaries. Changes to shared run/build contracts require full configuration regressions. Deliver: A demonstrable muFerro example, acceptance summary and remaining issues for the next cycle.

Extensions after prerequisites are complete

If the main workflow finishes early, implement P7's real concurrency across three parameter points with three traceable QoIs, followed by P8's discovery, validation, launch, monitoring and result retrieval through a real MCP client. Passing visualization MCP records cannot substitute for solver workflow acceptance.

Parallel work that needs allocated capacity

  • Interfaces and scientific checks: Add contracts and independent checks for configuration/solver-state separation, field ownership and repeated context lifecycles. Retain muAFM original-source compatibility evidence. Directly verify mathematically decidable properties; prepare named review material for material-model questions.
  • Customer reference pages: Follow the existing recovery procedure to locate original workstation source or build artifacts. After recovery, check all 13 pages and sidebar links and add build checks. If the material is unavailable, record the specific blocker before deciding whether to rewrite. This does not replace the main run workflow.
  • muPREDICT update and Computherm preparation: Define the new mode's scope and completion criteria, then schedule the update. After it is complete, reconnect with Weisheng Cao on the new PanPhaseField SDK. Establish this prerequisite first; implementation and coordination dates remain to be scheduled.

GPU, multiple runtimes, in-process Python solving, simultaneous unification of every app, ACCH/CALPHAD and comprehensive scientific approval are outside the primary acceptance goal for these two weeks and remain on the existing later roadmap.

05 / Open work and coordination

  • Substantial run workflow work remains. Registration of 11 apps and existing executables does not establish unified CLI, manifest or Python/MCP support for them. Beta interface freezing and real-scenario acceptance are also incomplete.
  • Scientific and maintenance responsibilities need named owners. All 36 maintainer fields remain unassigned. Assign module maintenance and scientific standard reviewers. Missing approval does not block decidable basic checks or otherwise eligible alpha/beta releases.
  • AFM compatibility mode has known limitations. Original-source comparisons remain evidence of source compatibility. A corrected spatially nonuniform magnetostatic mode needs a separate definition and verification. Current mathematical checks do not establish material calibration, temperature laws or noise/multiphysics model validity.
  • Historical results and customer documentation need follow-up. Historical-case impacts and customer communication for numerical fixes, plus issues in external repositories, remain with the existing H2/OWNER-007 responsibilities. The 13 customer module reference pages have not been recovered.
  • Release engineering must connect to the actual product scope. P0 still needs complete muFerro acceptance, an aggregate configuration matrix and trusted approval receipts. This month's work delivered supporting tools and partial verification; no SDK was released.

06 / Evidence and reporting scope

Engineering evidence covers the muprosdk repository from 2026-08-12 through 2026-09-12, grouped in the America/Los_Angeles time zone. It also includes the owner's September 12 account of the Shenyang conference and Computherm discussions. The exact date of the preceding meeting was not supplied; this report uses the calendar month ending today and does not retroactively assert that a meeting took place on a particular date.

Local Git baseline: 11c1b7818114bd09ed4a1f20de78e33ea1c8497b. The Skill script collected daily commits by all authors, yielding 58 unique commits after merge commits were excluded. This is a traceability measure, not a measure of hours or productivity. Uncommitted working-tree changes are included using their implementation files and existing acceptance records.

  • Current work packages and release definitions · Current handoff · Historical handoff
  • HDF5 implementation and limits · Documentation site decisions · Module and app completion record
  • Release tools / CI acceptance · muAFM comparisons · Independent scientific checks
  • Daily Git evidence (local) · Latest regression and installation summary (local) · Initial Python run (local) · Targeted MCP retry (local)

out/ does not travel with Git; another machine must obtain the original evidence or rerun the checks. Historical reports retain their original dates and configurations; work unverified then is not presumed to pass today. Revision note: on 2026-09-12, the same-day two-week draft was expanded into a monthly review and a detailed two-week plan to match this meeting's schedule. The previous copy remains in the local evidence directory.

Addendum, 2026-09-12: Added the owner's account of discussions with Weisheng Cao of Computherm, recovery of the previous key, and the sequence “update muPREDICT to the new mode → reconnect on the new PanPhaseField SDK.” The engineering evidence cutoff and test records are unchanged.

Translation note, 2026-09-15: Translated into English under the repository documentation policy. Reporting dates, historical results, source references and approval states remain those of the original report; this translation records no new test execution.