Skip to content

Show the anisotropy the elastic averages throw away, and draw the Fermi surface - #21

Merged
Starlitnightly merged 1 commit into
mainfrom
elastic-anisotropy-and-fermi-plots
Aug 5, 2026
Merged

Show the anisotropy the elastic averages throw away, and draw the Fermi surface#21
Starlitnightly merged 1 commit into
mainfrom
elastic-anisotropy-and-fermi-plots

Conversation

@Starlitnightly

Copy link
Copy Markdown
Contributor

mv.pl.elastic — what four numbers were hiding

mv.prop.elastic computes the whole 6×6 stiffness tensor and stores it, then reports four Voigt-Reuss-Hill averages. Those are what a screen ranks on, and they are exactly the part of the tensor that survives averaging the direction dependence away. Computing the tensor and reading only the averages throws away the reason for computing it.

Copper, from its measured constants:

direction Young's modulus published
[100] 66.7 GPa 66.7
[110] 130.3 GPa 130.3
[111] 191.1 GPa 191.1
isotropic average ~120 GPa

A factor of 2.9 with direction, reported as one number. An isotropic solid returns exactly 1.000.

The subtle part is the Voigt factors. A compliance matrix carries a half on every shear index and a quarter on a shear–shear pair; a stiffness matrix carries none. Inverting the 6×6 and expanding without them gives a tensor that looks reasonable and reports an anisotropy that is not there. There is a test that deliberately drops the factors and asserts the result does go wrong, so that check cannot quietly stop checking.

mv.pl.fermi_surface — draw the stored mesh, not a recomputation

mv.elec.fermi_surface now keeps each sheet's vertices and faces. The interpolation takes minutes, and a plotting function that repeated it on every call would not be an interface worth having; keep_mesh=False is there for a screen that wants only the numbers.

A sphere wider than the Brillouin zone comes out with flat faces where it crosses the boundary — physics, not a rendering artefact.

Executing the tutorials found what the unit tests could not

mv.pl.elastic resolved a row against obs_names only, so row="Cu" reached int() and failed with a message about base 10 — a matverse dataset puts the formula in obs["name"] and leaves obs_names as integers.

The tests had named their own rows and always took the branch that matched. Fixed to follow mv.pl.structure's convention, with a regression test that says why it should have existed. This is the case for executing tutorials rather than rendering stored output.

Plotting coverage

Every plotting function is now called in a tutorial. The two that appeared only once — distribution and spacegroups — have a second use each, placed where they answer something rather than to make up a number: a histogram beside a screening threshold, and a space-group distribution over a search library.

Verification

981 pass on py3.12, 861 on py3.10. Contract-verified rate stays 165/165. All 16 notebooks execute. Docs build.

(Three TestBatchedEngine failures appeared in one run from GPU contention by other jobs on this node — nvidia-smi showed the card free afterwards and they pass on rerun. Not a regression.)

🤖 Generated with Claude Code

https://claude.ai/code/session_016wh5NzNE9Wn49nuUm7zg2a

…mi surface

mv.prop.elastic computes the whole 6x6 stiffness tensor and stores it, then
reports four Voigt-Reuss-Hill averages - bulk, shear and Young's moduli and a
Poisson ratio. Those are what a screen ranks on, and they are exactly the part
of the tensor that survives averaging the direction dependence away. Computing
the tensor and reading only the averages throws away the reason for computing
it.

mv.pl.elastic draws Young's modulus as a function of direction. Copper's
measured constants give 67 GPa along [100] and 191 along [111], a factor of
2.9, where the isotropic average is a single number near 120; the plot
reproduces 66.7, 130.3 and 191.1 along [100], [110] and [111], which are the
published values to the digit, and returns exactly 1.000 for an isotropic solid.

The subtle part is the Voigt factors: a compliance matrix carries a half on
every shear index and a quarter on a shear-shear pair where a stiffness matrix
carries none. Inverting the 6x6 and expanding without them gives a tensor that
looks reasonable and reports an anisotropy that is not there. There is a test
that deliberately drops the factors and asserts the result does go wrong, so
that check cannot quietly stop checking.

mv.pl.fermi_surface draws the sheets in three dimensions. mv.elec.fermi_surface
now keeps each sheet's vertices and faces, because the interpolation behind a
Fermi surface takes minutes and a plotting function that repeated it on every
call would not be an interface worth having; keep_mesh=False is there for a
screen that wants only the numbers. A sphere wider than the Brillouin zone
comes out with flat faces where it crosses the boundary, which is the physics
and not a rendering artefact.

Executing the tutorials found a bug the unit tests could not. mv.pl.elastic
resolved a row against obs_names only, so row="Cu" reached int() and failed
with a message about base 10 - a matverse dataset puts the formula in
obs['name'] and leaves obs_names as integers. The tests had named their own
rows and always took the branch that matched. Fixed to follow mv.pl.structure's
convention, with a regression test that says why it should have existed.

Every plotting function is now called in a tutorial, and the two that appeared
only once - distribution and spacegroups - have a second use each, placed where
they answer something rather than to make up a number: a histogram beside a
screening threshold, and a space-group distribution over a search library.

981 tests pass on py3.12, 861 on py3.10. Contract-verified rate stays 165/165,
all 16 notebooks execute, docs build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wh5NzNE9Wn49nuUm7zg2a
@Starlitnightly
Starlitnightly merged commit 82ca7ac into main Aug 5, 2026
6 checks passed
@Starlitnightly
Starlitnightly deleted the elastic-anisotropy-and-fermi-plots branch August 5, 2026 22:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant