Changelog

Every resolved issue of Exudyn, newest first, with the version it produced. The micro version is the count of closed issues, so each line below is one version number: 1.10.160 is the 160th issue closed in release 1.10. An issue that was closed without being resolved is in no list: it changed nothing - which is why a release can span more version numbers than it has lines here.

Every entry carries the type of the issue, then its priority and its effort as badges (LOW EFF is within 2 hours, MEDIUM EFF is within 16 hours, HIGH EFF is within 40 hours, HUGE EFF is above 40 hours), then who raised it and who resolved it - both omitted when that was Johannes Gerstmayr (JG).

This file is generated; it is written by the tracker whenever an issue closes.

Only the current release is below. The issues resolved before it, in the same form, are in the issue tracker of the documentation, which also lists the open issues and the known bugs; the table that follows is the whole history at a glance.

release

name

resolved issues

highest version

1.13

Newborn

7

1.13.6

1.12

Metheney

367

1.12.462

1.11

McLaughlin

240

1.11.240

1.10

Lagrene

160

1.10.160

1.9

Krall

235

1.9.234

1.8

Jones

82

1.8.81

1.7

Hall

124

1.7.123

1.6

Gillespie

188

1.6.189

1.5

Fitzgerald

118

1.5.118

1.4

Ellington

66

1.4.65

1.3

Davis

106

1.3.105

1.2

Corea

147

1.2.146

1.1

Burton

178

1.1.177

1.0

Abercrombie

290

1.0.295

0.1

-

359

0.1.367

Version 1.13 - Newborn (current)

  • 1.13.6 TESTING HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG allExudynModulesTest fails where Python has no tkinter: the Windows jobs of GitHub CI (#2920)

    • description: GitHub CI of 1.13.5, windows-2025, cp313 (Python 3.13.12, the interpreter cibuildwheel installs for its tests): ‘Failed to execute …exudyn/misc/GUI.py: No module named tkinter’, so the model returns 0 and –exit-code fails all Windows wheel jobs; the other 15 jobs passed. tkinter is optional for Exudyn - only the dialogs need it, and every other module imports GUI.py lazily

    • notes: allExudynModulesTest skips GUI.py where Python has no tkinter, which only the dialogs need; the Windows jobs of GitHub CI pass again. revision2026b step RG10.27

    • date resolved: 2026-10-09 20:38, date raised: 2026-10-09

  • 1.13.5 TESTING HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the GitHub macOS test jobs fail on two platform differences, and Linux ARM has no list (#2919)

    • description: GitHub CI of 1.13.3, macos-15 ARM: geometricallyExactBeamRightAngleFrame (rel. 3.9e-10, cp313 and cp314) and objectFFRFreducedOrderTest (rel. 1.3e-08, cp314 only) differ beyond the tolerance and are not in UnresolvedOnMacOS, so –exit-code fails the job. Linux ARM (aarch64) was judged with UnresolvedOnLinux although it is arm64 and fuses a*b+c into FMA as macOS ARM does

    • notes: the test suite on macOS ARM accepts two more known platform differences (geometricallyExactBeamRightAngleFrame, objectFFRFreducedOrderTest on cp314), and Linux ARM is judged with the same list. revision2026b step RG10.26

    • date resolved: 2026-10-09 19:43, date raised: 2026-10-09

  • 1.13.4 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the Linux ARM wheels do not build: exudynCPPfast gets the x86-64 options -mavx2 -mfma (#2918)

    • description: GitHub CI of 1.13.3, ubuntu-24.04-arm: g++: error: unrecognized command-line option ‘-mavx2’ / ‘-mfma’ while compiling exudynCPPfast. A release version builds the fast module for every Python version and setup.py adds the AVX2 options on every Linux; a development version builds it only on cp313, so the ARM jobs of dev builds failed the same way there. __init__.py loads exudynCPPfast only on a CPU with AVX2, so on ARM it is never used

    • notes: the Linux ARM wheels build again: setup.py builds exudynCPPfast, with its AVX2 options, only on x86-64 Linux; on ARM it was never loaded. revision2026b step RG10.26

    • date resolved: 2026-10-09 19:43, date raised: 2026-10-09

  • 1.13.3 DOCU HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the GitHub start page and the PyPI page show stale texts with a dead link to theDoc.pdf (#2917)

    • description: GitHub shows README.md before README.rst: a 22-line leftover (RST syntax in a .md file, Python 3.6 - 3.9, docs/theDoc/theDoc.pdf), while README.rst is the landing page of Read the Docs. The PyPI description, inline in pyproject.toml, also pointed to theDoc.pdf; it is part of the wheel metadata, so the 1.13.2 wheels cannot be published with it (maintainer 2026-10-09, after pushing master)

    • notes: GitHub shows README.rst, the landing page of Read the Docs (the stale README.md is removed); the PyPI description links to the documentation on Read the Docs instead of the deleted theDoc.pdf. revision2026b step RG3.44

    • date resolved: 2026-10-09 17:08, date raised: 2026-10-09

  • 1.13.2 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev points to an empty setuppy.output.txt when a test fails (#2913)

    • description: after any failing build or release step exudev printed ‘compiler output: setuppy.output.txt’ - also when a test suite failed and the file was empty or from an earlier build; it now names the file only if this run wrote something into it

    • notes: exudev names setuppy.output.txt after a failed build or release only if this run wrote something into it. revision2026b step RG10.25

    • date resolved: 2026-10-09 13:04, date raised: 2026-10-09

  • 1.13.1 TESTING HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the AVX2 reference set is stale - 26 test models and 4 mini examples fail under exudynCPPfast (#2912)

    • description: AVX2ReferenceSolutionUpdate (recorded 2026-09-17) was not renewed when the regular reference values moved (modified Newton default #2815 and others), so the fast-module suite of the 1.13 release failed on 3.10 and 3.13; re-recorded from the fast logs of cp310 and cp313, which agree to the last digit

    • notes: the AVX2 reference set re-recorded from the fast-module suite on cp310 and cp313 (identical); contactFrictionCircleCable2DnoFrictionTest takes 1000 steps, so Newton converges and both modules agree; the mini example ObjectConnectorRigidBodySpringDamper has one value for both modules; runPerformanceTests.py applies the AVX2 set to its single runs. revision2026b step RG2.7

    • date resolved: 2026-10-09 13:04, date raised: 2026-10-09

  • 1.13.0 TESTING HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG test models that count refused input fail under exudynCPPfast (#2911)

    • description: the fast-module suite of the 1.13 release: createItemNumbersTest raised (the Create functions skip the item-kind checks in exudynCPPfast, so a node reaches AddMarker and raises ExudynTypeError instead of ValueError), homogeneousTransformationInterfaceTest counted 3 must-raise cases that raise nothing there, ANCFThinPlateRevisionTest failed testInvalidIntegrationModeRaises; these cases are judged only in the regular module, as symbolicModuleTest does (‘[FAST]’ in exu.config.Version(True))

    • notes: createItemNumbersTest, homogeneousTransformationInterfaceTest and ANCFThinPlateRevisionTest judge refused input only in the regular module; exudynCPPfast skips these checks by design. revision2026b step RG2.7

    • date resolved: 2026-10-09 13:04, date raised: 2026-10-09