Magnetoelastic interaction¶

Physical problem¶

This page is the public physical and authoring contract for the interaction. It separates authored semantics, planner resolution, executable backend lanes, and scientific qualification.

Governing equations and strain convention¶

The public six-component engineering-Voigt order is

The implemented density is

For example,

Symbols and SI units¶

Capability matrix¶

Python API and stage-first example¶

# %% Study, execution lane, and magnetic body
import fullmag as fm

nm = 1.0e-9
study = fm.study("magnetoelastic_authoring_boundary")
study.engine("fem")
study.device("cpu", precision="double")
study.mode("strict")
study.objects.mesh.defaults(cell_size=(2 * nm, 2 * nm, 2 * nm))
body = study.geometry(fm.Box(40 * nm, 20 * nm, 4 * nm), name="film")
body.Ms = 8.0e5
body.Aex = 13.0e-12
body.alpha = 0.02
body.m = fm.texture.uniform(1.0, 0.0, 0.0)

# The current stage facade does not yet attach the complete mechanics graph.
elastic = fm.ElasticMaterial(name="substrate_material", C11=1.66e11, C12=6.39e10, C44=7.96e10, rho=2329.0)
substrate_geometry = fm.Box(40 * nm, 20 * nm, 4 * nm, name="substrate_geometry")
substrate = fm.ElasticBody(name="substrate", geometry=substrate_geometry, elastic_material=elastic)
law = fm.MagnetostrictionLaw(name="cubic_b1_b2", kind="cubic", B1=2.4e6, B2=3.1e6)
load = fm.MechanicalLoad(kind="prescribed_strain", strain=(1.0e-4, 0.0, 0.0, 0.0, 0.0, 0.0))
coupling = fm.Magnetoelastic(magnet="film", body=substrate.name, law=law.name)
study.stages.add_run(stage_id="authoring_boundary", until=1.0e-15)

At the audited revision, the stage-first builder does not expose complete registration methods for ElasticBody, MagnetostrictionLaw, MechanicalLoad, and Magnetoelastic. Therefore the following is intentionally an IR-only construction test, not a runnable coupled simulation:

Do not surround disconnected objects with a normal run stage and call it a magnetoelastic example. Publish a complete stage example only after the mechanics graph can be attached and lowered end to end.

Validation boundary and required code corrections¶

Current API checks are incomplete:

• MagnetostrictionLaw.B1, B2, and lambda_s are not explicitly finite-validated.

• MechanicalLoad.strain and stress check length but not all numeric/finite values.

• ElasticMaterial currently requires positive \(C_{12}\), which is unnecessarily restrictive, while it does not enforce the actual cubic stability conditions \(C_{44}>0\), \(C_{11}-C_{12}>0\), and \(C_{11}+2C_{12}>0\).

The documentation must distinguish the current API restriction from physical stability, and the implementation should adopt the stability conditions.

ProblemIR semantics¶

The canonical term references named graph objects:

{
  "kind": "magnetoelastic",
  "magnet": "magnetic_film",
  "body": "elastic_film",
  "law": "b1b2"
}

Prescribed strain, the elastic material, and the law remain separate typed records. Isotropic lambda_s is not silently converted to \(B_1/B_2\) without a declared elastic/symmetry model.

Required numerical validation¶

• zero field and energy for zero strain;

• pure normal-strain analytic components;

• pure engineering-shear factor-of-two test;

• finite-difference derivative of energy versus field;

• active-mask/nonmagnetic-node exclusion;

• uniform versus per-node/per-cell strain equivalence;

• CPU/GPU comparison at matched integration weights;

• eventual coupled-mechanics energy exchange and convergence tests.

Limitations and roadmap¶

Quasistatic elasticity, elastodynamics, two-way magnetostriction, damping, acoustic radiation, and temperature-dependent elasticity are semantic API intentions, not currently executable features. Promote them only with a complete graph, time-integration policy, conservation/dissipation tests, and provenance.

Scientific bibliography¶

1. E. du Trémolet de Lacheisserie, Magnetostriction: Theory and Applications of Magnetoelasticity, CRC Press, 1993.

2. A. E. Clark, in Ferromagnetic Materials, Vol. 1, North-Holland, 1980.

Control Room crosswalk¶

This is a navigation page; the selected interaction or foundation is configured by its linked Python API and object/stage editor. The category itself has no standalone control. frontend support is not implemented applies to physical parameters without a matching control. See {doc}/frontend/capability-register; do not infer UI support from backend or Python availability.

Python/API crosswalk¶

The linked Python API page is authoritative for exact functions, arguments, units, and failure semantics. If this page is a foundation or category overview, runnable Python is ot applicable here and must be taken from the terminal API page.

Bibliography and source scope¶

Use the scientific bibliography and source-code index on the linked terminal page. This block adds no new equation or unverified implementation claim.

Round-trip and failure semantics¶

Requested intent preserves the authored model, coefficients, orientations, targets, and execution request. Resolved execution records the selected solver, device, precision, discretization, and capability decision. Validation errors reject malformed or contradictory data before runtime. Unsupported combinations fail closed and are not silently omitted or converted to another interaction.

Assumptions and validity¶

The authored model is valid only within the continuum, discretization, boundary, and capability limits stated on this page.

Implementation mapping¶

Python owns authoring and serialization, ProblemIR owns canonical intent, planners own legality and realization selection, and backend kernels own numerical evaluation.

Source-code index¶