Issue tracker

This section contains resolved issues per release and known bugs. Use this information to understand changes compared to previous versions. The extension .dev1 is not added in the issues list (e.g., 1.2.2.dev1==1.2.2), as it only marks versions that will not be available in pypi with standard pip install, but only with the --pre option or by specifying the exact version name, see versions on https://pypi.org/project/exudyn/.

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).

General information on current version:

  • Exudyn version = 1.13.6

  • last change = 2026-10-09

  • Number of issues = 2921

  • Number of resolved issues = 2783 (6 in current version)

Resolved issues and resolved bugs before version 1.13

The following list contains the issues which have been RESOLVED in the according version. The issues of the current release, 1.13, are in the changelog.

Version 1.12

  • 1.12.462 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG installation page: pip install -i https://pypi.org/project/ exudyn is not a valid index URL (#2910)

    • description: PDF check 2026-10-09. The simple index of PyPI is https://pypi.org/simple. revision2026b step RG3.43

    • notes: The installation page names a valid package index for pip, https://pypi.org/simple

    • date resolved: 2026-10-09 11:33, date raised: 2026-10-09

  • 1.12.461 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG generated signatures end in -> exudyn.ObjectInde) - the return annotation loses its last letter (#2909)

    • description: PDF check 2026-10-09: ‘exudyn.ObjectInde)’ in PDF and online, multiple times: CreateGround(mbs, …) -> exudyn.ObjectInde). GetFunctionArguments cuts the def line at a fixed place. revision2026b step RG3.43

    • notes: The function signatures of the documentation show return annotations completely, e.g. CreateGround(…) -> exudyn.ObjectIndex

    • date resolved: 2026-10-09 11:33, date raised: 2026-10-09

  • 1.12.460 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG LaTeX umlauts in the manual: Gr”ubler-Kutzbach, Br”uls (#2908)

    • description: The maintainer, checking the PDF before 1.13 (2026-10-09): ‘In the docs/theory section I found a couple of Gr”ubler-Kutzbach typos to be fixed. Please check and fix all such “o, “a and “u in the document.’ Leftovers of the LaTeX conversion in theoryMultibody.md, solver.md, introduction.md and the module headers of FEM.py and kinematicTree.py (generated pages). revision2026b step RG3.42

    • notes: The manual writes Grübler, Brüls, Schöberl, Zwölfer and Plücker with their letters instead of LaTeX accents, and the documentation check refuses a LaTeX accent in text

    • date resolved: 2026-10-09 10:21, date raised: 2026-10-09

  • 1.12.459 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG macOS: after Q or ESCAPE in the SolutionViewer, its window and a ‘tk’ window stay visible and empty (#2906)

    • description: macOS GUI check 2026-10-08, S7: after Q or Escape in the dialog, the SolutionViewer and a tk window remain visible but empty. Cocoa removes a destroyed GLFW window only when its events are processed, and a destroyed Tk window stays until Tk processes its events; the ‘tk’ window is the root left by the failed dialog of R6 (#2904). revision2026b step RG2.4.6.3

    • notes: macOS: the render window and the SolutionViewer leave the screen when they are closed; confirmed on the Mac

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

  • 1.12.458 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG the test suite of the GitHub wheels cannot fail: cibuildwheel test-command without –exit-code (#2907)

    • description: The test-command of [tool.cibuildwheel] (Linux, macOS, Windows) runs runTestSuite.py -quiet -local without –exit-code, so a failing test suite leaves the wheel job of .github/workflows/wheels.yml green; the GitLab job passes it. Maintainer 2026-10-09: ‘yes, add the –exit-code’. revision2026b step RG10.24

    • notes: The test suite run by the GitHub wheel builds (cibuildwheel) passes –exit-code, so a failing suite fails the wheel job

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

  • 1.12.457 FIX HIGH EFF resolved by: Claude-JG linux (#2140)

    • description: fix graphics-related crashes on linux versions, in particular when closing renderer and with mbs.SolutionViewer()

    • notes: No more crashes of the renderer or the SolutionViewer on Linux: a larger number of tests by the maintainer could not reproduce them

    • date resolved: 2026-10-08 20:01, date raised: 2025-07-10

  • 1.12.456 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG real-time mode: the time of a pause counts, the simulation jumps when it continues (#2905)

    • description: macOS GUI check 2026-10-08, K5: in real-time mode the simulation time runs on while paused; paused at 9 s, waited 5 s, continued: it jumps to 14 s and continues in real time. CSolverBase: the real-time pacing compares the simulated time with the wall-clock time since the start of the solver, pauses included (on every platform); and the realtime.factor is applied to the first value only, not inside the waiting loop. revision2026b step RG2.4.6.2

    • notes: Real-time mode: a pause (SPACE, pauseAfterEachStep) no longer counts as simulated time, the simulation continues where it was paused; realtime.factor holds while the solver waits

    • date resolved: 2026-10-08 19:15, date raised: 2026-10-08

  • 1.12.455 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG right click on a sensor: the properties dialog fails (ShowRightMouseSelectionDialog: showing the dictionary failed) (#2904)

    • description: macOS GUI check 2026-10-08 (tmp/MacOS/GuiManualCheckMacOS.txt), R6 with Sensor0 of guiManualCheckModel.py: ERROR: ShowRightMouseSelectionDialog: showing the dictionary failed, then an abort in plt.show of phase 5. Reproduced on Windows: TkinterEditDictionary.GetDictionary takes self.tree.item(i,’values’)[0], and for an empty value - fileName ‘’ of a sensor - Tk gives ‘’ instead of a tuple: IndexError. The broad except printed no reason. The Tk root the failed dialog left behind is the empty ‘tk’ window of S7 and plausibly the abort under the macosx backend of matplotlib. revision2026b step RG2.4.6.1

    • notes: The properties dialog of a right click works for items with an empty value, e.g. a sensor without a file name; a failure of the dialog names its reason

    • date resolved: 2026-10-08 19:15, date raised: 2026-10-08

  • 1.12.454 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG spotReinforcementLearning.py imports RL_Spot, which is not in the repository; checkExtras keeps a rotted exemption for exudynCPP (#2903)

    • description: Complete build of 2026-10-08, checkExtras warnings: broken import RL_Spot in Examples/FurtherExamples/spotReinforcementLearning.py - the model of that folder is spotModel.py with the same GetModel(addShoulderContact) (the Details line names it); and the exemption of exudynCPP is used nowhere. revision2026b step RG10.23.3

    • notes: spotReinforcementLearning.py imports spotModel, the model of its folder, instead of the missing RL_Spot; checkExtras reports no warnings

    • date resolved: 2026-10-08 18:46, date raised: 2026-10-08

  • 1.12.453 TESTING LOW EFF raised by: Claude-JG resolved by: Claude-JG pytest files use deprecated helpers where they do not test a deprecation (#2902)

    • description: Complete build of 2026-10-08: DeprecationWarnings of graphics.BrickXYZ (test_graphicsMiniExamples.py, test_zoomAllTrackMarker.py) and beams.GenerateStraightLineANCFCable/2D (test_itemCompatibility.py); these tests do not test the deprecations. revision2026b step RG10.23.2

    • notes: The pytest files use graphics.Brick and GenerateBeamElementsAlongLine where they do not test a deprecation

    • date resolved: 2026-10-08 18:46, date raised: 2026-10-08

  • 1.12.452 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG the quiet exudev build shows pip’s message on conflicting packages as an ERROR line without the conflicts (#2901)

    • description: Complete build of 2026-10-08 (tmp/completeBuild2026-10-08.txt), venvP313: ERROR: pip’s dependency resolver does not currently take into account all the packages that are installed … - the quiet filter of #2895 passed the first line (it contains error) and swallowed the conflicts listed after it (spyder-kernels 2.5.0 for spyder 6.1.2, setuptools 72.1.0 for sip). Not an error of the build. revision2026b step RG10.23.1

    • notes: The quiet exudev build shows pip’s message on conflicting packages in the environment as a note with the conflicts, instead of an ERROR line without them

    • date resolved: 2026-10-08 18:46, date raised: 2026-10-08

  • 1.12.451 TESTING LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev build –complete stops at the test suite of Python 3.10: energiesTest.py differs by 5.9e-11 with numpy 2.2 (#2900)

    • description: The local complete build of 1.12.450 (2026-10-07/08): wheels for cp310-cp314 built, then the test suite in venvP310 failed with energiesTest.py: 17.61488435881711 against 17.614884358875663, error -5.855e-11 (rel. 3.3e-12), tolerance 5e-14; the build stopped there, so 3.11-3.14 and the fast module were not tested. The same difference was seen on Linux (WSL 1.12.372) and put into UnresolvedOnLinux; venvP310 has numpy 2.2.5, the reference environment numpy 2.4.6 - a round-off difference, not a platform one. revision2026b step RG4.1.4

    • notes: exudev build –complete passes again: energiesTest.py gets a tolerance factor for the round-off difference of numpy 2.2, and seven performance references follow the modified Newton default of the time integration (#2815)

    • date resolved: 2026-10-08 08:51, date raised: 2026-10-08

  • 1.12.450 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG visualizationSettings.bodies.shells.inPlaneTiling: the subdivision of plates and shells in the drawing (#2899)

    • description: The maintainer, 2026-10-07, testing the ANCF thin shells: ‘there is no option in visualizationSettings.shells on how often plates/shells are subdivided in drawing - like a inPlaneTiling, per default 4 I would suppose. The cross-section tiling is currently less critical as it is probably linear. I also see that it probably does not use the 6-node triangles (which however would not help a lot, because for contour, the main problem is the subdivision for the values, not for the shape).’ The plate used bodies.beams.axialTiling (default 8). revision2026b step RG6.17

    • notes: Plates and shells (ObjectANCFThinPlate) are drawn with their own subdivision, visualizationSettings.bodies.shells.inPlaneTiling (default 4 x 4 quads per element), instead of the axial tiling of the beams

    • date resolved: 2026-10-07 22:38, date raised: 2026-10-07

  • 1.12.449 FIX MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the scaling of the render window and the dialogs, restarted: system scaling times displayScaleFactor for the renderer, the scaling of Tk plus dialogs.fontScaling for every dialog (#2898)

    • description: The maintainer’s measurements on Ubuntu with fractional scaling 200 percent, 2026-10-07 (after #2897): displayScaleFactor 0 / fontScaling 0: render window scaled, the settings tree scaled, but buttons and edit fields very small, help and command dialogs not scaled; displayScaleFactor 1: dialogs scaled with buttons and edit fields large (looks best), render window unscaled; fontScaling 0.5: all dialogs 2x smaller, buttons tiny; at 100 percent a displayScaleFactor 0.5 made the buttons huge. ‘I would suggest to kind of restart the scaling thing … a conservative approach … check at which places these factors take effect … consider that some tkFonts already scale with the linux fractional scaling, so double scaling is contraproductive … write up a table’. revision2026b step RG6.16

    • notes: The render window scales with the display scaling of the system times general.displayScaleFactor; every dialog - settings, help, command window, buttons and edit fields included - follows the system scaling, and dialogs.fontScaling is a factor on top of it; confirmed on Ubuntu with fractional scaling

    • date resolved: 2026-10-07 21:37, date raised: 2026-10-07

  • 1.12.448 CHECK LOW EFF resolved by: Claude-JG linux GLFW (#2277)

    • description: check if glfwGetWindowContentScale now works on newer GLFW version to enable display scaling on linux

    • notes: On Linux the display scaling of the system (also fractional scaling) is read through GLFW 3.3.6 or newer and scales the render window and the dialogs; confirmed on Ubuntu

    • date resolved: 2026-10-07 21:37, date raised: 2026-02-09

  • 1.12.447 CHANGE MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG one display scaling setting: general.displayScaleFactor (0 = system, > 0 = override); the dialog fonts of fontScaling for all widgets; after-callbacks of closed dialogs (#2897)

    • description: The maintainer’s check on Ubuntu, 2026-10-07: scaling is improved; the display scaling provided by Ubuntu works perfectly, so merge the factors: displayScaleFactor = 0 uses the scaling of Windows, Linux (macOS if possible), > 0 overrides; useWindowsDisplayScaleFactor and linuxDisplayScaleFactor deprecated (the linux value mapped to the new one, the windows value to a dummy). dialogs.fontScaling rescales only the inner text, not the buttons or the edit fields, and it rescales while the window opens; values < 1 were used too. ‘invalid command name …<lambda> while executing (after script)’ after closing dialogs. A crash ‘X Error of failed request: BadWindow (X_QueryTree)’, ‘terminate called without an active exception’ after changing a few parameters and re-opening. revision2026b step RG6.15

    • notes: One display scaling setting, general.displayScaleFactor: 0 uses the scaling of the system (Windows, Linux, macOS), a value > 0 replaces it; useWindowsDisplayScaleFactor and linuxDisplayScaleFactor are deprecated. dialogs.fontScaling applies to every widget of the dialogs, buttons and edit fields included, and closing a dialog no longer leaves invalid command name messages

    • date resolved: 2026-10-07 18:47, date raised: 2026-10-07

  • 1.12.446 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG InverseKinematicsNumericalExample.py fails: InverseKinematicsNumerical.Solve returns None for the joint values (#2896)

    • description: Found by the examples run of 1.12.443 (2026-10-07): TypeError: unsupported operand type(s) for *: ‘NoneType’ and ‘float’ in np.round(sol[0], 3) at line 72 - the solution of myIkine.Solve(T3, q0=…) is None. The example passed in the runs up to 1.12.279; the robotics classes were changed to exu.HT in between (#2821). Not investigated yet.

    • notes: InverseKinematicsNumericalExample.py solves a reachable pose again (the pose of a known configuration), and InverseKinematicsNumerical.Solve no longer fails on rounding the joint values of a failed solve

    • date resolved: 2026-10-07 18:47, date raised: 2026-10-07

  • 1.12.445 FIX MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG Ubuntu: fractional scaling not followed by the renderer, linuxDisplayScaleFactor without effect, dialogs.fontScaling not in the H and X dialogs (#2893)

    • description: The maintainer’s check on Ubuntu, 2026-10-07: ‘general.linuxDisplayScaleFactor does nothing (can be removed?); dialogs.fontScaling works for the visualizationSettingsDialog, but not for the other dialogs (X, H); the linux settings Fractional Scaling affects the dialogs font sizes, but not the renderer’s => fix if possible; the renderer’s font size can be adjusted currently with the view0.window.globalFontSize.’ revision2026b step RG6.14

    • notes: Fractional and other display scaling on Linux scales the texts of the render window and the dialogs (GLFW 3.3.6 or newer); confirmed on Ubuntu

    • date resolved: 2026-10-07 18:47, date raised: 2026-10-07

  • 1.12.444 IMPROVEMENT MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG quiet runs: the build shows its version and a progress line, the test runners a progress line and no tables; the test suite log 260000 lines of caught user errors (#2895)

    • description: The maintainer, 2026-10-07: ‘for the exudev build command, it would be extremely helpful to see in the console which exudyn version is built, and to see a progress during compilation … The same would be nice for TestModel and Example runs (in quiet case). For the test suite, after the run finishes with python tools/exudev test –env venvExuP313 it outputs a lot of text => should be the quiet case by default. Furthermore, the log file for the testsuite has, since about version 1.12.366, approx. 260000 lines after TESTMODEL 138 parameterConversionTest.py which is unacceptable (User ERRORs => we need a solution (turn off by environment setting/config.special flag, etc.)’ revision2026b step RG10.22

    • notes: Quiet runs: exudev build names the Exudyn version and counts the compiled files in one line; the test suite and the examples count the models in one line and end with their summary; exudyn.special.exceptions.writeErrorsToLogFile keeps caught errors out of the log (the test suite log: 7000 instead of 266000 lines)

    • date resolved: 2026-10-07 18:19, date raised: 2026-10-07

  • 1.12.443 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG docs job of GitLab CI fails: the generated page of a new test model was not committed (#2894)

    • description: GitLab docs job on ca70704f (tmp/gitlabRunsFailed/output.txt): docs/generated/testModels/testModelsIndex.md:7: WARNING: toctree contains reference to nonexisting document ‘docs/generated/testModels/fileHeaderThreadsTest’ - with -W one warning fails the build. The page was generated with #1450 but left untracked (git add -u adds no new files); regenerate.py reported it as a tier 2 warning only. Fix: commit the page; regenerate.py –check fails for a new generated file git does not know. revision2026b step RG10.21

    • notes: The documentation builds from a fresh clone again: the page of the test model fileHeaderThreadsTest is committed, and the regeneration check fails for a newly generated page that is not in git

    • date resolved: 2026-10-07 17:47, date raised: 2026-10-07

  • 1.12.442 CHECK MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG tkinter dialogs look awkward on Ubuntu: the Tk of conda on Linux has no Xft (#2890)

    • description: The maintainer, 2026-10-07: ‘as I have now also the build config for Ubuntu: I could test now improvements for font scaling (or fonts in general - they look awkward on ubuntu). If you include a setting (like for activating font scaling on linux, or coupling it temporarily for macos), I could test, if it works now.’ Two settings to test, default off: general.useDisplayScaleFactorOnLinux (glfwGetWindowContentScale on linux, #2277) and general.useTextMipmaps (the 64-pixel characters of the bitmap font minified with mipmaps instead of 2x2 linear sampling). After the tests: defaults decided, or the settings removed. revision2026b step RG6.13 [2026-10-07, Claude-JG]: Correction by the maintainer, 2026-10-07: ‘It is not about the renderer text - that is perfect, but the tkinter dialogs.’ The two renderer test settings are removed again. Cause found: the libtk8.6.so of the conda environments (tk 8.6.14/8.6.15 of the default channel) links no Xft, so Tk draws with X11 core fonts - no anti-aliasing, few sizes; the system Tk links libXft. Fix: the Xft build of conda-forge, conda install -c conda-forge ‘tk=*=xft_*’; the dialogs say so once on Linux when Tk reports fontsystem x11.

    • notes: On Linux with conda, the dialogs draw smooth fonts with the Xft build of tk from conda-forge; Exudyn says so once, and the installation page has a section Working with Ubuntu

    • date resolved: 2026-10-07 16:42, date raised: 2026-10-07

  • 1.12.441 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG UBSan: mbs.ComputeItem casts every object to CObjectBody (#2892)

    • description: The sanitizer job of GitLab CI (b834538a, gcc 14, test suite exit 0, AddressSanitizer 0, one UB report): src/Main/MainSystem.cpp:1242:29: runtime error: downcast of address … which does not point to an object of type ‘CObjectBody’. MainSystem::PyComputeItem cast the object to CObjectBody before the switch, also for connectors and constraints; the cases that use the body apply to bodies alone, so the pointer was never used for another object, but the cast itself is undefined behaviour. revision2026b step RG4.25

    • notes: mbs.ComputeItem casts an object to a body only if it is one; the sanitizer build reported the cast of connectors and constraints as undefined behaviour

    • date resolved: 2026-10-07 16:23, date raised: 2026-10-07

  • 1.12.440 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev accepts Python 3.15 and 3.16 when named (–py 315, venvP315) (#2891)

    • description: The maintainer, 2026-10-07: ‘the exudev and similar scripts only work until 3.14. Please also allow Python 3.15 and Python 3.16 with 315 and env venvP315, etc., keeping the standard still with 3.10-3.14.’ revision2026b step RG10.20

    • notes: exudev accepts –py 315 and 316 (also 3.15, P316) with the environments venvP315 and venvP316; –py all stays the version matrix 3.10-3.14

    • date resolved: 2026-10-07 16:02, date raised: 2026-10-07

  • 1.12.439 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG ffmpeg for the videos: conda install ffmpeg and pip install ffmpeg-python on every platform (#2889)

    • description: The maintainer, 2026-10-07: ‘for installation of ffmpeg, for the according places in the docs, please add: conda install ffmpeg (install ffmpeg in general); pip install ffmpeg-python (install python package). Tested on MacOS and linux. This removes the necessity for homebrew on mac (which takes very long); and it directly runs in the terminal.’ revision2026b step RG3.41

    • notes: Videos from recorded frames: the documentation and the messages of exudyn.interactive name conda install ffmpeg and pip install ffmpeg-python, which work on Windows, Linux and macOS without Homebrew

    • date resolved: 2026-10-07 14:29, date raised: 2026-10-07

  • 1.12.438 TESTING raised by: Claude-JG resolved by: Claude-JG Ubuntu GUI check: curved triangle tiling and recorded frames not reproduced from here (#2881)

    • description: exudynGuiCheckUbuntu.txt: K13 - openGL.advanced.curvedTriangleTilingAngle 90/5/15 shows no visible difference in graphicsCurvedShapes.py; S6 - Record frames in the SolutionViewer wrote no images (no images folder). Both need a screen: to be repeated with 1.12.37x (a failed PNG write is now reported in the console; the images go to images/ in the directory the script was started from), and the tiling compared with Windows.

    • notes: On Ubuntu the curved triangles follow the tiling angle (K13) and Record frames in the SolutionViewer writes its images (S6): the frame is read before the buffer swap, the first frame prints where it is written, a failed write is reported

    • date resolved: 2026-10-07 14:22, date raised: 2026-10-06

  • 1.12.437 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG GETTING_STARTED.md: exudev started as ‘python -m exudev’, which fails; the README does not point to the page (#2888)

    • description: The maintainer, 2026-10-07: ‘python -m exudev build –env venvExuP313 => this is I believe wrong, it should be: python tools/exudev build … Please check all commands in the getting started. It also should really help when starting up. The getting started document should also be linked from the README.md and README.rst in the repo root. Think about, if somebody clones the gitlab repo, the only info one has is the README.’ revision2026b step RG3.40

    • notes: The developer getting-started page starts the driver as python tools/exudev (python -m exudev fails without tools/ on the path), says what to do when conda is not found, and README.md and README.rst point to it

    • date resolved: 2026-10-07 14:09, date raised: 2026-10-07

  • 1.12.436 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG Record frames in the SolutionViewer writes no images, at random: saveImageAsData not initialized (#2887)

    • description: Found by the GUI check agent on Ubuntu over xrdp (S6, HEAD c3327c06): RenderViewDataVSC::saveImageAsData was never initialized and InitializeRenderState did not reset it; with a nonzero value SaveSceneToFile took the RedrawAndGetImage() path and returned before the directory or the file was written - no images folder, no error, only the message of the first frame. Random by nature (guiManualCheckModel.py failed 2/2, a minimal script worked). Second: in data mode SaveImage built a file name, counted the frame and printed it, so a RedrawAndGetImage() before a recording used up frame00000 and announced a file that never existed. revision2026b step RG2.4.5.1

    • notes: Record frames in the SolutionViewer writes its images every time: the flag that keeps a frame in memory for RedrawAndGetImage() is initialized, and RedrawAndGetImage() no longer uses up a frame number

    • date resolved: 2026-10-07 12:54, date raised: 2026-10-07

  • 1.12.435 EXTENSION HIGH MEDIUM EFF resolved by: Claude-JG coordinatesSolution (#1450)

    • description: add number of threads to solution files and more details on computer; check parameter variation and other files (e.g. numberOfThreads and final computation time)

    • notes: The version line of the solution and sensor file headers ends with the number of threads of the computation, e.g. ‘#Exudyn version = 1.12.435.dev1; Python3.13.2; Windows x86_64 FLOAT64; 4 thread(s)’

    • date resolved: 2026-10-07 12:05, date raised: 2023-02-25

  • 1.12.431 CHECK LOW EFF resolved by: Claude-JG linux GLFW (#2278)

    • description: check if call to glfwDestroyWindow from StopRenderer avoids crashes on linux?

    • notes: On Linux no more crashes when the renderer is closed; confirmed by the maintainer’s tests on Ubuntu (2026-10-07)

    • date resolved: 2026-10-07 10:59, date raised: 2026-02-09

  • 1.12.417 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG pip install –group dev fails on macOS and on Python 3.14+: scipy==1.15.2 has no wheel there (#2886)

    • description: The maintainer, 2026-10-07: on macOS with Python 3.14 and 3.15 ‘pip install –group dev’ does not work with the scipy restriction to 1.15 - it cannot be installed; remove the restriction for macOS in general, and for the newer Python versions use the current scipy. The pin of the dev group gets PEP 508 markers, as tools/ci/buildManylinux.sh already has for 3.14. revision2026b step RG10.19

    • notes: pip install –group dev works on macOS and on Python 3.14+: the dev group pins scipy==1.15.2 only where it has wheels (not macOS, Python < 3.14) and takes the current scipy elsewhere

    • date resolved: 2026-10-07 10:53, date raised: 2026-10-07

  • 1.12.416 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev issue html writes the HTML overview of the tracker (#2885)

    • description: tools/issueTracker/trackerlog.html is ignored by git and only written as a side effect of a verb that changes an issue, so a fresh checkout has none. The maintainer, 2026-10-07: ‘when I checkout the repo at another computer: I do not have the html page of the issue tracker (which is handy)’ - a verb that writes just this page. revision2026b step RG10.18

    • notes: exudev issue html writes the HTML overview of the tracker, tools/issueTracker/trackerlog.html, which git ignores - e.g. after a fresh checkout

    • date resolved: 2026-10-07 10:47, date raised: 2026-10-07

  • 1.12.415 FIX LOW EFF resolved by: Claude-JG linux (#2236)

    • description: fix wrong initialization for time in renderer on linux systems

    • notes: On Linux the time shown in the renderer starts at zero; confirmed by the maintainer’s repeated tests on Ubuntu (2026-10-07)

    • date resolved: 2026-10-07 10:47, date raised: 2026-01-26

  • 1.12.412 CHANGE NORMAL HUGE EFF raised by: Claude-JG resolved by: Claude-JG connectors and loads compute their marker values themselves instead of precomputed MarkerData (#2745)

    • description: The maintainer, 2026-09-29: compute marker values inside the connector (joint, constraint) and load functions, no precomputation of MarkerData; a new temporary data with smaller footprint per marker; check GeneralContact. Migration: a function in CObjectConnector / CLoad that does what the precomputation does today, then each connector and load changed. Advantage: automatic differentiation becomes much simpler. First an evaluation step - what is there now, what are the best options - since it shapes future items and the user elements. revision2026b group RG14.

    • notes: Connectors, joints, constraints and loads compute the values of their markers themselves, through an interface per marker kind, instead of a precomputed MarkerData for every marker; the rigid markers give a homogeneous transformation and the Jacobians follow by automatic differentiation (revision2026b step RG14.2)

    • date resolved: 2026-10-07 08:32, date raised: 2026-09-29

  • 1.12.375 DOCU raised by: Claude-JG resolved by: Claude-JG PDF: LaTeX macros and backslashes printed as text (#2883)

    • description: Maintainer 2026-10-07: ‘there are a couple of stray \LU, \pv, \mathbf, etc. in the PDF; there are many lost \ in the PDF, possibly \ from earlier line breaks’. Found in the text of the PDF: figure references that print the caption (its math stays LaTeX source), a pipe inside math in table rows (the table splits the cell - the rows of the hydraulic actuator, the spring-dampers, the rolling discs), display math not on lines of its own (ANCFThinPlate), LaTeX line breaks and spaces in the Markdown text (trailing backslash, backslash-space, backslash-comma) and backslash-commas in 12 issue texts of the tracker log.

    • notes: The PDF documentation no longer shows LaTeX commands or stray backslashes in its text.

    • date resolved: 2026-10-07 01:16, date raised: 2026-10-07

  • 1.12.374 CHECK MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG parameters and output variables that the C++ of an item does not use - found by RG13.3 (#2867)

    • description: Found by checking the descriptions against the implementation (RG13.3.2-.5); the descriptions say what IS now, the code is for a decision: ObjectContactCurveCircles - the output variables DisplacementLocal, VelocityLocal, ForceLocal are declared and give an empty vector, dynamicFriction and frictionProportionalZone are not used, polynomialData only bends the drawing; ObjectContactCircleCable2D - contactDamping is not used (commented out); ObjectConnectorCoordinateSpringDamperExt - velocityOffset only reaches the user function, the built-in law k(x-x0)+d*v ignores it; ObjectANCFThinPlate - strainIsRelativeToReference has no effect since the port of RG4.20 (strains always relative to the reference). Options per item: implement, or remove the parameter (no deprecation needed for 1.12-new ones).

    • notes: ObjectContactCurveCircles returns its output variables (gap, gap velocity and contact force per segment) and has friction; ObjectConnectorCoordinateSpringDamperExt uses velocityOffset in its damper force; the parameters contactDamping of ObjectContactCircleCable2D and strainIsRelativeToReference of ObjectANCFThinPlate, which had no effect, are removed.

    • date resolved: 2026-10-07 01:16, date raised: 2026-10-06

  • 1.12.373 BUG raised by: Claude-JG resolved by: Claude-JG Linux suite of 1.12.372: deprecation warnings on the console, energiesTest (#2882)

    • description: tmp/Ubuntu/ubuntuTestSuiteConsoleOutput.txt (maintainer, WSL, cp313): 73 DeprecationWarnings on the console. 69 are expected - parameterConversionTest sets every parameter, the deprecated names included, and homogeneousTransformationParameterTest compares rotationMarker0/1 with localHT - and are now kept off the console. 2 came from the mini examples ObjectANCFCable/ObjectANCFCable2D: the mini examples are generated from the miniExample texts in definitions/, so the conversion of #2873 in python/MiniExamples was undone by the next regeneration; the 11 texts are converted in definitions/. energiesTest.py differs by -5.9e-11 against 3e-11 (rel. 3.3e-12) and goes to UnresolvedOnLinux.

    • notes: The test suite no longer prints the deprecation warnings that its deprecation tests trigger on purpose, and the mini examples of the cable elements use GenerateBeamElementsAlongLine.

    • date resolved: 2026-10-07 00:03, date raised: 2026-10-06

  • 1.12.372 CHANGE raised by: Claude-JG resolved by: Claude-JG The default drawing size of nodes, markers and sensors is too small to see (#2880)

    • description: GUI checks on macOS and Ubuntu (K1, ‘some markers/sensors are too small to see’): defaultSize = -1 gives a radius of 0.001 * openGL.advanced.initialMaxSceneSize (1 by default), 1 mm in a scene of 1 m, whatever the size of the scene. Proposal, for decision: relative to the scene the renderer computed (maxSceneSize), e.g. 1 %, or a larger factor.

    • notes: The model of the manual GUI check draws markers and sensors larger and with thicker lines, and the check switches the simplified drawing styles.

    • date resolved: 2026-10-06 23:36, date raised: 2026-10-06

  • 1.12.371 EXTENSION raised by: Claude-JG resolved by: Claude-JG Shadows of GLSpheres in the OpenGL renderer (#2879)

    • description: Maintainer, GUIcheckMacOS.txt: the spheres drawn as GLSphere (display lists; graphics.Sphere and, since #2877, the spheres of connectors and joints) cast no shadow, because each may have many triangles. Proposal: a coarse shadow geometry, e.g. a cylinder or disc per sphere, with some artefacts that are acceptable.

    • notes: Spheres drawn as spheres (graphics.Sphere, the spheres of joints and connectors) cast shadows in the OpenGL renderer.

    • date resolved: 2026-10-06 23:36, date raised: 2026-10-06

  • 1.12.370 BUG MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG macOS: abort when a Tk dialog of the SolutionViewer is closed, and when matplotlib shows a window while the renderer runs (#2878)

    • description: GUIcheckMacOS.txt: (1) closing the SolutionViewer dialog after demo 2 aborts in PyEval_RestoreThread: the dialog’s Tk after-callback calls SC.renderer.DoIdleTasks, whose glfwPollEvents dispatches the Tk close event (one NSApp event loop), so tkinter’s PythonCmd runs nested inside a Python callback, with its saved thread state NULL. Proposal for the Mac session: inside a Tk mainloop on macOS, redraw without polling (Tk’s loop already delivers the GLFW events), e.g. DoIdleTasks(pollEvents=False). (2) graphicsDataExample.py: plt.show() with the renderer still running aborts in matplotlib’s macosx backend (PyEval_RestoreThread, GIL released); the example now stops the renderer first; whether a GLFW callback touches Python without the GIL is to be checked on the Mac.

    • notes: On macOS, the dialogs of SolutionViewer and AnimateModes no longer let the renderer pump the window events inside their tkinter callbacks, which aborted Python when a dialog was closed; SC.renderer.DoIdleTasks has the argument pollEvents for this.

    • date resolved: 2026-10-06 23:36, date raised: 2026-10-06

  • 1.12.369 BUG MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG First manual GUI check on macOS and Ubuntu (1.12.368): the findings that can be fixed without a screen (#2877)

    • description: From tmp/MacOS/GUIcheckMacOS.txt (maintainer) and tmp/Ubuntu/exudynGuiCheckUbuntu.txt (M. Pieber), 2026-10-06: CTRL+keypad rotation did nothing (R9); F2 showed no message (K10); the selection highlight lasted 0.5 s (R5); sensor traces missing in the raytracer (K7); graphics.Sphere ignored general.sphereTiling (tiling fixed at creation) and the spheres of connectors were triangles with sphereTiling 6 (= 4 segments as display list); contour Displacement: spheres not colored, and bodies without rotation colored by their local position (A3); a failed PNG write was silent; ConvertImages2Video failed with an ffmpeg without libx264 (conda-forge on macOS); the check list and its model: demo 2, which model, V4/V5 on items the settings reach, V14 ‘store’, S5, P1 (plot windows closed at the end of the script), marker/sensor sizes; the docs: ffmpeg on macOS, CTRL+F3 is a macOS system shortcut.

    • notes: Findings of the first manual GUI checks on macOS and Ubuntu: CTRL with the keypad rotates in small steps, F2 shows its message, sensor traces appear in the raytraced image, graphics.Sphere and graphics.Spheres follow visualizationSettings.general.sphereTiling (now 16), the spheres of joints and connectors are drawn smooth, the Displacement contour colors bodies without rotation and spheres correctly, ConvertImages2Video works with an ffmpeg without libx264 (macOS), and a failed image write is reported.

    • date resolved: 2026-10-06 22:59, date raised: 2026-10-06

  • 1.12.368 BUG raised by: Claude-JG resolved by: Claude-JG macOS: RedrawAndGetImage(useRaytracer=True) segfaults; double free of symbolic vector expressions (#2876)

    • description: Found by a Claude session on the Mac (tmp/MacOS/mac_*.txt, 2026-10-06). (1) Raytracer::SoftwareRenderer always ends by drawing the image into the OpenGL window (DrawImageRGBA), also when RedrawAndGetImage calls it from the Python thread without a current OpenGL context: a no-op on Windows, a NULL dereference in the CGL dispatch on macOS. (2) VectorExpressionSReal::Destroy releases its expressions but keeps the pointers; ~VectorExpressionSReal calls Destroy again after SymbolicRealVector::Destroy did, a double free (heap corruption at MINI EXAMPLE 25, symbolicModuleTest). Both fixes tested on the Mac; raytracerNOGLFWtest.py runs on macOS again.

    • notes: On macOS, SC.renderer.RedrawAndGetImage(useRaytracer=True) crashed, and freeing a symbolic user function that returns a vector corrupted the heap; both are fixed.

    • date resolved: 2026-10-06 18:06, date raised: 2026-10-06

  • 1.12.367 TESTING raised by: Claude-JG resolved by: Claude-JG The test suite runs the test models in one namespace, which hides a missing name; two models fail when run alone (#2875)

    • description: runTestSuite.py executes every test model with exec(…, globals()), so a name that a model uses without importing it is found if an earlier model imported it. Found with #2873: 15 test models and mini examples called GenerateBeamElementsAlongLine without importing it and passed the suite; run alone they stop with NameError. Run alone (pre-run of #2873), explicitLieGroupIntegratorPythonTest.py fails: SensorNode: OutputVariableType ‘_None’ is not available in node 0 (line 108); the example reevingSystem.py stops with an InternalError in SolveSteps. Proposal: a fresh namespace per model (a copy of the runner’s globals), and the pre-run as a check.

    • notes: The test suite runs each test model and mini example as if it ran alone, in a module of its own, so a missing import is found; restartFileTest passes on Linux.

    • date resolved: 2026-10-06 17:57, date raised: 2026-10-06

  • 1.12.366 CHANGE MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG Examples, test models and mini examples use the current item parameters, Create arguments and settings (#2873)

    • description: The shipped scripts still use deprecated item parameters (physicsMass, rotationMarker0, …), deprecated arguments of the Create functions (bodyNumbers, bodyNumber, …) and renamed settings; users copy from them. The scripts are pre-run, the deprecation warnings name file and line, and the names are replaced there; deprecated functions with a different signature (BrickXYZ, GenerateStraightLineANCFCable2D, …) are listed separately. Maintainer 2026-10-06.

    • notes: The examples, test models and mini examples use no deprecated functions any more: graphics.Brick instead of BrickXYZ, beams.GenerateBeamElementsAlongLine instead of GenerateStraightLineANCFCable(2D) and GenerateStraightBeam, rotationMatrixRef instead of eulerParametersRef. ObjectFFRFreducedOrderInterface works with rotationMatrixRef also for its default rigidBodyNodeType given as string.

    • date resolved: 2026-10-06 16:49, date raised: 2026-10-06

  • 1.12.365 BUG raised by: Claude-JG resolved by: Claude-JG Linux test suite: the restart file of RK44 is not read back; two new platform differences (#2874)

    • description: The WSL run of 1.12.363.dev1 (cp310): restartFileTest fails with ‘the restart file has a value that is not a number’. The explicit solver never initializes aAlgorithmic, so the restart file holds garbage (subnormal numbers, -nan); std::stod throws out_of_range for a subnormal number with glibc, not with MSVC. Fixed: aAlgorithmic set to zero, the restart numbers read with strtod. createSphereQuadContact.py (rel. 1.1e-7, since #2109) and computeItemTest.py (rel. 2.3e-11) differ on Linux and go to UnresolvedOnLinux.

    • notes: A restart file written by an explicit solver could not be read back on Linux: it contained uninitialized values; they are zero now, and the numbers of a restart file are read the same way on every platform.

    • date resolved: 2026-10-06 15:34, date raised: 2026-10-06

  • 1.12.364 BUG raised by: Claude-JG resolved by: Claude-JG JointSliding/JointSliding2D: SlidingCoordinate counts the last increment twice after a step (#2872)

    • description: After a step, PostNewtonStep has added the algebraic increment of the sliding coordinate to the data coordinate, but the algebraic coordinate keeps the increment; the output SlidingCoordinate (data + increment), and DisplacementLocal of JointSliding2D (#2870), add it a second time. Measured on the setup of SlidingJoint2DTest after 50 steps: data 1.00137056, SlidingCoordinate 1.00142803, increment 5.75e-5; DisplacementLocal shows the increment as tangential drift. The solver itself is not affected: the next Newton solves the increment against the updated data coordinate. Found with RG12.42.

    • notes: The output variable SlidingCoordinate of ObjectJointSliding and ObjectJointSliding2D counted the increment of the last step twice; it is the sliding coordinate of the step.

    • date resolved: 2026-10-06 15:17, date raised: 2026-10-06

  • 1.12.363 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG joints and connectors: consistent output variables - joint frame, drift and relative frame as HomogeneousTransformation(Local) (#2870)

    • description: Maintainer 2026-10-06: the connectors and joints have inconsistent output variables; consistent: local drift in joints, joint position/orientation (marker 0), relative position of connectors, DisplacementLocal for items without rotation, a new HomogeneousTransformationLocal for the drift of joints and the marker difference of connectors, HomogeneousTransformation for the joint frame J0 of the classical joints (not the rolling joints). Concept first (RG12.42), table in tmp/connectorOutputVariables.md; nothing implemented before the decisions.

    • notes: Joints and connectors give the same output variables for the same quantity: the new HomogeneousTransformationLocal (the joint frame J1 relative to J0, an exu.HT) for the joints and connectors on rigid markers, HomogeneousTransformation (the joint frame J0) for JointGeneric, JointRevoluteZ, JointPrismaticX and JointPrismatic2D, Position, Velocity and the force for JointRevolute2D and JointPrismatic2D, DisplacementLocal for JointPrismatic2D and JointSliding2D, Displacement for ConnectorRigidBodySpringDamper and ConnectorLinearSpringDamper.

    • date resolved: 2026-10-06 09:32, date raised: 2026-10-06

  • 1.12.362 CHANGE LOW EFF raised by: Claude-JG resolved by: Claude-JG settings dialog: the button ‘view as code’ is ‘store model view’ and gives SetModelView as CTRL+F3; ‘store positions’ explains it stores all windows (#2871)

    • description: Maintainer 2026-10-06: the button should be called ‘store model view’ and give SC.renderer.Start() and SC.renderer.SetModelView(zoom=…, rotationVector=[…], centerPoint=[…]) like CTRL+F3; the hints of ‘store positions’ were misleading: it stores the positions of all windows, not only of the dialog.

    • notes: The visualization settings dialog has a button store model view, which gives SC.renderer.Start() and SC.renderer.SetModelView(zoom, rotationVector, centerPoint) as CTRL+F3 prints it; store positions describes that it stores the positions of all open windows (revision2026b step RG6.10.1)

    • date resolved: 2026-10-06 08:55, date raised: 2026-10-06

  • 1.12.361 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG macOS: geometricallyExactBeamCurvedTest fails; FMA contraction of clang moves results (#2869)

    • description: Feedback from the macOS tests (maintainer 2026-10-06): geometricallyExactBeamCurvedTest needs staticSolver.newton.absoluteTolerance = 1e-6, in particular for P=0, which has no load to measure the residual against; -ffp-contract=off reduces the macOS differences from 8 models to 3 and should be the default: arm64 has FMA as baseline and clang/gcc contract a*b+c by default, MSVC does not.

    • notes: Builds on Linux and macOS no longer fuse a*b+c into one rounded operation (-ffp-contract=off), as Windows does not, which brings macOS results closer to the reference values; geometricallyExactBeamCurvedTest passes on macOS (revision2026b step RG4.1.4)

    • date resolved: 2026-10-06 08:55, date raised: 2026-10-06

  • 1.12.360 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev linux: WSL is asked for the repository path through its shell, which eats the backslashes (#2868)

    • description: exudev linux –py 313 stopped with ‘wslpath: C:DATAcppEXUDYN_git’ / ‘could not ask WSL for the repository path’ (maintainer 2026-10-06): WslRepositoryRoot ran ‘wsl wslpath -a C:\DATA...’, which current WSL (3.0) passes through the login shell; ‘wsl –exec’ and forward slashes fix it

    • notes: exudev linux works again on Windows: it asks WSL for the repository path with wsl –exec and forward slashes, which the login shell of current WSL no longer garbles (revision2026b step RG10.17)

    • date resolved: 2026-10-06 07:56, date raised: 2026-10-06

  • 1.12.359 DOCU HIGH EFF raised by: Claude-JG resolved by: Claude-JG RG13: each item’s description is synchronized once with its implementation, and the definition records that it was (#2717)

    • description: The maintainer, 2026-09-27: each item’s description needs to be one-time manually synched with the implementation; then it gets a ‘checked’ in the definitions file, or a better way for that. Proposal for the better way: the mark records not only who and when, but a fingerprint of the implementation it was checked against - the C++ source of the item (src/Impl<Kind>s/C<Item>.cpp and the generated header in src/Autogenerated/) - so that checkDefinitions can report a description whose implementation has changed since it was checked, instead of a checked flag that stays true forever. revision2026b step RG13.3.

    • notes: Every item description - nodes, objects, markers, loads, sensors - is checked once against its implementation and recorded with a fingerprint of the implementation in definitions/descriptionChecks.json; tools/checkDescriptions.py –check (in the all-checks gate) names an item whose implementation changed since, –mark records it again (revision2026b step RG13.3)

    • date resolved: 2026-10-06 07:12, date raised: 2026-09-27

  • 1.12.358 TESTING NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG a graphics regression suite: several models, several visualization settings (#2582)

    • description: The drawing code is exercised by exactly one model (#2562): raytracerNOGLFWtest.py, one set of visualization settings, one checksum. A checksum changes with any visualization change and does not say what changed, so it can only ever be “different” or “equal”. What is wanted is a suite over several models and several settings - show/hide of nodes, markers, loads and sensors, different colours and text settings - comparing either low-resolution reference images that a human can also look at, or counts extracted from the graphics data (triangles, lines, texts per item), or both: the counts say WHAT changed, the images say whether it still looks right. Needs the extraction API of the issue filed beside this one.

    • notes: the graphics regression suite: graphics data of every MiniExample, settings variants, user functions, raytracer image (revision2026b step RG2.3)

    • date resolved: 2026-10-05 23:05, date raised: 2026-09-22

  • 1.12.357 TESTING NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG the drawing code is exercised by exactly one test model (#2562)

    • description: The UpdateGraphics of every node, object, marker, load and sensor - ~4000 lines of drawing code - is called only by VisualizationSystem when the renderer runs, and every runner sets EXUDYN_SUPPRESS_UI_WINDOW_OPEN, so no test ever executes one of them. Moving all 79 of them in step R11.4.4 could only be verified by the compiler and by comparing the text of the bodies before and after. What is missing is a headless path that builds the graphics data of a model and checks it - the data is in VisualizationSystemData, so a binding that updates and returns a summary (number of triangles, lines, texts per item) would make the drawing code testable without a window. See revision2026 step R5.18.9. [2026-09-22, Claude-JG]: CORRECTION (maintainer, 2026-09-22): the original premise was wrong. python/TestModels/raytracerNOGLFWtest.py runs in the test suite with a reference checksum (runTestSuiteRefSol.py: 0.28151013387134) and calls SC.renderer.RedrawAndGetImage(useRaytracer=True), which goes through MainRenderer::RedrawAndGetImage -> VSC.UpdateGraphicsDataNow() and VSC.UpdateGraphicsData(), so the UpdateGraphics of every visible item IS executed and its result enters a compared number. What is true is narrower: exactly one model, one set of visualization settings, and a single checksum that changes with any visualization change without saying what changed. The broader work - a graphics regression suite over several models and settings, and the extraction API it needs - is filed separately.

    • notes: the drawing of every item is checked through its graphics data over all MiniExamples and the regression models (revision2026b steps RG2.3, RG2.1)

    • date resolved: 2026-10-05 23:05, date raised: 2026-09-20

  • 1.12.355 TESTING LOW EFF resolved by: Claude-JG computeInitialAccelerations (#2235)

    • description: add test for initial accelerations and velocities

    • notes: test model initialAccelerationsTest.py: the initial accelerations of the generalized-alpha method with a constraint and an initial velocity (revision2026b step RG4.19.11)

    • date resolved: 2026-10-05 23:05, date raised: 2026-01-23

  • 1.12.354 TESTING LOW EFF resolved by: Claude-JG CreateLinearSpringDamper (#1954)

    • description: add test example

    • notes: test model createLinearSpringDamperTest.py for mbs.CreateLinearSpringDamper (revision2026b step RG12.41)

    • date resolved: 2026-10-05 23:05, date raised: 2025-02-05

  • 1.12.353 EXTENSION LOW EFF resolved by: Claude-JG CreateLinearSpringDamper (#1953)

    • description: add create function to MainSystem

    • notes: mbs.CreateLinearSpringDamper: a linear spring-damper along an axis between two rigid bodies or rigid markers, with the arguments of the joints (revision2026b step RG12.41)

    • date resolved: 2026-10-05 23:05, date raised: 2025-02-05

  • 1.12.351 CHECK LOW EFF resolved by: Claude-JG symbolic (#1740)

    • description: check examples in Docu for consistency

    • notes: The examples of the symbolic page run: they use esym = exudyn.symbolic, the module functions IfThenElse/SetRecording/GetRecording and Real(‘name’, value) (revision2026b step RG4.19.11)

    • date resolved: 2026-10-05 23:05, date raised: 2023-12-19

  • 1.12.347 TESTING MEDIUM EFF resolved by: Claude-JG GenericODE2 (#777)

    • description: add tests for dense and sparse mass and jacobian matrices, together with sparse/dense solvers

    • notes: ObjectGenericODE2 with dense and sparse matrices, with the dense and the sparse solver, gives the same motion: test model genericODE2matrixFormatsTest.py (revision2026b step RG4.19.11)

    • date resolved: 2026-10-05 23:05, date raised: 2021-10-09

  • 1.12.344 CHECK LOW EFF raised by: Claude-JG resolved by: Claude-JG a MainSystem does not keep its SystemContainer alive (#2851)

    • description: SC.AddSystem() returns the MainSystem with return_value_policy::reference: a script that keeps mbs but drops SC (del SC, or SC created inside a function that returns mbs) works on a system the container has deleted. GetGeneralContact keeps its system alive since #1512 (reference_internal); the same for AddSystem/GetSystem would tie mbs to SC. Check what else depends on the current behaviour (SC.Reset, the renderer) before changing it.

    • notes: SC.GetSystem(i) keeps its SystemContainer alive, as SC.AddSystem() does (revision2026b step RG4.19.10)

    • date resolved: 2026-10-05 18:49, date raised: 2026-10-05

  • 1.12.343 CHECK MEDIUM EFF resolved by: Claude-JG Newton (#1337)

    • description: C++: check if SysError(s) in CSolverBase::Newton() can be changed into regular failure and step reduction for adaptiveStep

    • notes: With adaptiveStep or automatic step size, a singular system Jacobian is a failed step, which is reduced; a singularity of the model ends the run at the minimum step size with the causing coordinate (revision2026b step RG4.19.4)

    • date resolved: 2026-10-05 18:49, date raised: 2022-12-26

  • 1.12.342 CHECK MEDIUM EFF resolved by: Claude-JG ContactFrictionCircleCable2D (#1290)

    • description: shows tangential forces in case of all friction stiffness and damping values are zero; may be caused by specific projection

    • notes: ObjectContactFrictionCircleCable2D without a friction model (frictionStiffness and frictionVelocityPenalty zero) has no tangential force, also when its data node starts in slip (revision2026b step RG4.19.5)

    • date resolved: 2026-10-05 18:49, date raised: 2022-11-05

  • 1.12.341 CHECK MEDIUM EFF resolved by: Claude-JG CSystem (#692)

    • description: check JacobianAE: jacobianGM.AddSubmatrixTransposed(temp.localJacobianAE_ODE2_t … if _t is correctly used

    • notes: The numerical Jacobian of algebraic equations (numericalDifferentiation.forAE) adds for each constraint row only the transposed block the residual has - dC/dq for position-level, dC/dq_t for velocity-level constraints; the analytic one was right (revision2026b step RG4.19.6)

    • date resolved: 2026-10-05 18:49, date raised: 2021-06-28

  • 1.12.340 EXTENSION HIGH EFF raised by: Claude-JG resolved by: Claude-JG a restart mechanism: how a simulation continues from its restart file (#2850)

    • description: The maintainer, 2026-10-05: before a restart function is written, evaluate how a restart works together with a model script - where the restart file is injected, for example that the system detects a restart file and loads its state from it. The restart file is written already (simulationSettings.solution.restart); a prototype that reads it is _InitializeFromRestartFile in basicUtilities.py, not public. Successor of #1565.

    • notes: A dynamic simulation continues from its restart file: with solution.restart.write the solvers write the state every writePeriod and at the end, and with solution.restart.continueIfAvailable the same script continues from it, appending to the solution and sensor files; results are identical to an uninterrupted run (with modified Newton within the Newton tolerance) (revision2026b step RG12.39)

    • date resolved: 2026-10-05 18:00, date raised: 2026-10-05

  • 1.12.339 TESTING MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the PDF documentation is built in no gate (#2856)

    • description: The maintainer, 2026-10-05: a PDF check in the docs gate. Today exudev docs builds only the html; the PDF (exudev docs –pdf, about 2.5 min) is a release artifact, so a table that runs into the footer, an overfull box, a formula LaTeX cannot set or a missing figure surfaces only when someone reads the PDF. Proposal: exudev docs –pdf –check, run with the gates when the documentation changed, that fails on LaTeX errors and reports overfull boxes and other warnings of the LaTeX log against a baseline.

    • notes: exudev docs –check builds the PDF and fails on a new LaTeX problem against tools/pdfLogBaseline.json - an error, a missing file or character, an undefined reference, a float or box too large for its page, a line much too wide - with its page; part of the docs gate for changes to docs/, definitions/ or conf.py (revision2026b step RG3.36)

    • date resolved: 2026-10-05 17:30, date raised: 2026-10-05

  • 1.12.338 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev notebooks fails: no –env option (#2865)

    • description: exudev notebooks stops with AttributeError: ‘Namespace’ object has no attribute ‘env’ - the subparser of notebooks has no –env although Notebooks() in commands.py reads options.env and its help names –env venvP313; found in RG12.40, where tools/runNotebooks.py was run directly instead

    • notes: exudev notebooks takes –env (and –py) again; it stopped with an AttributeError without it (revision2026b step RG10.16)

    • date resolved: 2026-10-05 17:13, date raised: 2026-10-05

  • 1.12.337 CHANGE MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG Create functions: itemNumbers instead of bodyNumbers and bodyOrNodeList (#2863)

    • description: The maintainer, 2026-10-05: several Create functions accept bodies, nodes and markers in bodyNumbers, some also bodyOrNodeList; the new interface is itemNumbers=[None,None]; bodyNumbers stays, deprecated for 5 years; bodyOrNodeList stays with a DeprecationWarning that names itemNumbers. Affected (to be checked): CreateSpringDamper, CreateCartesianSpringDamper, CreateRigidBodySpringDamper, CreateTorsionalSpringDamper, CreateRevoluteJoint, CreatePrismaticJoint, CreateSphericalJoint, CreateGenericJoint, CreateDistanceConstraint. A proposal for decision first.

    • notes: The Create functions take bodies, nodes or markers in itemNumbers, CreateForce and CreateTorque one item in itemNumber; bodyNumbers and bodyNumber are deprecated until 2031, bodyOrNodeList and bodyList raise a TypeError naming itemNumbers; exudev scripts –fix rewrites them (revision2026b step RG12.40)

    • date resolved: 2026-10-05 16:10, date raised: 2026-10-05

  • 1.12.336 CHANGE MEDIUM EFF resolved by: Claude-JG CreateCoordinateConstraint (#2337)

    • description: change bodyNumbers to itemNumbers allowing both bodies and nodes to be constrained

    • notes: CreateCoordinateConstraint takes a body, a node, or None for the ground in itemNumbers; the coordinate of a body is counted over its nodes (revision2026b step RG12.40)

    • date resolved: 2026-10-05 16:10, date raised: 2026-04-06

  • 1.12.335 CHANGE MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG ANCF thin plate: one sign of curvature and moment, thickness gradients along the node slopes, SurfaceMap, the builder removed (#2864)

    • description: The maintainer’s decisions of 2026-10-05 on RG4.20.4: CurvatureLocal and TorqueLocal with one sign (the negated first component was wrong); ShellMesh projects the global thickness gradient onto the unit node slopes; default integration mode 0 everywhere; the maps as static methods of SurfaceMap without the Map prefix, no aliases; SymSin/SymCos removed (exu.symbolic.sin/cos take floats); ANCFThinPlateBuilder removed without deprecation - it was public only in development versions since 2026-10-05 - and ShellMesh takes a surfaceMap instead.

    • notes: ObjectANCFThinPlate: CurvatureLocal and TorqueLocal with one sign, positive where the surface bends towards its normal; exudyn.shells: ShellMesh(surfaceMap=…) with the maps of SurfaceMap (Cylinder, ConeFrustum, HemisphericalShell, ToroidalPanel, …), thickness function gradients along the node slopes.

    • date resolved: 2026-10-05 15:35, date raised: 2026-10-05

  • 1.12.334 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG ANCF thin plate visualization of the working copy 2026: normal offset, postprocessed contour, contour layer (#2859)

    • description: From the same working copy: visualizationSettings.bodies.shells drawNormal, drawNormalFactor, drawNormalColor, drawNormalLines, usePostprocessedContour (node-averaged contour) and contourZeta; finer tiling; the storage of the postprocessed values in VisualizationSystem. Not the setting integrationMode (port note 2).

    • notes: ObjectANCFThinPlate drawing: visualizationSettings.bodies.shells.contourZeta (thickness coordinate of the contour), reducedInterpolation (strain-type contours interpolated bilinearly from the element corners) and drawNormal, drawNormalFactor, drawNormalColor, drawNormalLines (the contour value along the surface normal); bodies.beams.axialTiling quads per direction.

    • date resolved: 2026-10-05 15:35, date raised: 2026-10-05

  • 1.12.333 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG visualization settings dialog: a button that shows the current model view as code (#2862)

    • description: The maintainer, 2026-10-05: an additional button in the visualization dialog exports the important parts of the current render state - center point, zoom, model rotation, window size - so that they can be set in the code and the model view is the same on every rerun.

    • notes: The visualization settings dialog has a button ‘view as code’: it shows and copies the lines that give a script the current model view of the render window - window size, center point, zoom, model rotation - so that every run starts with this view.

    • date resolved: 2026-10-05 14:37, date raised: 2026-10-05

  • 1.12.332 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG macOS (Apple clang 15): CObjectJointGeneric.cpp does not compile - missing ‘template’ before GetColumnVector (#2861)

    • description: Reported 2026-10-05 for 1.12.324.dev1 on arm64 macOS, Python 3.13: in ComputeConstraintEquationsTemplate, A0all is a ConstSizeMatrixBase<TReal, 9>, so A0all.GetColumnVector<3>(…) needs the template keyword (lines 156, 168, 184, the velocity level written by RG14.2.13 on 2026-10-02). MSVC accepts it, clang does not.

    • notes: macOS (Apple clang): ObjectJointGeneric compiles again; three calls of GetColumnVector on a matrix of the template type had no template keyword.

    • date resolved: 2026-10-05 10:20, date raised: 2026-10-05

  • 1.12.331 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG the settings tables repeat every access path in the name column (#2860)

    • description: The maintainer, 2026-10-05: a settings item lists its name and each full path (simulationSettings.timeIntegration.newton.numericalDifferentiation.doSystemWideDifferentiation, …staticSolver…), which makes the tables unreadable online and in the PDF; the paths belong once into the description of the structure, the table names the item only.

    • notes: The tables of the simulation and visualization settings name each item by its name only; the description of each structure says once where it is reached, e.g. simulationSettings.timeIntegration.newton.numericalDifferentiation.

    • date resolved: 2026-10-05 09:56, date raised: 2026-10-05

  • 1.12.330 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG exudyn.shells: ANCFThinPlateBuilder, geometry maps and plate helpers of the working copy 2026, ported (#2858)

    • description: From the same working copy: ShellMesh with stiffness-proportional damping and a thickness function (12 thickness values), exact slopes of the bilinear corner map, ANCFThinPlateBuilder, geometry maps (cylinder, cone, hemisphere, torus, Bezier strip, …), constraint, edge-load and hinge helpers; names in UpperCamelCase.

    • notes: exudyn.shells (revision by Michael Pieber): ANCFThinPlateBuilder for plate meshes on mapped rectangles, the maps MapCylinder, MapConeFrustum, MapHemisphericalShell, MapToroidalPanel, MapBezierStrip and others, functions for constraints, edge loads and hinges of plate nodes, and ShellMesh with stiffness-proportional damping and a thickness function.

    • date resolved: 2026-10-05 09:16, date raised: 2026-10-05

  • 1.12.329 EXTENSION HIGH EFF raised by: Claude-JG resolved by: Claude-JG ObjectANCFThinPlate: the revision of the working copy 2026 (M. Pieber), ported (#2857)

    • description: A colleague (Michael Pieber) checked the element against the literature in his working copy and documented the changes in tmp/shells/changesANCFThinPlate2026: material curvature measure, separate membrane and bending integration (modes 0, 1, 2), 12 thickness values and stiffness from the local thickness, Kelvin-Voigt damping, two-pass automatic differentiation of the Jacobian, outputs through the thickness (StrainLocal, StressLocal, ForceLocal, TorqueLocal). Port into the current repository with the renames of 1.12 and the corrections of the port notes.

    • notes: ObjectANCFThinPlate (revision by Michael Pieber): curvatures of the material measure, membrane and bending integrated at separate points (useReducedOrderIntegration 0: Gauss 5x5; 1 and 2: Lobatto 3x3 for the membrane, Gauss 2x2 for the bending), 1, 4 or 12 thickness values with the stiffness from the local thickness, Kelvin-Voigt damping (stiffnessProportionalDamping, bendingStiffnessProportionalDamping) that does not damp rigid motion, and StrainLocal, StressLocal, ForceLocal, TorqueLocal through the thickness; StrainLocal has 6 components, CurvatureLocal is [-kxx, kyy, kxy]; test model ANCFThinPlateRevisionTest.py.

    • date resolved: 2026-10-05 09:16, date raised: 2026-10-05

  • 1.12.328 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG the renamed and deprecated item parameters are listed only on each item’s page (#2855)

    • description: The maintainer, 2026-10-05: the settings changes are listed at the end of the settings pages, but where are the item parameter changes listed? Each item page lists its own under the parameter table; a list of all of them, like that of the settings, is missing.

    • notes: The index page of the items reference manual lists every renamed and deprecated item parameter, with a link to its item, as the settings pages list theirs.

    • date resolved: 2026-10-05 02:07, date raised: 2026-10-05

  • 1.12.327 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectFFRF and ObjectFFRFreducedOrder: the acceleration row of the output variables table is broken over several lines (#2854)

    • description: A Markdown table row is one line; the formula of the Acceleration row was written over five lines, so the table ended there and the rest of the formula was printed as text after it (the maintainer, 2026-10-05, in the PDF).

    • notes: The acceleration rows of the output variables of ObjectFFRF and ObjectFFRFreducedOrder are one table row again; the rest of the formula was printed as text after the table.

    • date resolved: 2026-10-05 02:07, date raised: 2026-10-05

  • 1.12.326 DOCU MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG tables in the PDF: too narrow columns, and tables running into the footer (#2853)

    • description: The maintainer, 2026-10-05: the notation tables (Symbols in item equations) and the ‘Definition of quantities’ of ObjectMass1D, ObjectRigidBody, ObjectFFRFreducedOrder, ObjectRotationalMass1D have columns of 20 % of the page; tables longer than the page overlap with the footer (e.g. SolutionFileSettings); the name column of the settings tables is too narrow, their size column mostly empty; headers ‘type / function return type’ and ‘default value’ are longer than their content.

    • notes: In the PDF, every table in a section breaks across pages instead of running into the footer, and a table without widths of its own gets them from its content; the settings tables have no size column, short headings (name, type, default) and a wider name column; the item tables say default.

    • date resolved: 2026-10-05 02:07, date raised: 2026-10-05

  • 1.12.325 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG the reference pages name the notebook of an example after every code cell (#2852)

    • description: The maintainer, 2026-10-05: in the pages of the Python-C++ interface, ‘(from the notebook …)’ follows every code cell that comes from a notebook; it shall appear once per notebook and page, after its first code cell, smaller and directly under the cell, and only the file name.

    • notes: The pages of the Python-C++ interface name the notebook an example comes from once, after its first code cell on the page, as its file name, small and directly under the cell.

    • date resolved: 2026-10-05 01:46, date raised: 2026-10-05

  • 1.12.324 CHECK LOW EFF raised by: Claude-JG resolved by: Claude-JG GeneralContact: the implicit solver keeps a contact only while its force presses, the explicit one while the bodies penetrate (#2848)

    • description: With contact damping, the active set of the implicit solver (PostNewton) takes a contact only if k*gap + d*v_n < 0; the explicit solver, and ObjectContactSphereSphere / SphereTriangle / Coordinate in both, take it while gap < 0, so the damping can pull at the end of a contact. A ball dropped onto a triangle rebounds to 0.1391 implicit against 0.1352 (contactComparisonTest.py). Decision: which of the two is the model, and then make both solvers do it.

    • notes: GeneralContact.keepContactWhilePenetrating = True: a sphere-sphere or sphere-triangle contact acts while the bodies penetrate, and its damping may pull at the end of the contact, as ObjectContactSphereSphere and ObjectContactSphereTriangle do; by default it acts only while its contact force presses (contactComparisonTest.py).

    • date resolved: 2026-10-05 01:15, date raised: 2026-10-04

  • 1.12.323 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG GeneralContact: a triangle body gets no torque from the normal force of a sphere-triangle contact without friction (#2849)

    • description: In the sphere-triangle contact of GeneralContact the torque (trigPP - rigid.position) x fVec on the rigid body of the triangles is added only if dryFriction != 0; the normal force at the contact point also has a moment about the body’s reference point, so a moving triangle body without friction gets no torque from its contacts. The same condition in the Jacobian. Ground triangles are not affected.

    • notes: GeneralContact: the rigid body of the triangles of a sphere-triangle contact gets the torque of the contact force also without friction, so that linear and angular momentum are conserved; test model generalContactTriangleMomentumTest.py.

    • date resolved: 2026-10-05 00:59, date raised: 2026-10-04

  • 1.12.322 CHECK HIGH MEDIUM EFF resolved by: Claude-JG return value policy (#1512)

    • description: check return value policy of GeneralContact (as example for further decisions); see if reference in ALL access functions makes no problems if object is deleted on Python side

    • notes: The GeneralContact returned by mbs.AddGeneralContact() and mbs.GetGeneralContact() keeps its MainSystem alive.

    • date resolved: 2026-10-05 00:44, date raised: 2023-04-13

  • 1.12.321 CHECK LOW EFF resolved by: Claude-JG OutputVariableConnector (#984)

    • description: check all penalty-based connectors if OutputVariable for forces is only computed if activeConnector=True

    • notes: An inactive RigidBodySpringDamper, LinearSpringDamper and TorsionalSpringDamper (activeConnector=False) reports zero force and torque in its output variables, as the other connectors do; test model inactiveConnectorForceTest.py.

    • date resolved: 2026-10-05 00:44, date raised: 2022-03-14

  • 1.12.320 CHECK MEDIUM EFF resolved by: Claude-JG allocation failure (#121)

    • description: assert that every allocation in Matrix, Vector, ResizableArray, … is performed with try/catch - compare Matrix::AllocateMemory(…)

    • notes: Every allocation of ResizableArray goes through one function that catches a failed allocation and raises an error with the size requested, as Vector and Matrix do.

    • date resolved: 2026-10-05 00:44, date raised: 2019-05-13

  • 1.12.305 TESTING NORMAL MEDIUM EFF resolved by: Claude-JG ANCFBeam (#1500)

    • description: check for advanced right-angle frame

    • notes: rightAngleFrame.py is the right-angle frame, driven past its buckling point (#2762); with ObjectANCFBeam the static solver stalls, which is #2763.

    • date resolved: 2026-10-04 23:09, date raised: 2023-04-08

  • 1.12.304 TESTING LOW EFF resolved by: Claude-JG ComputeLinearizedSystem (#1395)

    • description: add test model

    • notes: ComputeLinearizedSystem is tested by mainSystemExtensionsTests.py.

    • date resolved: 2026-10-04 23:09, date raised: 2023-01-12

  • 1.12.303 CHECK LOW EFF resolved by: Claude-JG ExplicitSolver (#1192)

    • description: Newton / startOfStep: check if dataCoords should also be copied

    • notes: Checked: all dynamic solvers, the explicit ones included, copy the whole current state - data coordinates included - into the start-of-step state at the beginning of each step.

    • date resolved: 2026-10-04 23:09, date raised: 2022-07-10

  • 1.12.302 TESTING LOW EFF resolved by: Claude-JG MarkerObjectODE2Coordinates (#613)

    • description: add simple test into TestModels

    • notes: MarkerObjectODE2Coordinates is tested by coordinateVectorConstraintGenericODE2.py.

    • date resolved: 2026-10-04 23:09, date raised: 2021-03-21

  • 1.12.301 CHECK MEDIUM EFF resolved by: Claude-JG SlimVector (#390)

    • description: check if erasing all <rule of 5> methods in SlimVector work and speed up code performance

    • notes: SlimVector: the copy and move constructors and assignments are the compiler’s defaults.

    • date resolved: 2026-10-04 23:09, date raised: 2020-05-16

  • 1.12.300 CHECK MEDIUM EFF resolved by: Claude-JG mass matrix update (#380)

    • description: mass matrix is not updated in Generalized Alpha solver in CSolverImplicitSecondOrderTimeInt::ComputeNewtonJacobian - may be critical for 3d rigid bodies

    • notes: Checked: when the mass matrix is not constant, the generalized-alpha solver computes it with every residual, so the Jacobian of a Newton iteration uses the mass matrix of that iterate; the derivative of the mass matrix times the accelerations is not in the Jacobian.

    • date resolved: 2026-10-04 23:09, date raised: 2020-05-06

  • 1.12.299 CHECK MEDIUM EFF resolved by: Claude-JG contact iteration (#209)

    • description: make simple example for contact to check changing jacobian matrices from ContactCoordinate

    • notes: contactComparisonTest.py drops a ball with ObjectContactCoordinate, implicit, whose Jacobian changes with the contact state, and compares it with three other contact implementations (#2749).

    • date resolved: 2026-10-04 23:09, date raised: 2019-06-28

  • 1.12.298 CHECK LOW EFF resolved by: Claude-JG ConstSizeVector (#124)

    • description: check if begin/end() overriding of Vector:: function is needed?

    • notes: Checked: ConstSizeVectorBase is not derived from VectorBase and holds its data in an array, so it needs its own begin() and end(); nothing to change.

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

  • 1.12.297 FIX MEDIUM EFF resolved by: Claude-JG GeneralContact (#1947)

    • description: check difference of friction force computation of SphereSphereContact (see notes in .cpp file) and GeneralContact

    • notes: GeneralContact with an implicit solver keeps the sliding or sticking state of a friction contact that its active set gives during the Newton iteration, as ObjectContactSphereSphere does; a sliding ball agrees with the rigid-body solution (contactComparisonTest.py).

    • date resolved: 2026-10-04 23:03, date raised: 2025-02-03

  • 1.12.296 FIX HIGH EFF resolved by: Claude-JG GeneralContact (#1848)

    • description: Test and improve implicit SPHERE-TRIG contact

    • notes: GeneralContact, implicit sphere-triangle contact, agrees with ObjectContactSphereSphere in a drop (contactComparisonTest.py) - to 1e-15 without damping; with damping it releases the ball when the contact force no longer presses (#2848).

    • date resolved: 2026-10-04 23:03, date raised: 2024-06-02

  • 1.12.294 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG SetDictionary of the settings takes a dictionary of Exudyn 1.11 (#2847)

    • description: A dictionary of simulation or visualization settings stored by Exudyn 1.11 (GetDictionary) uses the old names and structures - solutionSettings, linearSolverType, window, openGL.light0position, …; SetDictionary did not read those keys, and it required every key of the current structures. Revision2026b step RG12.34.7, raised by RG12.34 (#2813).

    • notes: SimulationSettings.SetDictionary and VisualizationSettings.SetDictionary take a dictionary stored by Exudyn 1.11, with the old names (solutionSettings, linearSolverType, window, …), and dictionaries with only some keys; keys not given keep their current values.

    • date resolved: 2026-10-04 21:00, date raised: 2026-10-04

  • 1.12.293 BUG HIGH MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the raytracer can hang in RedrawAndGetImage when tests run in parallel (#2776)

    • description: Twice on 2026-10-02 the full pytest run (pytest -n 8 python/testing) hung in test_graphicsRegression.py::testRaytracerImages, in SC.renderer.RedrawAndGetImage(useRaytracer=True) (faulthandler traceback), with all workers idle - a wait, not a loop; a third and fourth run passed, and 8 processes rendering the same images 15 times each in parallel did not hang. The raytracer starts the TaskManager for its ParallelFor (Raytracer::SoftwareRenderer, ExuThreading::EnterTaskManager) unless it is already running; a deadlock there, or a TaskManager left running by a previous test in the same worker, are the candidates. The hung processes stayed and could not be ended from the session.

    • notes: Fixed: a multithreaded solve (parallel.numberOfThreads > 1) that fails, e.g. because a user function raises, stops its worker threads and closes its files; before, the threads kept running, and a later multithreaded solve, the raytracer, or the end of the Python process could hang.

    • date resolved: 2026-10-04 20:49, date raised: 2026-10-02

  • 1.12.292 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectContactCurveCircles draws its points with a deprecated setting (#2846)

    • description: The points of the curve of ObjectContactCurveCircles are drawn with the deprecated visualizationSettings.connectors.contactPointsDefaultSize (0.02); the setting it is deprecated for is contact.contactPointsDefaultSize (0.001), which the other contacts use. Found with revision2026b step RG13.8.2; the maintainer, 2026-10-04: the change is ok.

    • notes: ObjectContactCurveCircles draws the points of its curve with visualizationSettings.contact.contactPointsDefaultSize (default 0.001), as the other contacts, instead of the deprecated connectors.contactPointsDefaultSize.

    • date resolved: 2026-10-04 20:27, date raised: 2026-10-04

  • 1.12.291 DOCU NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG the documentation says how each item is drawn and which settings it uses (#2840)

    • description: The maintainer, 2026-10-04: ‘the graphics visualization has no docs about how the items are drawn. Which (default) settings are used for tiling, colors, etc. - only available via the code. So, this should be completed and possibly improved if some misleading or inappropriate settings are used in the UpdateGraphics functions. This is mainly for the objects, but also for other items (but they would probably have a generic description for most nodes, markers, etc.).’ revision2026b step RG13.8.

    • notes: Every item page of the reference manual has a section Drawing: how the item is drawn, as all items of its kind and beyond, and the visualization settings that act on it, linked.

    • date resolved: 2026-10-04 19:22, date raised: 2026-10-04

  • 1.12.290 CHECK MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG Drawing parameters and settings that do nothing or something else than they say (#2843)

    • description: Found by the inventory of the drawing functions (tools/itemDrawingReport.py, docs/revision/itemDrawingState.md, revision2026b step RG13.8.1): (1) ObjectConnectorDistance.drawSize (‘link size’) is not read - the connector is a line; (2) ObjectConnectorGravity has show, drawSize (‘diameter of spring’) and color but no drawing; (3) ObjectConnectorCoordinateVector has show and color but no drawing; (4) 13 more items have show but draw nothing (Node1D, the generic nodes, ObjectGenericODE1, the coordinate markers, LoadCoordinate, SensorLoad, SensorUserFunction); (5) ObjectContactCurveCircles says its circles use circleTiling, the code uses general.cylinderTiling; (6) ObjectANCFThinPlate reads view0.scene.showMeshEdges when it builds its graphics data, a view setting the other items leave to the renderer; (7) a load with a Python user function is drawn with its user function only if general.useMultiThreadedRendering is False, a symbolic one always - nowhere said; (8) the line of a 3D beam without section geometry interpolates its contour colors over 0..L while it runs from -L/2 to L/2; (9) the tiling of connectors and joints mixes general.cylinderTiling, axesTiling, sphereTiling and circleTiling (circleTiling*4 for the contact circles, 4*cylinderTiling for rolling discs) without a rule. To decide per finding: draw, remove the parameter, or say what it does.

    • notes: Visualization: connectors.drawSimplified draws springs and ObjectConnectorDistance as lines (default) or as a tube and a rod of drawSize; ObjectConnectorGravity is drawn as a line between its markers if shown, its drawSize is removed; SensorLoad is drawn at the marker of its load; the parameter show of items that draw nothing (Node1D, generic nodes, ObjectGenericODE1, coordinate markers, LoadCoordinate, SensorUserFunction) and show/color of ObjectConnectorCoordinateVector are removed - exudev scripts finds them in a script; ObjectContactCurveCircles draws circles with circleTiling.

    • date resolved: 2026-10-04 17:51, date raised: 2026-10-04

  • 1.12.289 IMPROVEMENT NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG ObjectKinematicTree computes directly with homogeneous transformations (#2829)

    • description: The maintainer, 2026-10-04: ‘check the main relevant functions in KinematicTree (I suppose ComputeTreeTransformations and ComputeMassMatrixAndODE2LHS); make two local implementations in C++, with a exudyn.experimental switch for the testing. Probably, the evaluations need to be slightly adjusted, as the Featherstone version uses an inverse of the HTs. Most functions like Translation2T66 are just wrappers that did the T66 and the HT path, but with an optimized version just with the HTs, it should be easier to implement and faster. If comparison shows that the new path with HTs works, the old T66 functions could mostly go; probably some 6D motion and force computations will stay - possibly in a more suitable/faster form.’ revision2026b step RG16.13.6 to RG16.13.9.

    • notes: ObjectKinematicTree computes its kinematics, mass matrix and forces on the placements of its links (homogeneous transformations); the results agree with the earlier computation to round-off, about 25% faster for small trees.

    • date resolved: 2026-10-04 17:15, date raised: 2026-10-04

  • 1.12.288 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectKinematicTree.forceUserFunction receives no velocities (#2845)

    • description: The forceUserFunction(mbs, t, itemNumber, q, q_t) of ObjectKinematicTree is called with tempVector2 as q_t, which nothing fills: the function receives an empty list (or a stale one) instead of the joint velocities. No example or test model uses this user function. Found while moving the joint forces into one function for both paths of revision2026b step RG16.13.7.

    • notes: Fixed: the forceUserFunction of ObjectKinematicTree receives the joint velocities q_t; it received an empty vector.

    • date resolved: 2026-10-04 16:55, date raised: 2026-10-04

  • 1.12.287 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG The raytracer draws no GraphicsData Circle (#2844)

    • description: GraphicsData of type ‘Circle’ (graphics.Circle, and the circles that 2D items draw with AddCircleXY: the 2D joints, contact circles, slope nodes) are drawn by OpenGL but not by the raytracer: Raytracing.cpp converts lines, quadratic lines, triangles, spheres and texts, not glCircles. Found with the GraphicsData example of the user manual as notebook (revision2026b step RG17.5).

    • notes: Fixed: the raytracer draws GraphicsData circles (graphics.Circle) and the circles of 2D items such as joints and contact circles, as lines.

    • date resolved: 2026-10-04 16:39, date raised: 2026-10-04

  • 1.12.286 EXTENSION NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG tutorials as Jupyter notebooks: build, test and the first notebook (#2831)

    • description: The realization of the evaluation of revision2026b step RG17.1 (#2811): notebooks without stored outputs, rendered by myst-nb in the documentation, run by runTestExamples.py, images of the scene with the raytracer; the first notebook is rigidBodyTutorial3 with exu.HT (RG16.12.5). revision2026b step RG17.2.

    • notes: Done: the tutorials (python/Notebooks/), the examples of the reference manual (python/Notebooks/reference/) and of the user manual pages on graphics, solving and the renderer (python/Notebooks/snippets/) are notebooks with stored outputs; the documentation shows them with what they printed, and the tests run them.

    • date resolved: 2026-10-04 16:11, date raised: 2026-10-04

  • 1.12.285 BUG HIGH MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG SystemContainer.AppendSystem of a MainSystem that Python owns crashes at the end (#2842)

    • description: SC.AppendSystem(mbsCopy) with mbsCopy = copy.copy(mbs) - the example ‘Copying and referencing C++ objects’ of the reference manual - ends in an access violation when SC is deleted or the interpreter exits: AppendMainSystem stores the pointer and MainSystemContainer::Reset() deletes every MainSystem it holds, while the copy made by pickle belongs to its Python object, which deletes it again; deleting mbsCopy before SC leaves a dangling pointer in SC. The same holds for a MainSystem appended to a second container (simulatorCouplingTwoMbs.py). Needs an ownership rule: the container deletes only the systems it created (AddSystem), and AppendSystem keeps the appended one alive (keep_alive) and unlinks it in Reset. Found by running the examples of the reference manual as notebooks, revision2026b step RG17.4.

    • notes: Fixed: SC.AppendSystem(mbs) with a copy of a system (copy.copy) or the system of another container no longer crashes Python when the container is deleted: the container keeps an appended system alive but does not delete it, and SC.Reset() leaves it to its owner.

    • date resolved: 2026-10-04 15:51, date raised: 2026-10-04

  • 1.12.284 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG curves of connectors drawn with a tiling of their own, as watertight tubes (#2839)

    • description: The maintainer, 2026-10-04: ‘CObjectConnectorReevingSystemSprings: graphics uses nTile = visualizationSettings.general.cylinderTiling, which is wrong; first: the nTiles should depend on the angle; second: it should be a new SC.visualizationSettings.connectors.curveTiling or a similar name, which should also be used by windings resolution in spring-dampers. And we need a function to draw watertight curves along a line, which could be used then both for the reeving system and the spring windings (if drawn in 3D - with a new flag).’ revision2026b step RG6.9.

    • notes: Springs and the rope of ObjectConnectorReevingSystemSprings are drawn with visualizationSettings.connectors.curveTiling segments per full turn (the arc of a rope with the share of its angle); connectors.springDraw3D draws the windings of springs as a tube; the rope is one closed tube along its spans and arcs.

    • date resolved: 2026-10-04 15:20, date raised: 2026-10-04

  • 1.12.283 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG a 3D beam without section geometry is drawn with a coordinate frame at every tile (#2837)

    • description: UpdateGraphicsBeam3D (ObjectBeamGeometricallyExact, ObjectANCFBeam) draws a beam without polygonal section geometry as a line - and, marked ‘temporary!’ in the code, an orthonormal basis of size nodes.basisSize at each of the axialTiling points, also when nodes are not shown. Found with the item images of revision2026b step RG3.31: the default drawing of a beam is a row of arrows. The basis belongs to a setting (or goes), not to every line-drawn beam.

    • notes: Fixed: a 3D beam (ObjectANCFBeam, ObjectBeamGeometricallyExact) without section geometry is drawn as a line; it no longer draws a coordinate frame at every tiling point. The frames are those of its nodes (visualizationSettings.nodes.showBasis).

    • date resolved: 2026-10-04 15:01, date raised: 2026-10-04

  • 1.12.282 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG SystemContainer.Append is documented, the function is AppendSystem (#2841)

    • description: The reference manual (pybindSystemContainer.py, the MainSystem introduction and the copy example of the general information) and two error messages of CSystem.cpp and MainSystem.cpp tell to call SC.Append(mbs); the SystemContainer has no Append - its function is AppendSystem (PybindModule.cpp), which simulatorCouplingTwoMbs.py uses. Found by running the examples of the reference manual as notebooks, revision2026b step RG17.4.

    • notes: Fixed: the reference manual (SystemContainer, the MainSystem introduction, the copy example) and the error messages of CSystem.cpp and MainSystem.cpp name SC.AppendSystem(mbs), the function the SystemContainer has.

    • date resolved: 2026-10-04 14:48, date raised: 2026-10-04

  • 1.12.281 EXAMPLE NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG examples and test models that show referenceHT, localHT and exu.HT (#2823)

    • description: The maintainer, 2026-10-04: ‘referenceHT, localHT, etc. is rarely used’; ‘a couple of examples and test models (like 4+4) should use referenceHT / localHT, just to show how it works and for the tests’ - solutionViewerTest.py, rigidBodyTutorial3.py (better as Jupyter tutorial, RG17), and ‘a pure prestepuserfunction example showing 4 bodies transformed with the InterpolateSE3/SO3 features, writing the transformations into the renderer (with the solution information string)’. revision2026b step RG16.12. [2026-10-03, Claude-JG]: Done 2026-10-04: the example homogeneousTransformationInterpolation.py (RG16.12.1) and solutionViewerTest.py on exu.HT with referenceHT and localHT (RG16.12.2); open: two examples, four test models, rigidBodyTutorial3 as notebook (RG16.12.3 to .5).

    • notes: Done: the notebook tutorialRigidBodyCreate (python/Notebooks/) replaces rigidBodyTutorial3.py; it names referenceHT and shows the frame of a body as exu.HT, together with the examples and test models of revision2026b step RG16.12.

    • date resolved: 2026-10-04 14:30, date raised: 2026-10-03

  • 1.12.280 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG GenerateBeamElementsAlongLine fails without nodeNumberStart and nodeNumberEnd (#2838)

    • description: beams.GenerateBeamElementsAlongLine, the function that replaces the deprecated GenerateStraightBeam, passed its defaults nodeNumberStart=None and nodeNumberEnd=None to GenerateStraightBeam, which takes -1 for no node: every call without them raised ‘failed to convert to NodeIndex, but received None’; it also warned that GenerateStraightBeam is deprecated. Found with the flexible beams tutorial notebook (revision2026b step RG17.2). Now None is passed as -1 and the implementation is called without the warning.

    • notes: beams.GenerateBeamElementsAlongLine works without nodeNumberStart and nodeNumberEnd and no longer warns about the deprecated function it uses.

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

  • 1.12.279 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG representative images for the item pages that lack one (#2830)

    • description: The maintainer, 2026-10-04: ‘I think that most of them are too difficult to do them automatically. Suggestion: check which items (mostly bodies, loads, joints) would make sense to have a representative image - and which ones do not yet have one … add a couple of images, some maybe from a Testmodel or within 1-2 scripts that are hand-made and which extract the images for the missing cases … use the non-simplified drawing modes for springs, basis vectors, etc.; extract images with raytracer and try to adjust them yourself.’ Replaces RG2.3.3.7, an automatic image per item. revision2026b step RG3.31.

    • notes: 23 item pages show a representative image of the item, drawn by the raytracer: the ground, mass point, planar rigid body, kinematic tree, beams, thin plate, FFRF body, the loads, spring-dampers, distance constraint, reeving system, rolling discs, planar joints, sphere contact and the rigid body marker.

    • date resolved: 2026-10-04 11:15, date raised: 2026-10-04

  • 1.12.278 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG PlotSensor fails for data given as numpy array when an output directory is set (#2836)

    • description: mbs.PlotSensor(sensorNumbers=[data]) with a numpy matrix raised ‘The truth value of an array with more than one element is ambiguous’ when exudyn.config.outputDirectory is set (EXUDYN_OUTPUTDIRECTORY, as the runners and the notebook runner do): the array was passed to OutputFilePath as if it were a file name. Found with the first tutorial notebook (revision2026b step RG17.2). Data given as array is now taken as it is.

    • notes: PlotSensor plots data given as numpy array also when an output directory is set (exudyn.config.outputDirectory).

    • date resolved: 2026-10-04 10:55, date raised: 2026-10-04

  • 1.12.277 DOCU LOW LOW EFF raised by: Claude-JG resolved by: Claude-JG the start page of the documentation talks about how the documentation is made (#2835)

    • description: Feedback of a colleague installing Exudyn, forwarded by the maintainer 2026-10-04: ‘The text This page is the table of contents, and it is hand-written … in index.html reads strange => remove.’ Root cause: a note for maintainers on a page for readers. Removed there; the information is in the repository layout of docs/dev/README.md. revision2026b step RG3.33.

    • notes: The start page of the documentation no longer explains how the documentation is made.

    • date resolved: 2026-10-04 10:36, date raised: 2026-10-04

  • 1.12.276 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG aligned formulas break in the HTML pages: begin{aligned} ended with end{split} (#2834)

    • description: Feedback of a colleague installing Exudyn, forwarded by the maintainer 2026-10-04: ‘In the html doc, sometimes \begin{aligned} ended with \end{split} occurs (e.g. ObjectRigidBody). This should be fixed globally.’ Cause: Sphinx splits a display formula at a blank line into separate equations, each wrapped in split, which tears an aligned environment apart; the blank lines came from LaTeX comment lines (‘%’) inside the formulas of the definitions, which the converter emptied but did not remove (4 item pages), and from blank lines in docs/manual/solver.md (7 formulas). The converter removes such lines; checkMathMacros –check refuses a blank line inside display math. revision2026b step RG3.32.

    • notes: Aligned formulas in the HTML documentation no longer break apart (begin{aligned} ended with end{split}).

    • date resolved: 2026-10-04 10:36, date raised: 2026-10-04

  • 1.12.275 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev env stops at the first environment of the version matrix that a developer does not have (#2833)

    • description: Feedback of a colleague installing Exudyn, forwarded by the maintainer 2026-10-04: ‘exudev env error message: the conda environment venvP310 does not exist. It searches for all packages of the python matrix for a complete build - not required by a developer that does not do the release-runs and tests. Only for a complete build, different venvs for different Python versions shall be required.’ Without –py or –env, exudev env now probes the environments that exist and names the missing ones of the matrix as needed only for build –complete. revision2026b step RG10.15.

    • notes: exudev env no longer requires the environments of the whole Python version matrix; they are needed only for exudev build –complete.

    • date resolved: 2026-10-04 10:36, date raised: 2026-10-04

  • 1.12.274 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the test suite fails without matplotlib instead of saying what to install (#2832)

    • description: Feedback of a colleague installing Exudyn, forwarded by the maintainer 2026-10-04: ‘The test-suite needs matplotlib to be installed; otherwise, it fails. Should it be like that?’ Measured with matplotlib blocked: 9 test models failed - eight plot (PlotSensor, matplotlib.pyplot) after or instead of computing their result, and allExudynModulesTest failed because exudyn.misc.resultsMonitor imported matplotlib at module level. matplotlib is optional (rule 6), part of the [tests] extra. Now: resultsMonitor imports it when it is there and says so when the monitor is started without it; a test model that fails for a missing package of the [tests] extra is SKIPPED, listed at the end with ‘pip install exudyn[tests]’, and does not fail the run - unless it computed its result before, then it is judged as usual. revision2026b step RG2.5.

    • notes: The test suite runs without matplotlib and the other packages of the [tests] extra: a test model that needs a missing one is skipped and listed with pip install exudyn[tests].

    • date resolved: 2026-10-04 10:36, date raised: 2026-10-04

  • 1.12.273 CHANGE NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the unused 6x6 Pluecker matrices of the kinematic tree are removed (#2828)

    • description: The maintainer, 2026-10-04: ‘the kinematic tree uses the C++ HT, it is a typedef in KinematicsBasics.h … first remove the unused T66 Pluecker transformations (inside #ifndef USE_EFFICIENT_TRANSFORMATION66 …)’. USE_EFFICIENT_TRANSFORMATION66 was always defined, so Transformation66 is HomogeneousTransformation and the 300 lines of Matrix6D implementations were never compiled. revision2026b step RG16.13.5.

    • notes: The unused 6x6 Pluecker matrix implementation of the kinematic tree was removed; the tree computes with homogeneous transformations.

    • date resolved: 2026-10-04 00:48, date raised: 2026-10-04

  • 1.12.272 CHANGE NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG the robotics classes use exu.HT instead of the 4x4 numpy arrays of rigidBodyUtilities (#2821)

    • description: The maintainer, 2026-10-04: ‘the robotics.Robot class (and the related classes) still use the Python HomogeneousTransformation’, and the examples using the Robot class. Robot, RobotLink, RobotBase, RobotTool, the DH conversions, LinkHT/JointHT/COMHT, the inverse kinematics and robotics.models/mobile/special/future work on numpy 4x4 arrays and HTtranslate/HTrotate; a user gives HT=HTtranslate(…). The transition keeps scripts working that give numpy arrays. revision2026b step RG16.10.

    • notes: The robotics classes compute with exu.HT; the HT helpers of rigidBodyUtilities are kept as numpy helpers.

    • date resolved: 2026-10-04 00:48, date raised: 2026-10-03

  • 1.12.270 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG CreateKinematicTree fails when a link with automatic graphics has no offset (#2827)

    • description: mbs.CreateKinematicTree with automatic graphics (graphicsDataList=None of the parent, or the base graphics) raised UnboundLocalError: gLink, or added the graphics of an earlier link again, when the jointHT of a link has zero translation: the link graphics was created only for a translation of some length, but appended in any case. Found with the measurement of revision2026b step RG16.13.2 (a tree whose first link is at the base). The append moved into the branch that creates it.

    • notes: mbs.CreateKinematicTree with automatic graphics no longer fails for a link whose jointHT has no translation.

    • date resolved: 2026-10-03 23:23, date raised: 2026-10-03

  • 1.12.269 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the functions added to MainSystem have return annotations (#2826)

    • description: The maintainer, 2026-10-04, choosing option (a) of #2825: add a step to add return annotations for the Create functions. Since #2825 the stub assigns the Python functions to MainSystem, so a type checker and an editor take their signature from the functions themselves; the return types that the copied stub had (ObjectIndex, NodeIndex, dict for returnDict=True, …) must therefore be annotations of the functions: the 25 Create functions and the other functions added to MainSystem (SolveDynamic, SolveStatic, PlotSensor, SolutionViewer, ComputeLinearizedSystem, …). revision2026b step RG12.38.

    • notes: The functions added to MainSystem (Create functions, solvers, PlotSensor, …) have return annotations, so that editors and type checkers know what they return.

    • date resolved: 2026-10-03 23:23, date raised: 2026-10-03

  • 1.12.268 EXTENSION NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG ObjectKinematicTree takes its joints as jointHTs (#2824)

    • description: The maintainer, 2026-10-04: ‘ObjectKinematicTree still has only jointTransformations and jointOffsets, but I believe that jointHTs would be much more convenient and could also boost the internal computations (?). Put there a step in the plan with substeps to suggest a transition to jointHTs, like adapting the CreateKinematicTree function, requiring a HTList (similar to Vector3DList) for the C++ interface, adapting the C++ implementation, also adapting the TreeLink to exudyn.HT’. revision2026b step RG16.13.

    • notes: mbs.CreateKinematicTree passes jointHTs and TreeLink.jointHT is an exu.HT; exu.HT(H) copies an HT; storing the joint HTs in ObjectKinematicTree was measured and brings no gain, so the two lists stay with jointHTs as their view.

    • date resolved: 2026-10-03 23:23, date raised: 2026-10-03

  • 1.12.267 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG go to definition of mbs.CreateRigidBody reaches the Python function, not only the stub (#2825)

    • description: The maintainer, 2026-10-04: ‘The Create… functions are injected into MainSystem, thus the direct navigation to these functions is not possible. If I use spyder or VS Code and I click on CreateRigidBody, it directs me to the .pyi file. Is there a fix for that?’ The stub declares each added function as a method of MainSystem with its own copy of the signature and the first sentence of the docstring; the function itself is MainSystemCreateRigidBody in exudyn/misc/mainSystemExtensions.py. revision2026b step RG16.14. [2026-10-03, Claude-JG]: The step is revision2026b step RG12.37, not RG16.14 (it is not about the HT). Tried on a copy of the package with jedi 0.20 and mypy: (a) CreateRigidBody = _MainSystemCreateRigidBody in the stub - mypy types it from the function, jedi’s go to definition lands on that stub line and its inference reaches the source; (b) a class-scoped import in the stub - jedi goes straight to the source, mypy refuses it; (c) the stub docstring names the function. Recommended (a) with return annotations on the functions; the maintainer decides after a look in VS Code.

    • notes: Go to definition of mbs.CreateRigidBody and the other functions added to MainSystem reaches the Python function: the stub assigns the function itself, and type checkers take its signature from it.

    • date resolved: 2026-10-03 22:27, date raised: 2026-10-03

  • 1.12.266 CHANGE NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG examples and test models use exu.HT instead of the HT functions of rigidBodyUtilities (#2822)

    • description: The maintainer, 2026-10-04: ‘whenever rigidbody transformations are used - in particular with kinematic trees and with more complicated kinematics, the exudyn.HT feature should be used’. 23 examples, 20 test models and the library modules graphics, plot and lieGroupBasics call HomogeneousTransformation, HTtranslate, HTrotateX/Y/Z, HT2translation, HT2rotationMatrix, InverseHT or HT0; a test model whose result shall stay exactly the same is converted only where the numbers do not change. revision2026b step RG16.11.

    • notes: Examples and test models that build the frame of a marker give its localHT with exu.HT.

    • date resolved: 2026-10-03 22:27, date raised: 2026-10-03

  • 1.12.265 CHANGE NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the library builds the frames of markers with exu.HT, and the Create functions no longer pass rotationMarker0/1 (#2820)

    • description: The maintainer, 2026-10-04: ‘ObjectJointPrismaticX.py uses localHT, but uses HomogeneousTransformation from rigidBodyUtilities, not the exudyn function => check whether other scripts / files in the library use HomogeneousTransformation’; ‘robotics.CreateRedundantCoordinateMBS uses rotationMarker; CreateFunctions still use rotationMarker’. Since #2804 the rotation of a joint is in its markers’ localHT, and the Create functions pass a unit rotationMarker0/1 - the deprecated parameter, which a reader of the library takes as the way to do it. The library and the definitions (MiniExamples, the advice of the deprecated rotationMarker parameters) build the localHT with exu.HT. revision2026b step RG16.9.

    • notes: The Create functions and robotics.Robot.CreateRedundantCoordinateMBS give the rotation of a joint to its markers only (localHT built with exu.HT) and no longer pass rotationMarker0/1.

    • date resolved: 2026-10-03 21:19, date raised: 2026-10-03

  • 1.12.264 EXTENSION NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG exu.HT offers the logarithm and the exponential map on SE(3) and R3xSO(3) (#2819)

    • description: The maintainer, 2026-10-04: ‘exudyn.HT misses the LogSE3/R3xSO3 as well as the according Exp features; they are all in the C++ core and it would be nice to have them directly available.’ LogSE3() and LogR3xSO3() give the 6 components [U, Omega] of the motion vector, SetExpSE3(v) and SetExpR3xSO3(v) set the HT from it and return it, as the other Set functions do (RG16.6). On EXUlie::LogSE3Vector, ExpSE3 and ExpSO3 of RigidBodyMath.h. revision2026b step RG16.8.

    • notes: exu.HT gives and takes the logarithm and exponential map: LogSE3() and SetExpSE3(v) for the motion vector of a screw motion, LogR3xSO3() and SetExpR3xSO3(v) for the translation and the rotation vector.

    • date resolved: 2026-10-03 21:19, date raised: 2026-10-03

  • 1.12.263 FIX LOW LOW EFF raised by: Claude-JG resolved by: Claude-JG LoadBinarySolutionFile prints verbose= on every call (#2818)

    • description: basicUtilities.LoadBinarySolutionFile prints ‘verbose=’ and the value unconditionally - a debug line left in. Found with binarySolutionFileTest.py (RG12.34).

    • notes: LoadBinarySolutionFile no longer prints verbose= on every call.

    • date resolved: 2026-10-03 20:55, date raised: 2026-10-03

  • 1.12.262 IMPROVEMENT NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG mbs.Inspect answers the node types a node marker requests, and Assemble checks them from the declaration (#2817)

    • description: The node types a node marker requests (Position or Position2D, Orientation or Orientation2D) were checked by hand-written C++ in CSystem::CheckSystemIntegrity and declared separately as requestedNodeTypes in the definitions, for the documentation only; mbs.Inspect did not answer them. Now the declaration generates MainMarker::GetRequestedNodeTypes(), Assemble checks it, and mbs.Inspect(marker, InspectType.RequestedNodeTypes) returns it - per node a list of requirements, each a list of alternatives. revision2026b step RG12.29.2.

    • notes: mbs.Inspect(marker, InspectType.RequestedNodeTypes) answers the node types a node marker requests, as requirements each a list of alternatives; Assemble checks them from the same declaration.

    • date resolved: 2026-10-03 20:55, date raised: 2026-10-03

  • 1.12.261 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the binary solution file takes the size of its numbers from solution.precision (#2816)

    • description: The binary solution file wrote float or double depending on the console precision (consolePrecision, before 1.13 outputPrecision), while the description of solution.file.binary says solution.precision. The maintainer (2026-10-04): use solution.precision - below 8 float, otherwise double. The examples that set solution.precision = 6 for a float file (ANCFcableCantilevered, ANCFslidingJoint) now get one; no script relied on the console precision for it. Test model binarySolutionFileTest.py. revision2026b step RG12.34.

    • notes: The binary solution file stores float if solution.precision is below 8 and double otherwise, as its description says; before, the console precision decided.

    • date resolved: 2026-10-03 20:55, date raised: 2026-10-03

  • 1.12.260 IMPROVEMENT HIGH EFF raised by: Claude-JG resolved by: Claude-JG two Newton structures for time integration and static solver, with the modified Newton by default in the time integration (#2815)

    • description: NewtonSettings is shared; with the forwarding of RG12.1 two structures are possible, most members copied, each with its own defaults - useModifiedNewton=True for the time integration; the test suite has to be evaluated again (maintainer 2026-10-04).

    • notes: The time integration uses the modified Newton method by default: timeIntegration.newton.useModifiedNewton is True, much faster for most models; results change within the Newton tolerances. staticSolver.newton keeps the full Newton method.

    • date resolved: 2026-10-03 20:55, date raised: 2026-10-03

  • 1.12.259 CHANGE HIGH EFF raised by: Claude-JG resolved by: Claude-JG item parameters renamed as decided in RG12.31: the prefix physics dropped, the friction forces, use… flags (#2814)

    • description: physicsMass -> mass and 26 more, sphereRadius, dynamicFrictionForce/staticFrictionOffsetForce/viscousFrictionForce, factor1, rollingViscousFriction, useIntrinsicFormulation, useClassicalFormulation; the old names forward until 2031; C++, library, scripts, documentation and tests follow (maintainer 2026-10-03).

    • notes: the item parameters of bodies and finite elements lost their prefix physics (physicsMass is mass, …), and sphereRadius, the friction forces of CoordinateSpringDamperExt, factor1, rollingViscousFriction, useIntrinsicFormulation and useClassicalFormulation are renamed; every old name still works with a warning until 2031, and exudev scripts –fix rewrites a script

    • date resolved: 2026-10-03 18:44, date raised: 2026-10-03

  • 1.12.258 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG settings and item parameters that could be renamed or restructured, for the maintainer’s decision (#2802)

    • description: maintainer 2026-10-03: search simulation settings and item parameter names that could be renamed or restructured; listed as revision2026b step RG12.31 for decision.

    • notes: the settings and item parameters that could be renamed were listed and decided; realized in #2813 and #2814

    • date resolved: 2026-10-03 18:44, date raised: 2026-10-03

  • 1.12.257 CHANGE HIGH EFF raised by: Claude-JG resolved by: Claude-JG simulationSettings renamed and restructured as decided in RG12.31, with every change the deprecation needs (#2813)

    • description: No substructure ends in Settings (solution, linearSolver), solution.file/.sensors/.restart, show.*, timeIntegration.realtime and .solverType, newton.active/.residualMode, camel case fixes; the old names forward until 2031; C++, library, scripts (exudev scripts –fix), documentation and tests follow (maintainer 2026-10-03).

    • notes: the simulation settings are reordered - solution.file, solution.sensors, solution.restart, linearSolver, show, timeIntegration.solverType, explicit and realtime, newton.active and residualMode; every old name still works with a warning until 2031, and exudev scripts –fix rewrites a script to the new names

    • date resolved: 2026-10-03 18:03, date raised: 2026-10-03

  • 1.12.256 DOCU MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the flow charts of the documentation as TikZ again: vector graphics in the PDF, images on the web (#2812)

    • description: The mermaid charts of introduction.md, solver.md and theoryContact.md are of low quality compared to the TikZ figures of the old LaTeX documentation (tmp/oldDocs/theDoc): arrows, colors, fonts, and they did not fit the page. Keep the current content of the charts, draw them in TikZ again: one small standalone .tex per figure, compiled only when a figure changes (an exudev command, needs LaTeX), giving a PDF for the PDF build and an image for the web (maintainer 2026-10-03).

    • notes: the flow charts of the documentation are TikZ again: vector graphics in the PDF and SVG on the web, compiled by exudev figures when a chart changes

    • date resolved: 2026-10-03 16:38, date raised: 2026-10-03

  • 1.12.255 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG exu.HT: the functions of the accepted proposal, with examples in its documentation and tests (#2810)

    • description: Realization of the HT proposal: the bindings on the existing C++ conversions, examples in the data structures section (rotation, position, the node coordinates), a test model.

    • notes: exu.HT converts from and to Euler parameters, Tait-Bryan angles, rotation vector and the coordinates of the rigid body nodes, gives Relative, InterpolateSO3, InterpolateSE3, RotationAngle and RotationAxis; its Set functions return it

    • date resolved: 2026-10-03 15:51, date raised: 2026-10-03

  • 1.12.254 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG exu.HT as the place for rigid body transformations: a proposal for its functions and names (#2809)

    • description: The coordinates of the rigid body nodes from and to an HT (position with Euler parameters, Tait-Bryan angles Rxyz or rotation vector), more functions that nodes, markers and items need, and the names of the class (translation or position) - for the maintainer’s decision (2026-10-03).

    • notes: decided: exu.HT keeps translation; node coordinates, Relative, InterpolateSO3/SE3, angle and axis, chained Set functions

    • date resolved: 2026-10-03 15:51, date raised: 2026-10-03

  • 1.12.253 IMPROVEMENT MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG deprecations of the Python library declared like those of the C++, and a build check for expired ones (#2807)

    • description: The Python library deprecates functions and arguments by hand - a docstring saying DEPRECATED, an exu.Print(‘WARNING: …’), about 20 places (AddRevoluteJoint, bodyList of the Create functions, GeneticOptimization arguments, …) - with no version, no year of removal and nothing that finds them. Proposal: one declaration with since and expires for every deprecation, the library warning through exudyn.special.deprecations, and a check in exudev generate –all-checks that lists all deprecations and fails for one past its year (maintainer 2026-10-03).

    • notes: the deprecated functions and arguments of the Python library warn once per session at the line of the script and are counted in exudyn.sys[‘deprecationUse’][‘library’]; every deprecation of Exudyn has a year of removal, and a build check fails once it has come

    • date resolved: 2026-10-03 15:06, date raised: 2026-10-03

  • 1.12.252 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG Python-C++ command interface: the Exudyn module page in sections, the persisted settings a manual page, the environment variables a page of their own (#2808)

    • description: The module page had one section with every member; its groups (config, experimental, special and its parts, variables and sys) become sections from the definitions. The settings that persist between runs, with the plot windows of PlotSensor, move to the manual page userSettings.md; the environment variables become the last page of the chapter, after the type definitions (maintainer 2026-10-03).

    • notes: the Exudyn module page has a section per group of members; the settings that persist between runs are a page of the user manual, the environment variables the last page of the Python-C++ command interface

    • date resolved: 2026-10-03 14:37, date raised: 2026-10-03

  • 1.12.251 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG every use of a deprecated name is recorded in exudyn.sys[‘deprecationUse’] (#2806)

    • description: Grouped by source - simulationSettings, visualizationSettings, items, functions - with a count per name; always written, a flag in exudyn.special.deprecations turns it off. A test or a user sees whether a script used anything deprecated without catching warnings (maintainer 2026-10-03).

    • notes: every use of a deprecated name is counted in exu.sys[‘deprecationUse’], by source and name; exu.special.deprecations.recordUse = False turns it off

    • date resolved: 2026-10-03 13:55, date raised: 2026-10-03

  • 1.12.250 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev scripts reports deprecated item parameters (#2805)

    • description: checkUserScripts reads the deprecated settings and functions from definitions/, but not the deprecated item parameters: the renames of RG12.2 and the deprecated rotationMarker0/1 of the joints and connectors, given as keyword of an item class or as key of an item dictionary.

    • notes: exudev scripts reports deprecated and removed item parameters, as keyword of the item class and as key of an item dictionary

    • date resolved: 2026-10-03 13:55, date raised: 2026-10-03

  • 1.12.249 IMPROVEMENT MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG deprecation warnings where the user writes the deprecated name, switched in exudyn.special (#2804)

    • description: A deprecated item parameter (rotationMarker0/1) warns at Assemble today, so the warning points at mbs.Assemble() and not at the line that wrote it. Proposal: warn in the item class (itemInterface) and in the dictionary path, declared in definitions/, with one switch in exudyn.special for once per session or always (debugging).

    • notes: a deprecated setting, item parameter or function warns once per session and name, at the line of the script that uses it; exu.special.deprecations.warnOnce = False shows every use

    • date resolved: 2026-10-03 13:55, date raised: 2026-10-03

  • 1.12.248 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectContactCurveCircles: rotationMarker0 removed (#2803)

    • description: The parameter was never applied to the contact, only to the drawing, and Assemble refused any value other than the unit matrix; the frame of the curve is the frame of marker 0, which takes a rotation as localHT. Removed without deprecation (maintainer 2026-10-03).

    • notes: ObjectContactCurveCircles has no rotationMarker0 any more: it was used only for drawing, and Assemble refused any value other than the unit matrix; the curve lies in the frame of marker 0, which takes a rotation as localHT

    • date resolved: 2026-10-03 13:06, date raised: 2026-10-03

  • 1.12.247 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectConnectorRigidBodySpringDamper multiplies rotationMarker0 from the wrong side (#2801)

    • description: found in revision2026b step RG14.2.15: the connector computes A0all = rotationMarker0*A0, its documentation, CreateRigidBodySpringDamper (MR0 = A0^T R) and all other joints use A0*rotationMarker0; a rotationMarker0 different from the unit matrix on a rotated marker 0 gave the wrong frame.

    • notes: ObjectConnectorRigidBodySpringDamper applies rotationMarker0 after the frame of marker 0, as the joints do and as documented; models with a rotationMarker0 other than the unit matrix move differently

    • date resolved: 2026-10-03 11:25, date raised: 2026-10-03

  • 1.12.246 CHANGE LOW EFF raised by: Claude-JG resolved by: Claude-JG parallel.multithreadedLowerLimit… instead of multithreadedLimit… (#2800)

    • description: maintainer 2026-10-03, after revision2026b step RG12.1: the double L of multithreadedLLimit… meant lower limit; the settings are multithreadedLowerLimitLoads, …Residuals, …Jacobians, …MassMatrices; the old LLimit names forward until 2031.

    • notes: parallel.multithreadedLowerLimitLoads, …Residuals, …Jacobians, …MassMatrices; the old multithreadedLLimit names forward with a DeprecationWarning until 2031

    • date resolved: 2026-10-03 11:25, date raised: 2026-10-03

  • 1.12.245 EXTENSION NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG item parameters cannot be deprecated (#2589)

    • description: When an item parameter is renamed there is no path that keeps an old script working: unlike visualizationSettings, the item interfaces have no deprecation mechanism. Wanted (maintainer, 2026-09-22): the same feature for item parameters, either restricted to the classes of itemInterface.py - which is generated, so one place - or extended to the Get/Set functions of the items themselves. If it reaches the C++ side, the deprecated names must be searched LAST, so that the common case pays nothing.

    • notes: An item parameter can be renamed with its old name kept: it is still taken in the item class, in a dictionary and by GetObjectParameter/SetObjectParameter, with a DeprecationWarning naming the new one.

    • date resolved: 2026-10-03 09:59, date raised: 2026-09-22

  • 1.12.244 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG simulationSettings has no deprecation mechanism (#2588)

    • description: A member of visualizationSettings can be marked deprecated in the definitions - Deprecated(since, expires) plus the SFDeprecated flag, 93 members carry it today - and a user who sets the old name gets a message that names the new one. simulationSettings uses none of it, although the mechanism is the same generator and the same structure machinery: a renamed solver setting simply disappears. Apply it there.

    • notes: simulationSettings members can be renamed or moved with the old name kept as deprecated, forwarding with a DeprecationWarning; parallel.multithreadedLLimit… are parallel.multithreadedLimit… now.

    • date resolved: 2026-10-03 09:41, date raised: 2026-09-22

  • 1.12.243 CHANGE NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG access functions: single functions per access type in the objects, with precise interfaces (#2744)

    • description: The maintainer, 2026-09-29: GetAccessFunctionBody(AccessFunctionType, localPosition, Matrix& value) serves every access type through one function and a switch, with workarounds (e.g. the vector for JacobianTtimesVector_q passed in the output matrix). Revise into single functions per access type in the objects, with interfaces that say what they take and return. First: which objects need which access functions and what would be best for them. Then possibly a check that the declared access function flags (ItemAccessFunctionTypes) and the functions a definition declares agree. revision2026b step RG9.3.

    • notes: The access function types of an object are derived from the access functions it provides; AccessFunctionType.SuperElementAlternativeRotationMode is removed, the mode is an argument of the super element access function.

    • date resolved: 2026-10-03 08:16, date raised: 2026-09-29

  • 1.12.242 CHECK raised by: Claude-JG resolved by: Claude-JG fourteen figure files in docs/figures are referenced by nothing (#2594)

    • description: Twelve .pdf and two .eps files in docs/figures/ are referenced by no page, no definition and no tool: CommonTangents3D.eps, DrawSystemGraphExample.pdf, RotationAxisAngle.pdf, RotationAxisAngleDerivation.pdf, degrees_of_freedom.pdf, elementaryRotationX.pdf, elementaryRotationY.pdf, generalContactANCF2Dcircle.pdf, generalContactSpheres.pdf, open_closed_loop.pdf, plotSpringDamper.pdf, spectralRadiusZeta0.pdf, triangleNormal.eps, triangleNormal.pdf. They are the vector originals of the LaTeX era; most have a .png twin that IS used. Copies are in tmp/unusedFigures for the maintainer to look at (that directory is git-ignored, so nothing left version control). What has to be decided: delete them, or keep them as the editable source of the png twins - in which case they belong somewhere that says so. NOTE eleven further .pdf figures ARE referenced, but only inside \ignoreRST{} blocks in definitions/itemDefsObjects.py, i.e. only by the LaTeX build that no longer exists; the Markdown and the new PDF of revision2026b step RG3.3 use their png twins.

    • notes: The figures of the documentation that have a vector original are shown as vector graphics in the PDF and as png in the HTML.

    • date resolved: 2026-10-03 08:16, date raised: 2026-09-22

  • 1.12.241 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG exu.HT where a 4x4 numpy HT is taken: rigidBodyUtilities and the robotics classes (#2799)

    • description: revision2026b step RG16.4.2: exu.HT converts to a 4x4 numpy array (__array__), the HT functions of rigidBodyUtilities and the robotics classes (RobotLink, RobotTool, RobotBase, InverseKinematicsNumerical) take an exu.HT as well; CreateKinematicTree gives jointHTs.

    • notes: numpy reads an exu.HT as its 4x4 matrix (np.array(H)); the HT functions of rigidBodyUtilities and the robotics classes take an exu.HT where they take a 4x4 array.

    • date resolved: 2026-10-03 07:56, date raised: 2026-10-03

  • 1.12.240 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG ObjectKinematicTree takes jointHTs, the joint transformations and offsets as one list of HTs (#2798)

    • description: revision2026b step RG16.4.1 (named in RG16.2): jointHTs, a list of homogeneous transformations (4x4, 16 values or exu.HT), reads and writes the stored jointTransformations and jointOffsets; None for not given, both given must agree; a list of HTs in the generator.

    • notes: ObjectKinematicTree takes its joint transformations and offsets as one list jointHTs of homogeneous transformations (4x4 matrices, their 16 values or exu.HT).

    • date resolved: 2026-10-03 07:56, date raised: 2026-10-03

  • 1.12.238 CHECK MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG homogeneous transformations in the user interface of the rigid items: evaluation (#2781)

    • description: Evaluate whether ObjectRigidBody, ObjectGround, rigid body nodes and rigid markers can take an HT instead of position and rotation (compatibility mode with None defaults, or a global/auto-detected mode flag), exporting both; localHT in the rigid markers and its deprecation path; homogenize with the localHT work (RG14.2.15); proposal and decisions for the maintainer.

    • notes: Homogeneous transformations in the user interface: ObjectGround referenceHT, CreateGround/CreateRigidBody referenceHT and initialHT, localHT of the rigid markers - None for not given, an HT and its parts must agree.

    • date resolved: 2026-10-03 01:43, date raised: 2026-10-02

  • 1.12.236 EXTENSION MEDIUM EFF resolved by: Claude-JG OutputVariable (#2202)

    • description: add kinetic and potential energy

    • notes: Kinetic and potential energy are output variables of the bodies, beams, plates, superelements and spring-dampers (OutputVariableType.KineticEnergy, PotentialEnergy), and exudyn.advancedUtilities.SystemEnergy sums them for a system.

    • date resolved: 2026-10-03 01:43, date raised: 2026-01-07

  • 1.12.235 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG a symbolic user function could not be created for an item whose signature an earlier item has (#2797)

    • description: found in revision2026b step RG12.4.7: the generated SetUserFunctionFromDict of PySymbolicUserFunctionSet.h had a branch only for the first user function of each signature - CreateSymbolicUserFunction for ObjectConnectorCoordinateSpringDamper (the signature of ObjectConnectorSpringDamper), LoadTorqueVector, LoadMassProportional, MainSystem postStepUserFunction and others raised ‘invalid user object type’; 16 of 28 had a branch.

    • notes: CreateSymbolicUserFunction works for every user function, also for items whose signature an earlier item has (ObjectConnectorCoordinateSpringDamper, LoadTorqueVector, LoadMassProportional, the MainSystem’s postStepUserFunction, …).

    • date resolved: 2026-10-03 01:40, date raised: 2026-10-03

  • 1.12.234 CHANGE MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the TPyFunction group types leave the definitions: a user function’s signature is that of its def (#2796)

    • description: revision2026b step RG12.4.7 (maintainer 2025-09-25): the 24 group names of definitionTypes.userFunctionSignatures were a lookup key stated next to the def; checked first that the std::function derived from each def’s annotations equals the group’s for all 34 user functions (RG12.4.7.1), then the type= removed: ItemDefinition gives each user function the type PyFunction<Item><Parameter> with the std::function of its def, the documentation shows the Protocol name, the symbolic set has one member per signature named after its first user function.

    • notes: A user function of an item takes its C++ signature from its def in the definitions; the reference manual shows the name of its Protocol as its type.

    • date resolved: 2026-10-03 01:40, date raised: 2026-10-03

  • 1.12.233 EXTENSION HIGH EFF raised by: Claude-JG resolved by: Claude-JG GraphicsData gets a Sphere and a CurvedTriangleList (#2709)

    • description: The maintainer, 2026-09-27: GraphicsData will be extended by two classes, Sphere and CurvedTriangleList. Bigger than it sounds: the GraphicsData dictionary, the OpenGL renderer and the raytracer have to be adapted (at least with temporary workarounds), the pybind interfaces, SC.renderer.GetGraphicsData(), the documentation - so even the minimal implementation takes time. Known limitation to resolve with it: the OpenGL renderer already treats spheres separately for nodes (large node numbers); the raytracer does not draw glSpheres at all, while GetGraphicsData() does return them. The graphics regression test (RG2.3.3, #2704) is extended when this lands. revision2026b step RG6.7.

    • notes: 6-node triangles are split per edge by its own curvature, so a surface curved in one direction is not split along the other; LinkedCylinders and the hollow Sphere consist of 6-node triangles; Tet10 surfaces of FEMinterface are drawn curved; OpenGL keeps the split while the graphics and the settings do not change.

    • date resolved: 2026-10-03 01:24, date raised: 2026-09-27

  • 1.12.232 EXTENSION HIGH EFF raised by: Claude-JG resolved by: Claude-JG the rigid body markers take localHT, a frame with position and rotation (#2795)

    • description: revision2026b step RG16.3.3 (decided in RG16.2, #2781; RG14.2.15, RG16.5): MarkerBodyRigid, MarkerNodeRigid, MarkerKinematicTreeRigid and MarkerSuperElementRigid (localHT replaces offset and adds a rotation) get localHT; the marker frame is the body or node frame times localHT; None for not given.

    • notes: The rigid markers take localHT, a frame with a rotation in the body, link or node: MarkerBodyRigid and MarkerKinematicTreeRigid (localPosition is its translation), MarkerSuperElementRigid (offset is its translation) and MarkerNodeRigid (a rotation only); a joint can take its axis from its markers instead of rotationMarker0/1.

    • date resolved: 2026-10-03 00:44, date raised: 2026-10-03

  • 1.12.231 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG CreateRigidBody and CreateGround take referenceHT and initialHT (#2794)

    • description: revision2026b step RG16.3.2 (decided in RG16.2, #2781): referenceHT next to referencePosition/referenceRotationMatrix, initialHT (the transformation added to the reference) next to initialDisplacement/initialRotationMatrix; None for not given, both raises.

    • notes: CreateGround takes referenceHT, CreateRigidBody referenceHT and initialHT for the reference and the initial position and rotation matrix.

    • date resolved: 2026-10-03 00:26, date raised: 2026-10-03

  • 1.12.230 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG ObjectGround stores its frame as HT; referenceHT next to referencePosition and referenceRotation (#2793)

    • description: revision2026b step RG16.3.1 (decided in RG16.2, #2781): ObjectGround stores one HomogeneousTransformation; the parameters referencePosition, referenceRotation and the new referenceHT (a 4x4 array, its 16 values or an exu.HT) are views of it, None for not given; the HT and a part given together must agree. The generator gets the HT parameter with its parts, for the rigid markers to follow.

    • notes: ObjectGround stores its frame as one homogeneous transformation: referenceHT (a 4x4 matrix, its 16 values or an exu.HT) next to referencePosition and referenceRotation, None meaning not given.

    • date resolved: 2026-10-03 00:26, date raised: 2026-10-03

  • 1.12.229 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG exu.HT from 16 values (#2792)

    • description: Maintainer 2026-10-02: exu.HT also takes the 16 values of the 4x4 matrix row by row - as a sensor stores the output variable HomogeneousTransformation - instead of exu.HT(values.reshape(4,4)).

    • notes: exu.HT also takes the 16 values of a 4x4 matrix row by row, as a sensor of the output variable HomogeneousTransformation stores them.

    • date resolved: 2026-10-03 00:02, date raised: 2026-10-02

  • 1.12.228 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG the frame of a rigid marker in the visualization: markers.showBasis, markers.basisSize (#2791)

    • description: Maintainer 2026-10-02: rigid body markers get an own rotation (localHT, RG16.3.3), so visualizationSettings.markers gets showBasis and basisSize (the names of nodes); a rigid marker draws its frame: simplified as 3 RGB lines, otherwise 3 arrows as the node basis, with heads 50 % shorter to tell them from a node basis.

    • notes: visualizationSettings.markers.showBasis and basisSize draw the frame of markers with position and orientation: three RGB lines with drawSimplified, else three arrows with short heads.

    • date resolved: 2026-10-03 00:02, date raised: 2026-10-02

  • 1.12.227 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG a system without coordinates is solved (#2790)

    • description: Maintainer 2026-10-02: allow a zero-sized system (nODE2 = nODE1 = 0) at least in explicit integration, and check where it would break. The solvers refused it in InitializeSolverPreChecks (‘cannot solve for system size = 0’); without that check the explicit, implicit and static solvers run with the dense linear solver; the sparse solvers crash for a system of size 0, and the error estimate of the automatic step size control divided by the number of coordinates (ODE23, DOPRI5).

    • notes: A system without coordinates (no ODE2, ODE1 or algebraic coordinates) is solved by the explicit, implicit and static solvers; time, user functions and sensors advance.

    • date resolved: 2026-10-03 00:02, date raised: 2026-10-02

  • 1.12.225 CHANGE LOW EFF raised by: Claude-JG resolved by: Claude-JG the output variable HomogeneousTransformation as exu.HT (#2789)

    • description: Maintainer 2026-10-02: GetNodeOutput, GetObjectOutputBody, GetObjectOutput, GetMarkerOutput and GetObjectOutputSuperElement return an exu.HT for OutputVariableType.HomogeneousTransformation instead of 16 numbers - the standard way; sensors keep storing the 16 numbers row by row (a sensor stores rows of numbers), from which exu.HT(values.reshape(4,4)) makes the HT.

    • notes: GetNodeOutput, GetObjectOutputBody and GetMarkerOutput return the output variable HomogeneousTransformation as an exu.HT; a sensor stores its 16 values row by row.

    • date resolved: 2026-10-02 23:33, date raised: 2026-10-02

  • 1.12.224 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectANCFBeam: the output variable RotationMatrix returns the potential energy (#2788)

    • description: The case RotationMatrix of CObjectANCFBeam::GetOutputVariableBody has no break and falls through to PotentialEnergy (added with #2202), so GetObjectOutputBody(beam, RotationMatrix) and a SensorBody return a scalar; found by the output variable HomogeneousTransformation (#2780), which reads RotationMatrix.

    • notes: The output variable RotationMatrix of ObjectANCFBeam returned the potential energy; it returns the rotation matrix again.

    • date resolved: 2026-10-02 22:38, date raised: 2026-10-02

  • 1.12.223 CHECK LOW EFF raised by: Claude-JG resolved by: Claude-JG raytracer: single bright pixels on curved triangles at coarse tiling (#2787)

    • description: Seen in the images of RG6.7.7.7 (2026-10-02): at nTiles 32 and below, a SolidOfRevolution and a half sphere through the raytracer (160 x 160 pixels) show a few single white pixels on the surface, not at 64 - rays passing between neighbouring curved triangles, or between the flat triangles the raytracer splits them into. To check: watertightness of the split of 6-node triangles along shared edges (the same subdivision on both sides).

    • notes: Curved surfaces (6-node triangles) no longer show single bright pixels in the raytracer: the triangles of one item are split at the same points along shared edges.

    • date resolved: 2026-10-02 22:38, date raised: 2026-10-02

  • 1.12.222 IMPROVEMENT HIGH EFF raised by: Claude-JG resolved by: Claude-JG homogeneous transformations: the C++ class and its Python binding (#2780)

    • description: HomogeneousTransformationBase into its own file, out of exulie; 12 numbers stored; fast H*v, H^-1, H1*H2, set/get with fixed-size loops and a no-rotation flag (global constexpr switch); tests and measurement; pybind exudyn.HT with operators; note in rigidBodyUtilities.HomogeneousTransformation; HT inside the rigid items and as output variable.

    • notes: exudyn.HT is the homogeneous transformation of the C++ core (composition, inverse, transformed points, 4x4 matrix); every node, body point, marker and connector with Position and RotationMatrix gives the output variable HomogeneousTransformation (16 values, the 4x4 matrix row by row).

    • date resolved: 2026-10-02 22:38, date raised: 2026-10-02

  • 1.12.221 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectALEANCFCable2D: a connector or load through a body marker fails with a size mismatch (#2786)

    • description: Since the legacy path is gone (RG14.2.13, #2745), connectors and loads act through the marker functions, which size the generalized force by the body’s 9 coordinates; the position and rotation Jacobians of ObjectALEANCFCable2D have 8 columns (the ANCF coordinates) - ‘MultMatrixTransposedVectorAddTemplate: Size mismatch’ in the first step (the three CND2022 ALE examples). Fix: the Jacobians get the ALE coordinate as 9th column, zero, which is what the legacy path did implicitly; whether it should be nonzero is #2784.

    • notes: Connectors and loads acting through a body marker on ObjectALEANCFCable2D work again; they failed with a size mismatch in the first step.

    • date resolved: 2026-10-02 21:32, date raised: 2026-10-02

  • 1.12.220 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG MarkerSuperElementRigid on ObjectFFRF is accepted by Assemble() and fails in the first evaluation (#2785)

    • description: Found by test_accessFunctionsAllBodies.py (RG9.5.6): GetAccessFunctionSuperElement raises ‘AngularVelocity_qt, only possible for ObjectGenericODE2 and ObjectFFRFreducedOrder’ when the Jacobian of a MarkerSuperElementRigid on an ObjectFFRF is formed - at the first Newton iteration, not at Assemble(). The consistency check of the marker (or the declared access functions of ObjectFFRF) should refuse it with that reason.

    • notes: Assemble() refuses a connector or load acting through a MarkerSuperElementRigid on ObjectFFRF, which has no rotation Jacobian; before, the simulation failed in its first step.

    • date resolved: 2026-10-02 20:47, date raised: 2026-10-02

  • 1.12.219 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG mbs.ItemCompute: the ODE2 Jacobian of an object, and the bodies not yet in the test of the access functions (#2782)

    • description: What mbs.ItemCompute (#2779) does not compute yet: the ODE2 Jacobian of an object or connector (analytic where it has one, else numerical as the solver does), IsValidLocalPosition of a body, the Jacobians of a node with algebraic equations; and the bodies test_accessFunctionsAllBodies.py does not build yet: ObjectFFRF, ObjectFFRFreducedOrder, ObjectKinematicTree, ObjectALEANCFCable2D, ObjectGenericODE2, the derivative of the Lie group node by composed increments.

    • notes: mbs.ComputeItem computes the analytic ODE2 Jacobian of a body or connector (ComputeItemType.JacobianODE2, JacobianODE2_t); for superelements and kinematic trees it computes through their markers.

    • date resolved: 2026-10-02 20:47, date raised: 2026-10-02

  • 1.12.218 CHANGE LOW EFF raised by: Claude-JG resolved by: Claude-JG mbs.ItemCompute renamed mbs.ComputeItem (#2783)

    • description: Maintainer’s review of RG9.5.1 (2026-10-02): the function is mbs.ComputeItem and its enumeration exu.ComputeItemType, verb first like mbs.AddObject; the rest of the proposal stays (helper in exudyn.advancedUtilities, what=None lists what applies, one vector argument).

    • notes: mbs.ItemCompute and exu.ItemComputeType, new in this release, are named mbs.ComputeItem and exu.ComputeItemType.

    • date resolved: 2026-10-02 19:49, date raised: 2026-10-02

  • 1.12.217 IMPROVEMENT HIGH EFF raised by: Claude-JG resolved by: Claude-JG mbs.ItemCompute: the computation functions of an item from Python (#2779)

    • description: Python reaches an item’s computation only through output variables. A general access at the current state - mbs.ItemCompute(itemIndex, what, [optional parameters]), like mbs.Inspect - to the access functions of bodies, ComputeODE2LHS and mass matrix, constraint equations and Jacobians, connector forces, node and marker Jacobians; functions defined once in base classes; plus a numerical-derivative helper for comparisons. For tests (#2777), debugging and user items.

    • notes: mbs.ItemCompute(item, what) computes what the solver computes for one object, node or marker at the current state - Jacobians, mass matrix, right-hand side, connector forces, constraint equations and Jacobians, reaction forces, marker kinematics; mbs.ItemCompute(item) lists what applies; exudyn.advancedUtilities.NumericalJacobian gives the numerical derivative to compare with.

    • date resolved: 2026-10-02 18:27, date raised: 2026-10-02

  • 1.12.216 TESTING MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG every body’s access functions against finite differences (#2777)

    • description: A pytest that builds each body type with nontrivial (deformed, rotated) coordinates and checks, at several local positions, GetPositionJacobian and GetRotationJacobian against finite differences of the position and rotation matrix (via the output variables), and GetJacobianTransposedTimesVectorDerivative against the numerical derivative of J^T f. Two bugs of this kind were found by chance on 2026-10-02 (ObjectANCFBeam position Jacobian 3 x 8 for 18 coordinates; the rotation Jacobian of NodePointSlope23 not the derivative of its rotation, #2763).

    • notes: A test checks the position and rotation Jacobians and their derivatives of 15 body types against finite differences; ObjectBeamGeometricallyExact now computes the derivative of its rotation Jacobian times a torque, so torques and joints with rotations on these beams give a consistent Newton Jacobian.

    • date resolved: 2026-10-02 18:26, date raised: 2026-10-02

  • 1.12.215 IMPROVEMENT LOW EFF raised by: Claude-JG resolved by: Claude-JG a sensor allocates its value vector per evaluation (#2778)

    • description: CSensor::GetSensorValues fills a Vector per call; with TemporaryMarkerDataStructure (#2745) this is the remaining allocation of a sensor evaluation (measured 2026-10-02: 4 M allocations for 200 SensorObject over 20000 steps, one per evaluation). A ResizableVector kept per sensor, or the value written into the storage directly.

    • notes: Output variables of coordinate connectors, joints and contacts no longer allocate memory per evaluation, which makes sensors on them faster.

    • date resolved: 2026-10-02 17:17, date raised: 2026-10-02

  • 1.12.214 CHECK LOW EFF resolved by: Claude-JG PostNewtonStep (#241)

    • description: Check why markerData is computed with computeJacobian=true in CSystem::PostNewtonStep; is jacobian information really needed?

    • notes: The discontinuous iteration (PostNewtonStep) of contacts and connectors no longer computes the Jacobians of their markers, which it never used.

    • date resolved: 2026-10-02 13:26, date raised: 2019-08-22

  • 1.12.213 EXTENSION LOW MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG access functions: the position Jacobian of ObjectRotationalMass1D off its axis, a rotation Jacobian of ObjectANCFBeam (#2775)

    • description: Two access functions a body could provide but does not, each needing a decision: ObjectRotationalMass1D defines its position at any local position but its position Jacobian only on the axis (Assemble refuses connector and load markers elsewhere, #2744); off the axis it would depend on the rotation angle, as ObjectRigidBody2D does it. ObjectANCFBeam declares no AngularVelocity_qt, so a MarkerBodyRigid cannot be attached; a rotation could be defined from its slope vectors (which ones, and with which orthogonalization, is the decision). Found in the evaluation of #2744 (RG9.3.1) and listed in #2773.

    • notes: ObjectRotationalMass1D accepts connectors and loads at any point of the table, not only on its axis; ObjectANCFBeam accepts MarkerBodyRigid, so torques and joints with rotations act on it; a position marker on ObjectANCFBeam used in a connector no longer fails with ‘request of invalid column’.

    • date resolved: 2026-10-02 12:47, date raised: 2026-10-02

  • 1.12.212 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG access functions: the leftovers found in the evaluation RG9.3.1 and the split RG9.3.4 (#2773)

    • description: Found on the way and left alone, one step at a time: (1) CSystem::CheckSystemIntegrity reports the marker index as the object number when a body lacks the rotation access function, and spells orienation; (2) dead code: the if (false) branch of CObjectANCFCable2DBase::GetPositionJacobian (the exact derivative of the normal, equal to the simpler version in use; ObjectALEANCFCable2D uses the exact one), the commented-out calls of GetAccessFunctionBody in the relative coordinate markers, CObjectRigidBody and VisualizationObject.h, the incomplete commented-out block in CObjectFFRFreducedOrder::GetMassWeightedPositionJacobian, the double SetAll in CObjectANCFBeam::GetMassWeightedPositionJacobian; (3) CMarkerKinematicTreeRigid::ComputeMarkerDataJacobianDerivative raises unconditionally and the code after it is unreachable (the tree declares no JacobianTtimesVector_q); (4) ideas, not bugs: ObjectRotationalMass1D could provide the position Jacobian off its axis as ObjectRigidBody2D does, ObjectANCFBeam a rotation Jacobian from its slopes. The three findings of section 7 of the evaluation are done in RG9.3.4.2.

    • notes: Fixed the leftovers of the access functions: the message of the integrity check named the marker index as the object number; dead and commented-out code of the split removed; the unreachable code of MarkerKinematicTreeRigid::ComputeMarkerDataJacobianDerivative removed. The two extensions that need a decision are #2775.

    • date resolved: 2026-10-02 12:03, date raised: 2026-10-02

  • 1.12.211 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectANCFCable2D: the position Jacobian at a point off the axis leaves its third row uninitialized (#2774)

    • description: GetPositionJacobian (formerly the TranslationalVelocity_qt case of GetAccessFunctionBody) of ObjectANCFCable2D and ObjectANCFCable2D-based elements sets rows 0 and 1 for localPosition[1] != 0 but never row 2, which keeps whatever the matrix held; a MarkerBodyPosition at y != 0 on a cable then projects forces with garbage z-components and the implicit solver can report a singular Jacobian at random. Found by the comparison of the access functions by automatic differentiation (RG9.3.5): a cable on an elastic foundation with markers at y = 0.01 failed or passed depending on the memory.

    • notes: ObjectANCFCable2D and ObjectALEANCFCable2D: the position Jacobian at a point off the axis sets its third row to zero; before, it kept whatever the matrix held, which gave forces with random z-components and could make the implicit solver report a singular Jacobian

    • date resolved: 2026-10-02 08:51, date raised: 2026-10-02

  • 1.12.210 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG graphics.MergeTriangleLists: the edges of g2 are not offset when g1 has no edges (#2769)

    • description: MergeTriangleLists appends the points of g2 after those of g1, but adds the offset nPoints to the edge indices of g2 only if g1 has edges as well; if g1 has none, the edges of g2 point to the points of g1. Found during revision2026b step RG6.7.7.5 (#2709), whose edges3 merge offsets always.

    • notes: graphics.MergeTriangleLists: the edges of the second list are offset by the points of the first also when the first has no edges

    • date resolved: 2026-10-02 01:22, date raised: 2026-10-01

  • 1.12.209 CHECK NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG computeMassMatrixInversePerBody does not reduce cost unless a sparse solver is also selected (#2400)

    • description: the flag is documented as computing the inverse of the mass matrix per body so that explicit integration does not need a global solve; and it is the intended answer to the O(N^2) cost of issue 2398 (it cannot be the default; because it gives wrong results when bodies share nodes - a beam or an FEM body - as its own documentation and the maintainer both state). Measured 2026-09-12 on a chain of independent point masses; with the flag value read back from the settings to confirm it was applied: with the DEFAULT DENSE solver the flag changes nothing. At nMasses=1000 and 200 steps: ExplicitEuler 8.43 s off against 8.57 s on, RK44 20.5 against 20.4, DOPRI5 33.0 against 32.7 - all within noise. Selecting EigenSparse is what removes the cost (0.070 s); and only then is the flag worth a further 10 to 15 percent (0.058 s). So on its own the flag does not do what it promises; the user still has to know to change the linear solver. Either the flag should bypass the solver path; or its documentation should say that it must be combined with a sparse solver. Found while building the large system performance test for revision2026 step R2.10

    • notes: explicitIntegration.computeMassMatrixInversePerBody: documented that it needs a sparse solver (EigenSparse) to reduce the cost of a step

    • date resolved: 2026-10-02 01:22, date raised: 2026-09-12

  • 1.12.208 BUG NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG explicit integration costs O(N^2) per step with the default dense linear solver (#2398)

    • description: measured 2026-09-12 on a chain of point masses coupled by coordinate spring dampers; explicit Euler; 200 steps: nMasses 250/500/1000/2000 gives 2.5/10.1/42/168 ms per step - the per step cost quadruples on every doubling; so it is O(N^2) although an explicit step on a chain should be O(N). Setting simulationSettings.linearSolverType to EigenSparse makes it linear and 400 times faster at nMasses=2000 (0.084 s against 33.5 s for 200 steps). The dense default is reasonable for small systems; but nothing warns at large N and explicit integration does not obviously need a linear solver at all; so the trap is invisible. Found while building a large system performance test for revision2026 step R2.10

    • notes: explicit integration with the dense default solver: the warning above 1000 unknowns says that every step costs O(n^2) and names exu.LinearSolverType.EigenSparse; documented in the manual (performance)

    • date resolved: 2026-10-02 01:22, date raised: 2026-09-12

  • 1.12.207 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectJointGeneric: the Jacobian ignores alternativeConstraints (#2772)

    • description: With alternativeConstraints=True and all rotations constrained, ComputeAlgebraicEquations uses the alternative equations (vx0*(vy1 x vz0) - 1, …), but ComputeJacobianAE always forms the Jacobian of the default ones (vz0*vy1, …). Newton then works with a wrong Jacobian. Found by revision2026b step RG14.2.9.3 (#2745): the Jacobian by automatic differentiation of the joint’s own equations agrees with a numerical one, the hand-written one does not; on the new path the joint uses the AD Jacobian.

    • notes: ObjectJointGeneric with alternativeConstraints=True: Newton used the Jacobian of the default rotation constraints; the joint now differentiates its own equations

    • date resolved: 2026-10-02 00:26, date raised: 2026-10-02

  • 1.12.206 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG MainSolverBase.ComputeAlgebraicEquations and ComputeODE1RHS raise a size mismatch (#2771)

    • description: solver.ComputeAlgebraicEquations(mbs) and solver.ComputeODE1RHS(mbs) link the residual as LinkedDataVector(systemResidual, start, start + n), but the third argument is the number of items: with algebraic equations (or ODE1 coordinates) the call raises ‘LinkedDataVectorBase: size mismatch’. Found by the tests of revision2026b step RG14.2.9.1 (#2745).

    • notes: solver.ComputeAlgebraicEquations(mbs) and solver.ComputeODE1RHS(mbs) raised a size mismatch when the system has algebraic equations or ODE1 coordinates; ComputeAlgebraicEquations returns the equations alone, no longer added to the previous residual

    • date resolved: 2026-10-01 23:50, date raised: 2026-10-01

  • 1.12.205 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG RotXYZGTv_qTemplate: wrong sign in d(G^T v)/dq for Tait-Bryan angles (#2770)

    • description: The derivative of G^T*v with respect to the Tait-Bryan angles has entry (2,1) = -c1*v[0] + …, but d(s1*v[0])/dq1 = +c1*v[0]. It enters the Jacobian derivative of every torque on a NodeRigidBodyRxyz (CObjectRigidBody JacobianTtimesVector_q, CNodeRigidBodyRxyz line 302); found by revision2026b step RG14.2.8.1 (#2745), whose AD Jacobian of the torsional spring-damper differed from the numerical one in exactly this entry.

    • notes: RotXYZGTv_qTemplate: the derivative of G^T v by the Tait-Bryan angles had a wrong sign in entry (2,1) (d(s1*v0)/dq1 = +c1*v0); it entered the Jacobian of every torque on a NodeRigidBodyRxyz

    • date resolved: 2026-10-01 23:30, date raised: 2026-10-01

  • 1.12.204 BUG MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG declared output variables that cannot be read (#2768)

    • description: mbs.Inspect(item, exu.InspectType.OutputVariables) over every item of every MiniExample (#2203) finds output variables an item declares but cannot compute: NodePoint2D RotationMatrix, Rotation, AngularVelocity, AngularVelocityLocal (GetOutputVariable failed); MarkerNodeODE1Coordinate Coordinates_t (refused by MainMarker); ObjectANCFThinPlate Director2 (GetOutputVariableBody failed); ObjectANCFBeam AngularVelocity and AngularVelocityLocal (not implemented); ObjectRotationalMass1D AngularVelocityLocal (GetOutputVariableBody failed); and two that depend on the node: ObjectRigidBody on NodeRigidBodyRotVecLG Acceleration, AccelerationLocal, AngularAcceleration, AngularAccelerationLocal (the Lie group node has no angular acceleration), MarkerNodeRigid on the node of ObjectBeamGeometricallyExact AngularVelocity. Each is either implemented or no longer declared; the node-dependent ones need the body or marker to ask its node.

    • notes: Every output variable an item declares can now be read: the rotation outputs of NodePoint2D, Director1/Director2/ForceLocal/TorqueLocal of ObjectANCFThinPlate (which returned zeros before; ForceLocal and TorqueLocal are the membrane force and moment resultants per length), the angular velocity of ObjectANCFBeam, the accelerations of a rigid body on NodeRigidBodyRotVecLG, AngularVelocityLocal of ObjectRotationalMass1D, the angular velocity of a rigid marker on NodePointGround; markers on ODE1 coordinates no longer list Coordinates_t.

    • date resolved: 2026-10-01 10:52, date raised: 2026-10-01

  • 1.12.203 EXTENSION MEDIUM EFF resolved by: Claude-JG MainSystem.Inspect (#2203)

    • description: add function MainSystem.Inspect(itemIndex, what, optArgs) which retrieves additional info on items like available output variables, node/marker types, etc.

    • notes: mbs.Inspect(itemIndex, what) asks an item what it provides and requests: output variables, type flags, requested node and marker types, access functions, as lists of exudyn enumeration members; what is a member of exu.InspectType, or None for all that apply. The output variables list the energies only where the item can compute them with its current parameters.

    • date resolved: 2026-10-01 10:16, date raised: 2026-01-07

  • 1.12.202 TESTING LOW EFF raised by: Claude-JG resolved by: Claude-JG tests of user-facing features as test models (#2767)

    • description: A test of what a user does with Exudyn (items, output variables, sensors, utilities, and what they refuse) belongs into python/TestModels, where users look for examples, not into python/testing (maintainer, 2026-10-01): python/testing/test_energies.py goes into the test model energiesTest.py and python/testing/test_connectorOutputVariables.py becomes the test model connectorOutputVariablesTest.py; the rule is written into CLAUDE.md and docs/dev/WORKFLOW.md section 5.

    • notes: A test of what a user does with Exudyn is a test model in python/TestModels, where users look for examples: the energy tests are in energiesTest.py and energiesFlexibleBodiesTest.py, the output variables of connectors in connectorOutputVariablesTest.py; the rule is in CLAUDE.md and docs/dev/WORKFLOW.md.

    • date resolved: 2026-10-01 08:49, date raised: 2026-10-01

  • 1.12.201 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG a sensor or object dictionary cannot hold KineticEnergy or PotentialEnergy (#2766)

    • description: The generated dictionary conversion of an OutputVariableType parameter cast the value to a 32-bit Index; KineticEnergy (bit 32) and PotentialEnergy (bit 33) then fail with ‘Unable to cast Python instance of type OutputVariableType’. Found 2026-10-01 in RG9.4.2: mbs.AddSensor(SensorBody(…, outputVariableType=KineticEnergy)) raised.

    • notes: An outputVariableType beyond the 32nd bit (KineticEnergy, PotentialEnergy) can be given to sensors; an outputVariableType of -1 is refused.

    • date resolved: 2026-10-01 00:22, date raised: 2026-10-01

  • 1.12.200 TESTING LOW EFF raised by: Claude-JG resolved by: Claude-JG the MiniExample graphics test checks the transformation of the drawing (#2765)

    • description: Maintainer 2026-09-30 (RG2.3.3.6): the test sees more - a brick instead of a tetrahedron, the world basis drawn, bodies away from the origin, and the drawing transformation checked; the evaluation images in a 3D view.

    • notes: The graphics test of the MiniExamples checks that every body is drawn where its kinematics put it.

    • date resolved: 2026-09-30 23:59, date raised: 2026-09-30

  • 1.12.199 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG a body rotated by a small angle is drawn unrotated (#2764)

    • description: AddBodyGraphicsData and AddBodyGraphicsDataColored skipped the rotation of a body’s graphics when the diagonal of its rotation matrix was 1.f - which it is in single precision for any angle below about 3e-4 rad, while the off-diagonal terms are not zero. Found 2026-10-01 by the transformation check of the MiniExample graphics test (RG2.3.3.6): the spherical, generic and planar revolute joint examples drew their bodies 3e-5 m off after five steps.

    • notes: A rigid body rotated by a very small angle is drawn with its rotation; before, rotations below about 3e-4 rad were not drawn.

    • date resolved: 2026-09-30 23:59, date raised: 2026-09-30

  • 1.12.198 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG rightAngleFrame.py stops at the buckling load: drive it by displacement (#2762)

    • description: The test model rightAngleFrame.py (ANCF and geometrically exact beam) applies the load by a user function and the static solver stops near the critical load 1.088 N; it was not run by the suite (useGraphics). Maintainer 2026-09-30: drive the tip by displacement, a coordinate constraint with an offset user function, the reaction force being the load.

    • notes: The test model rightAngleFrame.py drives the frame by displacement and follows it past the buckling load of 1.088 N.

    • date resolved: 2026-09-30 23:34, date raised: 2026-09-30

  • 1.12.197 CHANGE LOW EFF raised by: Claude-JG resolved by: Claude-JG the mass switch of ObjectBeamGeometricallyExact becomes exu.special.beams.geometricallyExactLumpedMass (#2761)

    • description: exu.experimental.beamGeometricallyExactConsistentMass (RG4.8.4) stays as a switch, for tests with both mass matrices, but as a special setting: exu.special.beams.geometricallyExactLumpedMass, default False (the consistent mass); the experimental one goes (maintainer, 2026-09-30).

    • notes: The mass matrix of ObjectBeamGeometricallyExact is switched with exu.special.beams.geometricallyExactLumpedMass (default False: the element-consistent mass); exu.experimental.beamGeometricallyExactConsistentMass is gone.

    • date resolved: 2026-09-30 23:27, date raised: 2026-09-30

  • 1.12.195 FIX MEDIUM EFF resolved by: Claude-JG shadows (#2308)

    • description: in case modelCentricView=False, lights with useCameraFrame=True have erratic shadows in OpenGL mode

    • notes: Shadows in the OpenGL renderer no longer flicker or disappear with a camera-centric view and lights in the camera frame.

    • date resolved: 2026-09-30 23:09, date raised: 2026-02-19

  • 1.12.194 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev runs the pytest files and the MiniExample performance run (#2760)

    • description: exudev has commands for runTestSuite, runTestExamples and runPerformanceTests, but none for the pytest files of python/testing (graphics regression, MiniExample graphics, settings, dialogs, tools), none for runMiniExamplePerformance.py and none to re-record the graphics references. New: exudev pytest [–graphics] [–gate] [–record] [-k] [–processes], exudev perf –mini [–full] [–processes] [–only] [–compare]; build –complete also runs pytest.

    • notes: exudev pytest runs the pytest files of python/testing (–graphics for the graphics tests, –record to re-write their references); exudev perf –mini runs the performance measurement of the MiniExamples.

    • date resolved: 2026-09-30 21:59, date raised: 2026-09-30

  • 1.12.193 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG examples in subfolders are not run, and two of them fail (#2757)

    • description: runTestExamples.py runs python/Examples/*.py only; the subfolders (FurtherExamples, publications, …) are not run. Found 2026-09-30 (revision2026b RG12.30.4) by running six of them: FurtherExamples/fourBarKinematicTreeUF.py fails with ‘module object is not callable’ (copy), publications/CND2022PieberNtarladimaGerstmayr/fixedFixedANCFALEdiscreteMasses.py with ‘exudyn.basicUtilities has no attribute pi’ - both from earlier import cleanups, not from RG12.30.

    • notes: The examples in the subfolders of python/Examples are run with the other examples and work again; ClearWorkspace() no longer breaks a later import of exudyn.basicUtilities; a static solve with a user-function load on an ALE ANCF cable no longer fails with an inconsistent load jacobian.

    • date resolved: 2026-09-30 20:03, date raised: 2026-09-30

  • 1.12.192 TESTING NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG graphics regression test: every item through its MiniExample (#2751)

    • description: The last part of #2704 (resolved 2026-09-29 with RG2.3.3.1 to RG2.3.3.4): take every item through its MiniExample - which every item but three has since RG13.6 (#2732) - and store the graphics fingerprint of each (SC.renderer.GetGraphicsData(), counts and metrics) as a reference. revision2026b step RG2.3.3.5.

    • notes: Every item’s drawing is checked through its MiniExample: the graphics data at the start and after a few steps are compared with stored references.

    • date resolved: 2026-09-30 19:04, date raised: 2026-09-29

  • 1.12.191 FIX MEDIUM EFF resolved by: Claude-JG FEMinterface (#2321)

    • description: meshes imported from NGsolve lead to triangles with wrong orientation as compared to GraphicsData

    • notes: The surface triangles of a mesh imported with FEMinterface.ImportMeshFromNGsolve point outward, as those of the other imports; an FFRF body from NGsolve is lit on its outside.

    • date resolved: 2026-09-30 18:52, date raised: 2026-03-03

  • 1.12.190 FIX MEDIUM EFF resolved by: Claude-JG ZoomAll (#2309)

    • description: does not include trackMarker position (and orientation); fix that even for moving markers in modelCentricView zoom all is possible

    • notes: ZoomAll takes a tracked marker (camera.trackMarker) into account: the scene is centered and sized as the view draws it, with the marker’s position and orientation tracked.

    • date resolved: 2026-09-30 18:43, date raised: 2026-02-19

  • 1.12.189 FIX LOW EFF resolved by: Claude-JG Marker positions (#1813)

    • description: wrong representation of marker positions in AnimateModes for deformation scaling=0

    • notes: The markers on a superelement (MarkerSuperElementPosition, MarkerSuperElementRigid) are drawn on the body also when visualizationSettings.bodies.deformationScaleFactor scales its deformation, e.g. for a mode of amplitude 0 in AnimateModes.

    • date resolved: 2026-09-30 18:34, date raised: 2024-04-08

  • 1.12.188 CHANGE MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG scripts and modules use exudyn.graphics where it has the replacement, not exudyn.graphicsDataUtilities (#2759)

    • description: After #2756 the scripts under python/ imported GraphicsDataRectangle, GraphicsDataOrthoCubeLines and the color4 names from exudyn.graphicsDataUtilities (41 star imports among them) instead of using exudyn.graphics. The maintainer asked for the scripts and modules to be adapted: graphics.Lines, graphics.BrickXYZ(addFaces=False, addEdges=True), graphics.color; only the mesh functions without a replacement keep an import from graphicsDataUtilities.

    • notes: The scripts and modules of Exudyn use exudyn.graphics for rectangles (graphics.Lines), line cubes (graphics.BrickXYZ with addFaces=False) and colors (graphics.color); exudyn.graphicsDataUtilities is imported only for its mesh functions.

    • date resolved: 2026-09-30 18:22, date raised: 2026-09-30

  • 1.12.187 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG the pages of ObjectFFRF and ObjectFFRFreducedOrder link example pages that the PDF leaves out (#2758)

    • description: The descriptions of ObjectFFRF and ObjectFFRFreducedOrder (#2734/#2735) link [](#examples-ngsolveffrf), [](#examples-ngsolvecmstutorial) and [](#testmodels-objectffrfreducedordertest). The PDF build excludes the example and test model pages (conf.py), so the three links are unresolved there (myst.xref_missing). An item page names its examples through the examples field, which the page lists with github links; checkDefinitions shall reject a link to an example page.

    • notes: The pages of ObjectFFRF and ObjectFFRFreducedOrder name their complete models (NGsolveFFRF.py, NGsolveCMStutorial.py, objectFFRFreducedOrderTest.py) and list them with their github links; the PDF documentation no longer reports unresolved references on them.

    • date resolved: 2026-09-30 17:52, date raised: 2026-09-30

  • 1.12.186 EXTENSION HIGH EFF raised by: Claude-JG resolved by: Claude-JG explicit solvers: the states updated in the PostNewton step (#2754)

    • description: Explicit solvers do no PostNewton step, so contact, friction, switching states, rotation counters and sliding joint elements are not updated (#830 added a warning). Concept (maintainer 2026-09-30): check whether a PostNewton step is needed at all; update the data variables in the explicit integration similar to GeneralContact - at the beginning of a step, or more correctly in every stage of a multi-stage method; check every object with a PostNewton step against the concept; a test sweeping all explicit integrators, like contactComparisonTest.py; #2109 (DOPRI5 step size at discontinuities) may be resolved by it or give insight. Planned as revision2026b step RG4.16.

    • notes: the explicit solvers perform the PostNewton step after every step (contact, friction, switching states) and keep the scheme of the implicit solvers: states fixed during the stages of a step, updated after it, the step repeated when a state changed; tested with all explicit integrators (explicitSolversPostNewtonTest.py)

    • date resolved: 2026-09-30 14:48, date raised: 2026-09-30

  • 1.12.185 FIX HIGH EFF resolved by: Claude-JG DOPRI5 (#2109)

    • description: DOPRI5 automatic step size not working well with discontinuities (ContactSphereSphere, etc.)

    • notes: explicit solvers with automatic step size (DOPRI5, ODE23): an accepted step keeps its step size while a discontinuous iteration (contact, friction) repeats it; before, the step size proposed for the next step was used for the repetition, which could reject the same step forever; ObjectContactSphereSphere, ObjectContactSphereTorus and ObjectContactSphereTriangle recommend a step size also where the contact ends, as ObjectContactCoordinate does, which makes the release accurate with large steps; results of models with these contacts change slightly

    • date resolved: 2026-09-30 14:48, date raised: 2025-06-22

  • 1.12.184 CHANGE MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG exudyn.utilities imports less (#2756)

    • description: Maintainer 2026-09-30: remove from exudyn.utilities the imports of the beam generators (GenerateStraightLineANCFCable2D, GenerateSlidingJoint, GenerateAleSlidingJoint, GenerateStraightBeam - in exudyn.beams), of CreateDistanceSensorGeometry, CreateDistanceSensor, DrawSystemGraph (mbs.Create…, mbs.Draw…) and of graphicsDataUtilities (the old colors color4red, … shall not be promoted); update the exudev scripts checker, all models under python/, and the documentation with the workarounds. Planned as revision2026b step RG12.30.

    • notes: from exudyn.utilities import * no longer provides the beam generators (import them from exudyn.beams), the MainSystem extensions CreateDistanceSensor…, DrawSystemGraph (use mbs.CreateDistanceSensor(…), mbs.DrawSystemGraph(…)) and the names of exudyn.graphicsDataUtilities (the colors color4red… are graphics.color.red…; import the rest from exudyn.graphicsDataUtilities); GraphicsDataRectangle and GraphicsDataOrthoCubeLines are deprecated; exudev scripts names every affected line

    • date resolved: 2026-09-30 13:53, date raised: 2026-09-30

  • 1.12.183 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG explicit solvers: the warning about the PostNewton step is wrong (#2755)

    • description: The warning added for #830 (revision2026b RG4.15.3) says that explicit solvers do not perform the PostNewton step; they do, after every step, through the discontinuous iteration of CSolverBase. The warning is removed; found in revision2026b step RG4.16.1.

    • notes: the warning at the start of an explicit solve about objects with a PostNewton step is removed: it was wrong - explicit solvers perform the PostNewton step after every step, like the implicit solvers

    • date resolved: 2026-09-30 11:33, date raised: 2026-09-30

  • 1.12.181 BUG HIGH EFF resolved by: Claude-JG ContactSphereTorus (#2127)

    • description: check torques on both bodies, as there seems to be momentum conservation issues in ball bearings

    • notes: ObjectContactSphereTorus: the torque of the normal contact force on the torus is applied also without friction; before, a free torus (e.g. the ring of a ball bearing) did not conserve angular momentum

    • date resolved: 2026-09-30 07:33, date raised: 2025-07-03

  • 1.12.180 FIX MEDIUM EFF resolved by: Claude-JG NumericalJacobianODE1RHS (#1424)

    • description: add case for duplicated ODE1 coordinates if connector has two markers for the same object, same as ltgODE2numDiff

    • notes: the numerical Jacobian of ODE1 equations differentiates an ODE1 coordinate that an object addresses twice only once; before, its column was added twice, which slowed Newton’s convergence

    • date resolved: 2026-09-30 07:33, date raised: 2023-02-08

  • 1.12.179 BUG MEDIUM EFF resolved by: Claude-JG PostNewton (#830)

    • description: PostNewton missing in explicit solvers; add warning or add after single steps (but exclude in contact computation!)

    • notes: explicit solvers (RK, DOPRI5, …) warn at the start of a solve about objects that update their state in the PostNewton step of the implicit solvers - contact, friction, switching, rotation counters, sliding joints - which the explicit solvers do not update

    • date resolved: 2026-09-30 07:33, date raised: 2021-12-15

  • 1.12.178 EXTENSION LOW EFF resolved by: Claude-JG GeometricallyExactBeam2D (#2208)

    • description: add test for 3-node element

    • notes: ObjectBeamGeometricallyExact2D: the 3-node (quadratic) element is tested - one element reproduces the Timoshenko cantilever, and it converges with fourth order for large deformation (test model geometricallyExactBeam2DquadraticTest.py)

    • date resolved: 2026-09-30 07:18, date raised: 2026-01-08

  • 1.12.177 BUG HIGH EFF raised by: Claude-JG resolved by: Claude-JG ObjectBeamGeometricallyExact (3D) has defects and is under development: analyse the implementation (#2730)

    • description: The maintainer, 2026-09-28: ‘The 3D GeometricallyExactBeam has some defects and is still under development. So, you would find some errors in the implementation - so keep this item open and add a step and issue to RG4.’ Its reference page (4 words of description) stays open in RG13.5.2 until the analysis says what the element does and what it does not; an item found with a larger defect while it is documented gets an RG4 step like this one rather than a fix inside RG13. revision2026b step RG4.8.

    • notes: ObjectBeamGeometricallyExact is analysed and completed: body markers and output variables (section forces, strains, rotations) are available, the Jacobian is complete, the element is stress-free in the reference configuration of its nodes (curved and twisted beams), the mass matrix is element-consistent, and the element is tested against the literature (45-degree bend, right-angle frame buckling, dynamic right-angle cantilever); its reference page and MiniExample describe it

    • date resolved: 2026-09-30 01:43, date raised: 2026-09-28

  • 1.12.176 CHECK MEDIUM EFF resolved by: Claude-JG GeometricallyExactBeam (#1273)

    • description: check quadratic velocity terms

    • notes: ObjectBeamGeometricallyExact: element-consistent mass matrix and quadratic velocity vector, for the linearly interpolated velocity field of the element; a rigid motion is represented exactly at any mesh (the lumped mass of the nodes gave e.g. a 22 % too long period for a one-element pendulum); dynamic results change; exu.experimental.beamGeometricallyExactConsistentMass=0 switches back to the lumped mass for comparison

    • date resolved: 2026-09-30 01:32, date raised: 2022-09-24

  • 1.12.175 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectBeamGeometricallyExact: output variables (#2753)

    • description: the definition declares the output variables Rotation, StrainLocal and CurvatureLocal, which GetOutputVariableBody does not compute - asking for them stops with an internal error; ForceLocal and TorqueLocal, the section forces and moments, are missing (maintainer); planned as revision2026b step RG4.8.10

    • notes: ObjectBeamGeometricallyExact: the output variables Rotation, RotationMatrix, AngularVelocity, AngularVelocityLocal, StrainLocal, CurvatureLocal, ForceLocal and TorqueLocal are available; strains and section forces are constant in an element; Rotation, StrainLocal and CurvatureLocal were declared before but stopped with an internal error

    • date resolved: 2026-09-30 00:16, date raised: 2026-09-30

  • 1.12.174 TESTING NORMAL MEDIUM EFF resolved by: Claude-JG GeometricallyExactBeam (#1499)

    • description: check for advanced right-angle frame

    • notes: ObjectBeamGeometricallyExact: tested with the lateral buckling of the right-angle frame, which buckles at the published critical load of 1.088 N (test model geometricallyExactBeamRightAngleFrame.py)

    • date resolved: 2026-09-30 00:04, date raised: 2023-04-08

  • 1.12.173 FIX HIGH MEDIUM EFF resolved by: Claude-JG GeometricallyExactBeam (#1494)

    • description: add reference configuration to residual and jacobian

    • notes: ObjectBeamGeometricallyExact: the element is stress-free in the reference configuration of its nodes, so a curved or twisted beam is modelled by placing and orienting its nodes; before, every element was stress-free only when straight along its local x axis

    • date resolved: 2026-09-29 23:54, date raised: 2023-04-06

  • 1.12.172 FIX MEDIUM EFF resolved by: Claude-JG GeometricallyExactBeam (#1550)

    • description: add F_Lie*Glocal_q term for Jacobian to improve convergence

    • notes: ObjectBeamGeometricallyExact: the Jacobian contains the terms of the derivative of Glocal and of the rotation matrix; see #1100

    • date resolved: 2026-09-29 23:46, date raised: 2023-05-02

  • 1.12.171 EXTENSION HIGH EFF resolved by: Claude-JG GeometricallyExactBeam3D (#1100)

    • description: finalize implementation and fix jacobian computation

    • notes: ObjectBeamGeometricallyExact: the Jacobian is complete - the derivatives of the rotation matrices, of the G matrices and of the SE(3) tangent operator are included, and the derivative of the quadratic velocity vector with respect to the velocities; large deformations with Tait-Bryan nodes converge in the static solver, which failed before

    • date resolved: 2026-09-29 23:46, date raised: 2022-05-23

  • 1.12.169 EXTENSION NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev issue plot: the issues over time as a matplotlib figure (#2752)

    • description: The maintainer, 2026-09-29: ‘exudev issue plot’ opens a matplotlib figure with the issues over time - total, closed and open - and, on a second scale, total and open bugs and fixes, with a legend. revision2026b step RG10.13.

    • notes: exudev issue plot shows the issues over time - total, closed, open, and the bugs and fixes on a second axis; –save FILE writes the figure.

    • date resolved: 2026-09-29 21:41, date raised: 2026-09-29

  • 1.12.168 EXTENSION NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG ObjectContactCoordinate gets the contact law of ObjectContactSphereSphere: stiffness exponent, restitution and impact models (#2750)

    • description: The maintainer, 2026-09-29: ObjectContactCoordinate should get the contact law of ObjectContactSphereSphere - contactStiffnessExponent, restitutionCoefficient, impactModel, minimumImpactVelocity (Hunt-Crossley and Gonthier/Carvalho-Martins); the comparison test of the three contact objects (RG4.15.1) extends to these laws. revision2026b step RG4.15.2.

    • notes: ObjectContactCoordinate has the contact law of ObjectContactSphereSphere: contactStiffnessExponent, restitutionCoefficient, minimumImpactVelocity and impactModel (Hunt-Crossley, Gonthier et al. / Carvalho-Martins); with an impact model its data node has a second coordinate.

    • date resolved: 2026-09-29 21:27, date raised: 2026-09-29

  • 1.12.167 FIX MEDIUM EFF resolved by: Claude-JG mbs.GetDictionary (#1888)

    • description: does not work for symbolic userfunctions

    • notes: mbs.SetDictionary() accepts the dictionary of a model with a symbolic user function, as mbs.GetDictionary() writes it; the copy keeps the function symbolic.

    • date resolved: 2026-09-29 21:27, date raised: 2024-10-11

  • 1.12.166 TESTING NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG one drop, three contact objects: ObjectContactCoordinate, ObjectContactSphereSphere, ObjectContactSphereTriangle give the same motion (#2749)

    • description: The maintainer, 2026-09-29, as a check in compensation for #738: a ball hitting the ground computed with ObjectContactCoordinate (one coordinate), ObjectContactSphereSphere (a large ground sphere) and ObjectContactSphereTriangle (a ground triangle), with the same linear penalty law, must give the same motion; all together in one test. revision2026b step RG4.15.1.

    • notes: A test drops a ball on the ground with ObjectContactCoordinate, ObjectContactSphereSphere and ObjectContactSphereTriangle and checks that the three give the same motion.

    • date resolved: 2026-09-29 20:15, date raised: 2026-09-29

  • 1.12.165 DOCU HUGE EFF raised by: Claude-JG resolved by: Claude-JG RG13.5: the documentation of the items, written by the development documents of RG13.4 - nodes, objects, markers, loads, sensors (#2725)

    • description: The maintainer, 2026-09-27, after reading the node, load and sensor documents of RG13.4: those three are complete; ‘start a new step RG13.5, which adds according documentation for these types, again adding 13.5.1 for nodes, .2 for objects, …’. For loads the generalized forces keep their frames: a load is given in global or local coordinates, and the transformation belongs in the equation. For the slope nodes, the interpretation of the slopes goes into the detailed description of each node. RG13.5.0 is the generated frame and the general section per kind (definitions/itemKindDefinitions.py), before the pages are written. revision2026b step RG13.5.

    • notes: The reference manual describes every item - nodes, objects, markers, loads, sensors - with a general section per kind of item, and each item with what is its own.

    • date resolved: 2026-09-29 20:15, date raised: 2026-09-27

  • 1.12.164 TESTING MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG a graphics regression test on SC.renderer.GetGraphicsData(): counts per item, and metrics of positions and colors (#2704)

    • description: The maintainer, 2026-09-27: ‘File graphicdata test as step. It could include also metrics for positions, colors - mean/min/max - so the content is also checked.’ A set of models, each under several visualization settings, reduced to a fingerprint from SC.renderer.GetGraphicsData() (#2700) and compared with a stored reference: the NUMBER of lines, spheres, circles, texts and triangles per item exactly, and the CONTENT through metrics - min, max and mean of the points per coordinate, of the colors per channel, of radii and normals - with a tolerance, because the data is float32 and must compare across compilers. Texts are compared as their strings. The fingerprint is small enough to be a readable JSON reference, so a change shows in git diff as ‘ObjectRigidBody 3: 12 triangles -> 10’ or ‘mean z of the triangles of object 0 moved by 0.2’. No window is opened. revision2026b step RG2.3.3.

    • notes: A graphics regression test compares what the renderer draws - counts and metrics of the graphics data per item under the most used settings and with graphics user functions - and low-resolution raytracer images with stored references.

    • date resolved: 2026-09-29 20:15, date raised: 2026-09-27

  • 1.12.159 BUG MEDIUM EFF resolved by: Claude-JG ObjectContactCoordinate (#738)

    • description: modified Newton does not work, no Jacobian update computed when switching

    • notes: ObjectContactCoordinate switches its contact with a Jacobian update; a test compares it with the sphere-sphere and sphere-triangle contact on the same drop (#2749).

    • date resolved: 2026-09-29 20:15, date raised: 2021-08-13

  • 1.12.158 TESTING HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG a manual check of the render window and the dialogs before a release, on each platform (#2748)

    • description: The maintainer, 2026-09-29 (tmp/ManualGraphicsCheck): nothing automatic checks that a human can use the render window and the dialogs - keys, mouse, tkinter windows, focus, fonts, window placement. A check list for one person and one hour per platform (Windows, Ubuntu, macOS) before each release, with a model that has an item of every kind: the list into the developer documentation, the model into python/testing. revision2026b step RG2.4; RG1.4 waits for it.

    • notes: The developer documentation has a check list of the render window and the dialogs, for a person on each platform before a release, with a model that has an item of every kind (python/testing/guiManualCheckModel.py).

    • date resolved: 2026-09-29 19:58, date raised: 2026-09-29

  • 1.12.157 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the GitLab job check_docstrings fails, and no local gate runs pydoclint (#2747)

    • description: The maintainer, 2026-09-29, tmp/gitLabRunsFailed/check_docstrings.txt: pydoclint reports 29 findings outside its baseline - 25 DOC108 in the generated itemInterface.py (the user function parameters carry their Protocol type since #2664, and the configuration says no type hints in signatures), three DOC202 (a Returns: None section without a return: GUI.ApplyColumnWidths, GUI.StoreWindowGeometry, overrideSettings.StoreDialogGeometry) and one DOC104 (argument order in resultsMonitor.MonitorResults). No local gate runs pydoclint, so the CI job is the first to see it. Fix the four, record the deliberate DOC108 in the baseline, and add pydoclint to exudev generate –all-checks. revision2026b step RG10.12.

    • notes: The docstring check of the CI passes again, and exudev generate –all-checks runs it locally.

    • date resolved: 2026-09-29 19:52, date raised: 2026-09-29

  • 1.12.156 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG developer documentation names paths of the old main/ directory (#2743)

    • description: Found in revision2026b step RG13.7: docs/dev/WORKFLOW.md and docs/dev/README.md name main/setup.py, main/obj/cppsrc.vcxproj, main/sources.json and main/pyproject.toml; the files are setup.py, msvc/cppsrc.vcxproj, sources.json and pyproject.toml at the repository root. The layout block of the README also carries hand-kept counts that are wrong (24 mini examples, 139 test models) and a src/ listing without the Impl* directories. revision2026b step RG3.28.

    • notes: The developer documentation names the build files where they are: setup.py, pyproject.toml and sources.json at the repository root, the project file in msvc/.

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

  • 1.12.153 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG developer documentation: how to set up a new item (#2742)

    • description: The maintainer, 2026-09-29: a section ‘How to set up a new item in Exudyn’ - the definitions and how they work, how to add a simple item, with focus on the descriptions, parameter and function descriptions, miniExample and outputVariables; what to run; which files the generator writes for a new className (C/Main/Visu headers, object factory registration, Python interface, stubs, docs, MiniExample), and what is written by hand (the .cpp with the computation and UpdateGraphics, CheckPreAssembleConsistency in checkPreAssembleConsistencies<Kind>.cpp, the project file). The parts exist in CODING_STYLE.md section 9, ARCHITECTURE.md and definitions/README.md, scattered; one page brings them together and refers to the rest. revision2026b step RG13.7.

    • notes: The developer documentation has a page on how to set up a new item: the definition, which files the generator writes, the C++ to write for each kind of item, and what to run.

    • date resolved: 2026-09-29 18:54, date raised: 2026-09-29

  • 1.12.152 BUG MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the cable and beam shape markers accept any body: on a wrong one they cast it to an ANCF cable (#2731)

    • description: Found while documenting the markers, revision2026b step RG13.5.3, 2026-09-28: MarkerBodyCable2DShape, MarkerBodyCable2DCoordinates and MarkerBodyBeamShape have no consistency check of the body they are attached to. Assemble() accepts them on a rigid body, and ComputeMarkerData then casts the body to CObjectANCFCable2DBase or CObjectANCFCable: with range checks this ends in ‘InternalError: call to ConstSizeVectorBase::SetNumberOfItems with newNumberOfItems > dataSize’, in the fast module (no range checks) it is undefined behaviour. The analysis: which bodies each of the three markers can serve (ANCFCable2D and ALEANCFCable2D; ANCFCable), a CheckPreAssembleConsistency that says so, and whether MarkerBodyBeamShape, described as for ‘a 3D beam finite element’, should serve other beams. revision2026b step RG4.9 (maintainer’s rule: a larger defect found while documenting gets an RG4 step).

    • notes: Assemble() refuses MarkerBodyCable2DShape and MarkerBodyCable2DCoordinates on anything but ObjectANCFCable2D or ObjectALEANCFCable2D, and MarkerBodyBeamShape on anything but ObjectANCFCable - they cast the body to a cable before. MarkerBodiesRelativeTranslationCoordinate and MarkerBodiesRelativeRotationCoordinate are coordinate markers only; position connectors and loads no longer accept them, and Assemble() refuses bodies without the position or orientation they need.

    • date resolved: 2026-09-29 18:38, date raised: 2026-09-28

  • 1.12.151 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectContactCoordinate ignores activeConnector, and its output variable Distance raises (#2735)

    • description: Found while documenting the connectors, revision2026b step RG13.5.2.4, 2026-09-28: CObjectContactCoordinate::ComputeODE2LHS computes the contact force without looking at parameters.activeConnector, so the connector cannot be switched off as its parameter says; and GetOutputVariableTypes declares Distance while GetOutputVariableConnector raises ‘not implemented’, so a SensorObject asking for it passes Assemble() and fails during the simulation. Small, but found by the maintainer’s rule it becomes an RG4 step: revision2026b step RG4.11. [2026-09-28, Claude-JG]: Extended in RG13.5.2.5, 2026-09-28: a scan of all objects for GetOutputVariableConnector that raises ‘not implemented’ while GetOutputVariableTypes declares types found four: ObjectContactCoordinate (Distance), ObjectContactCircleCable2D (Distance), ObjectJointRevolute2D (Displacement, Rotation) and ObjectJointPrismatic2D (Distance, Rotation). A sensor asking for one of them passes Assemble() and fails during the simulation. Either implement the output variables or declare none.

    • notes: Output variables of four connectors: ObjectContactCoordinate gives Distance (the gap) and adds no force with activeConnector=False; ObjectJointRevolute2D gives Displacement; ObjectJointPrismatic2D gives Distance along the axis and the relative Rotation; ObjectContactCircleCable2D declares none. They raised ‘not implemented’ during the simulation before.

    • date resolved: 2026-09-29 18:09, date raised: 2026-09-28

  • 1.12.150 BUG MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG ObjectGenericODE2 and ObjectKinematicTree admit the general body markers, which fail during the simulation (#2734)

    • description: Found while documenting the super elements, revision2026b step RG13.5.2.3, 2026-09-28: both objects declare the access function types TranslationalVelocity_qt and AngularVelocity_qt (and GenericODE2 DisplacementMassIntegral_q), which their own markers need - MarkerSuperElementPosition/Rigid, MarkerKinematicTreeRigid - to pass CSystem::CheckSystemIntegrity. The same types admit MarkerBodyPosition, MarkerBodyRigid and MarkerBodyMass, whose computation calls GetAccessFunctionBody, and that raises ‘not available’ for both objects. The declaration now carries bodyMarkers=False, which the item pages use; the analysis: let the integrity check use it too, so that Assemble() refuses the combination. revision2026b step RG4.10.

    • notes: Assemble() refuses MarkerBodyPosition, MarkerBodyRigid and MarkerBodyMass on ObjectGenericODE2 and ObjectKinematicTree, which provide access only for their own markers - they raised during the simulation before; a super element marker needs a super element and a kinematic tree marker a kinematic tree.

    • date resolved: 2026-09-29 18:09, date raised: 2026-09-28

  • 1.12.149 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectKinematicTree: the position Jacobian of a prismatic joint rotates the axis twice (#2740)

    • description: Found while writing the page of MarkerKinematicTreeRigid (#2738, revision2026b step RG13.5.3.1). CObjectKinematicTree::ComputeJacobian computes axis = rotJoint*localAxis, which is the global joint axis, and for a prismatic joint then sets positionJacobian column = rotJoint*axis - the rotation applied twice. It is right only while the joint frame leaves the axis unchanged. Measured: link 0 RevoluteZ held at q0, link 1 PrismaticX on it, a LoadForceVector of 1 N along the prismatic axis on a MarkerKinematicTreeRigid of link 1, mass 2: after 1 s q1 = 0.25 for q0 = 0, and q1 = 0 for q0 = pi/2 (the column is -e_x instead of e_y). Every marker, load and connector on a link at or behind a rotated prismatic joint gets wrong generalized forces. The fix is one line (positionJacobian column = axis) and a test model with the case above. revision2026b step RG4.13.

    • notes: ObjectKinematicTree: a force, torque or connector on a MarkerKinematicTreeRigid behind a prismatic joint whose axis is rotated - by a parent link or by its joint transformation - acts in the right direction; the Jacobian rotated the prismatic axis twice, which gave wrong generalized forces, e.g. none at all behind a revolute joint at 90 degrees.

    • date resolved: 2026-09-29 14:44, date raised: 2026-09-29

  • 1.12.148 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG parameter tables: the symbol in the name column, and columns squeezed in the PDF (#2741)

    • description: The maintainer, 2026-09-29: (1) the symbol of a parameter, e.g. the force f of LoadForceVector, is appended to the name in the parameter tables; it belongs at the very beginning of the description, ‘(symbol: f) ‘, where it stays visible when a column is added or the name column is narrow. (2) In the PDF, a table with long descriptions gets name, type and default value columns of a few letters, because LaTeX sizes the columns by content; the parameter tables and the similar ones need minimum widths in the PDF. revision2026b step RG13.5.0.8.

    • notes: In the parameter tables of the reference manual the symbol of a parameter opens its description, ‘(symbol: f)’; in the PDF the columns of these tables have fixed widths, so that a long description no longer squeezes the name, type and default value.

    • date resolved: 2026-09-29 14:26, date raised: 2026-09-29

  • 1.12.147 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG MarkerSuperElementRigid and MarkerKinematicTreeRigid keep text in HTML comments (#2738)

    • description: The detailed descriptions of MarkerSuperElementRigid and MarkerKinematicTreeRigid carry tables and equations inside HTML comments (<!– … –>, remains of the LaTeX conversion), which are in the definition and on no page. Each part is either restored as Markdown, checked against the C++, or deleted. Left open by revision2026b step RG13.4 (#2721); revision2026b step RG13.5.3.1.

    • notes: MarkerKinematicTreeRigid has a full description - its quantities from the link frame, the Jacobians of revolute and prismatic joints and the generalized forces -, and MarkerSuperElementRigid says how rotationsExponentialMap changes its rotation matrix and angular velocity.

    • date resolved: 2026-09-29 14:26, date raised: 2026-09-29

  • 1.12.146 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG item pages: which Create functions add the item, and the plainest examples first (#2737)

    • description: Left open by the development documents of revision2026b step RG13.4 (#2721), folded into definitions/README.md in RG13.4.6: (1) each item page names the Create functions that add it, and each Create function names the items it adds - measured by running each Create function on a small model, because a static scan misses what an argument selects (CreateRigidBody makes one of four nodes, CreateForce one of two markers); open whether it runs inside generate or writes a JSON file the emitter reads; (2) the examples and test models of a page, today up to 129 links in file order, with the five plainest (shortest) first. revision2026b step RG13.5.0.6.

    • notes: The page of an object or load that a Create function adds says so before its parameters - ‘Simpler: mbs.CreateRigidBody adds this item, with what it needs, in one call’ -, and the pages of the point mass and rigid body items and of all sensors list a few plain examples, tutorials first, instead of every script that names the item.

    • date resolved: 2026-09-29 13:56, date raised: 2026-09-29

  • 1.12.145 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG items reference manual: the general section of a kind is a page of its own, next to the items (#2739)

    • description: The maintainer, 2026-09-29: the page of a kind (Node, Object (Body), …) holds its general section and then the items under a heading ‘Items’, so the items sit one level deeper than the general text in the navigation. Wanted: Node -> ‘General info for all nodes’ (with its sub-sections) -> NodePoint, NodePoint2D, … as siblings, without an ‘Items’ heading. The emitter writes the general section as a page of its own, <kind>General.md, first in the toctree of the kind. revision2026b step RG13.5.0.7.

    • notes: The items reference manual lists under each kind of item first a page ‘General info for all nodes’ (bodies, connectors, markers, …) with the sections that hold for every item of the kind, and then the items, side by side.

    • date resolved: 2026-09-29 13:33, date raised: 2026-09-29

  • 1.12.144 DOCU HIGH EFF raised by: Claude-JG resolved by: Claude-JG RG13: the development documents per item type - what the documentation of a node, object, marker, load and sensor must contain (#2721)

    • description: The maintainer, 2026-09-27: evaluate on a textual level, from representative examples - the tutorials, and the Create functions that hide the items behind them - what a reader needs to know about a node, marker, load, object and sensor and how they relate; check the text the generator writes around the generated information (e.g. ‘This Node has/provides the following types = Position’, which could say which markers it allows, and could be generated); make the interpretation of node coordinates systematic; group the objects - rigid bodies, flexible bodies (nonlinear finite elements), connectors acting on two or more markers; a general section per kind, above all for sensors, loads and markers. Written first as temporary documents docs/revision/<itemType>DefinitionsDev.md, which are folded into the developer documentation - what documentation an item needs, what it contains and how it is structured - and then removed. revision2026b step RG13.4.

    • notes: What documentation an item needs, what of its page is generated and what is written, the headings of the detailed description per kind and what a mini example is: definitions/README.md, section ‘The page of an item’.

    • date resolved: 2026-09-29 13:18, date raised: 2026-09-27

  • 1.12.143 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectANCFCable declares an angular velocity access function it does not implement (#2733)

    • description: Found while documenting the finite elements, revision2026b step RG13.5.2.2, 2026-09-28: ObjectANCFCable declares ItemAccessFunctionTypes TranslationalVelocity_qt, AngularVelocity_qt and DisplacementMassIntegral_q, but GetAccessFunctionBody has no case for AngularVelocity_qt (it is commented out) and GetAngularVelocity throws ‘not implemented’ - a single slope vector carries no orientation. So CheckSystemIntegrity accepted a MarkerBodyRigid on the cable, which then failed during the simulation, and the item page listed MarkerBodyRigid as fitting. The declaration drops AngularVelocity_qt; Assemble() now refuses such a marker with the check’s own message.

    • notes: ObjectANCFCable no longer declares an angular velocity access function it does not implement: Assemble() refuses a MarkerBodyRigid on the 3D cable with a clear message, where the simulation failed before, and the item page no longer lists that marker as fitting.

    • date resolved: 2026-09-28 14:20, date raised: 2026-09-28

  • 1.12.141 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG the PDF starts every item of the items reference manual on a new page (#2729)

    • description: The maintainer, 2026-09-28: ‘the PDF docs should add a new page before every item in the items reference manual. This improves readability.’ Every generated item page opens with a raw LaTeX \clearpage, which the HTML build ignores. revision2026b step RG13.5.0.5.

    • notes: In the PDF documentation every item of the items reference manual starts on a new page.

    • date resolved: 2026-09-28 07:45, date raised: 2026-09-28

  • 1.12.140 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG NodePointSlope12 and NodePointSlope23: the default reference slopes are parallel, [1,0,0] for both (#2728)

    • description: Found while writing the node pages of revision2026b step RG13.5.1, 2026-09-28: the default referenceCoordinates of NodePointSlope12 are [0,0,0, 1,0,0, 1,0,0] - slopeX and slopeY both along x - and of NodePointSlope23 [0,0,0, 1,0,0, 1,0,0] - slopey and slopez both along x. Neither spans a plate or a cross section; a flat plate in the x-y plane has slopes [1,0,0] and [0,1,0], a beam along x has cross section slopes [0,1,0] and [0,0,1]. Changing a default changes what a model without explicit reference coordinates computes, so it is raised, not changed; the node pages say to give them.

    • notes: The default reference coordinates of NodePointSlope12 are those of a flat plate in the x-y plane, [0,0,0, 1,0,0, 0,1,0], and of NodePointSlope23 those of the cross section of a beam along x, [0,0,0, 0,1,0, 0,0,1]; before, both slope vectors of each node were [1,0,0]. A model gives the reference coordinates of every node, so this changes what the defaults show.

    • date resolved: 2026-09-28 07:45, date raised: 2026-09-28

  • 1.12.137 TESTING NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG A test hook for forceQuitSimulation, which nothing can reach (#2674)

    • description: #2616 fixed the behaviour - quitting the renderer before a simulation starts raises where quitting during it does not - but no test can set forceQuitSimulation: it is set by the renderer thread from a key press or a closed window, and there is no binding for it. So the fix of #2616 is checked by hand and stays checked by hand. Either a binding (mbs.systemData or the renderer) or a test-only hook is needed, and which of the two is the decision this step takes (revision2026b step RG4.5, raised 2026-09-26).

    • notes: SC.renderer.StopSimulation(forceQuit=True) stops a simulation from Python as closing the render window does - a running one after its step, and with forceQuit also one that starts later, until mbs.SetRenderEngineStopFlag(False); quitting before or during a simulation is tested.

    • date resolved: 2026-09-28 06:45, date raised: 2026-09-26

  • 1.12.136 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG exudyn.config and exudyn.special are in no stub file (#2541)

    • description: exudyn.config is the run-time settings object (outputDirectory, printToConsole, suppressWarnings, precision) and exudyn.special holds the rarely needed corners; neither the objects nor their C++ classes Config and Special appear in python/exudyn/__init__.pyi, so no IDE completes exudyn.config.outputDirectory. The gap is older than this issue - stubtest simply did not check them while they arrived through a star import, and step R6.2 made them plain package attributes, which exposed it. Both are in the stubtest backlog with this number. The fix is generator work: emit Config and Special like the other bound structures.

    • notes: exudyn.config, exudyn.special and exudyn.experimental are in the stub file, with their parts and members, so an editor completes exudyn.config.outputDirectory and a type checker knows it; six members that were bound but undocumented are documented.

    • date resolved: 2026-09-28 06:45, date raised: 2026-09-19

  • 1.12.135 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG graphics drawn by a graphicsDataUserFunction carry the object number where an item ID belongs, so they are attributed to a wrong system and item (#2726)

    • description: Found by the graphics regression test of revision2026b step RG2.3.3.3, 2026-09-27: the triangles returned by the graphicsDataUserFunction of ObjectGround, ObjectRigidBody, ObjectRigidBody2D and ObjectGenericODE2 appear in SC.renderer.GetGraphicsData() as ‘system 1, type None, index 0’ for object 1. CallUserFunction passes itemNumber to EXUvis::AddBodyGraphicsData, which expects the item ID that UpdateGraphics computes with Index2ItemID(itemNumber, ItemType::Object, systemID); the object number is decoded as a system number. The same ID is what mouse selection shows, so selecting a user-function body reported a wrong item.

    • notes: What a graphicsDataUserFunction draws (ObjectGround, ObjectRigidBody, ObjectRigidBody2D, ObjectGenericODE2) belongs to its object: mouse selection and SC.renderer.GetGraphicsData() name the object; before, the object number was decoded as a system number.

    • date resolved: 2026-09-27 23:56, date raised: 2026-09-27

  • 1.12.134 CHANGE LOW EFF raised by: Claude-JG resolved by: Claude-JG item definitions: classDescription becomes overallDescription and equations becomes detailedDescription (#2724)

    • description: The maintainer, 2026-09-27: ‘the classDescription and the equations fields in the items should be replaced into overallDescription (brief description, summary) and detailedDescription. The reason for the split is that the overall descr. is used for class, etc., while the full description goes into the docs. And there is some auto-generated part before the details.’ Items only; the structures keep classDescription, which has no detailed counterpart there. A rename in the five item definition files, the generators that read them, the item report and definitions/README.md; the generated files do not change. revision2026b step RG13.5.0.1.

    • notes: The item definitions call their two description fields overallDescription (the brief text: the class, the docstring, the paragraph under the heading) and detailedDescription (the full text of the page after its generated part); they were classDescription and equations. The structures keep classDescription.

    • date resolved: 2026-09-27 23:45, date raised: 2026-09-27

  • 1.12.133 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG PlotSensor does not apply the stored window size: the default sizeInches overwrites it (#2723)

    • description: The maintainer, 2026-09-27, V1.12.132: the size of a PlotSensor window is stored correctly by store positions, but a new PlotSensor opens at the default size. __PlacePlotWindow resizes the window to the stored size, and PlotSensor then calls fig.set_size_inches(sizeInches, forward=True) with the default 6.4 x 4.8 inches, which resizes the window again. A size given in the script (sizeInches=…) still wins, as for the dialogs and the render window. revision2026b step RG12.28.

    • notes: PlotSensor opens a window at the size stored for it by store positions; before, the default sizeInches overwrote it. A sizeInches given in the script still wins.

    • date resolved: 2026-09-27 23:36, date raised: 2026-09-27

  • 1.12.132 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG store positions fails with Qt plot windows (QRect is not a geometry string), so no PlotSensor window is stored; the SolutionViewer loses its button column when narrower than its slider (#2722)

    • description: The maintainer, 2026-09-27, V1.12.131 in Spyder (QtAgg): pressing store positions in the settings dialog with two PlotSensor windows open raised ‘TypeError: can only concatenate str (not QRect) to str’ in OnStorePositions, and no window opened, so nothing was stored. A Qt window has geometry() too, returning a QRect, and PlotWindowGeometries and the storing of a plot window took any window with geometry() for tkinter. Second: the SolutionViewer, resized narrower than its 1200-pixel slider asks for, lost its third column (Static, Make mp4): Tk takes the missing width from the weighted columns, down to nothing, and every column right of the first was weighted. revision2026b step RG12.27.

    • notes: The store positions button of the settings dialog lists and stores PlotSensor windows of the Qt backend (Spyder); before, it failed with a TypeError and stored nothing. An interactive dialog that is narrower than its sliders ask for keeps its button and label columns; only the sliders give. The sliders of the SolutionViewer and of AnimateModes reach the last column.

    • date resolved: 2026-09-27 22:04, date raised: 2026-09-27

  • 1.12.131 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG the SolutionViewer: sliders and buttons do not follow the window width, its size cannot be given, and it shows t = 1.0 (#2720)

    • description: Reported by the maintainer against 1.12.128: the SolutionViewer - an InteractiveDialog - does not resize the width of its buttons and sliders with the window; its size cannot be set when it is started, and should be storable in ~/.exudyn/config.json; and a label ‘t = 1.0’ stands above the Start/Stop button whatever is shown. revision2026b step RG12.26.

    • notes: The SolutionViewer and every InteractiveDialog: the sliders and the Run button follow the width of the window, SolutionViewer(…, windowSize=[width, height]) gives it a size, and the viewer no longer shows a time label that stayed at t = 1.0.

    • date resolved: 2026-09-27 19:36, date raised: 2026-09-27

  • 1.12.130 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG store positions stores only the settings dialog, not the render window where it is, the solution viewer or the plot windows (#2719)

    • description: Reported by the maintainer against 1.12.128: the store positions button of the visualization settings dialog, pressed with the solution viewer, the settings dialog, the render window and two sensor plots open, wrote only the settings dialog’s geometry. It does not read where the render window IS - the render state - so the file keeps what view0.window says, which should be updated in the dialog and in ~/.exudyn/config.json; and the plot windows are not stored at all. revision2026b step RG12.25.

    • notes: The store positions button of the settings dialog stores every window that is open: the dialog itself, the other interactive dialogs such as the SolutionViewer, the PlotSensor windows, and the render window where it currently is - which is written as view0.window.renderWindowSize and renderWindowPosition into ~/.exudyn/config.json and into the settings the dialog shows.

    • date resolved: 2026-09-27 19:36, date raised: 2026-09-27

  • 1.12.129 DOCU HIGH EFF raised by: Claude-JG resolved by: Claude-JG RG13: the state of the documentation and the MiniExample of every item (#2715)

    • description: The maintainer, 2026-09-27: each item needs a full documentation and a MiniExample - more than fits into RG3, so a group of its own, RG13, and one of the most important steps before Exudyn 1.13. RG13.1 evaluates the current state: per item, what its definition in definitions/itemDefs*.py carries (class description, the description of the equations, parameters described, output variables, a MiniExample, an image, examples and test models that use it) and what is missing. revision2026b step RG13.1.

    • notes: The state of the documentation of every item is measured by tools/itemDocumentationReport.py and written down in docs/revision/itemDocumentationState.md: the parameters and output variables are described almost without exception, 29 of 97 items have no text on their equations (mostly nodes, markers and sensors), 84 show no figure, and 74 have no MiniExample.

    • date resolved: 2026-09-27 19:08, date raised: 2026-09-27

  • 1.12.128 CHANGE MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the files a run writes by default go into solution/, and scripts that write beside themselves are found (#2718)

    • description: The maintainer, 2026-09-27: examples still write into the folder of the script instead of solution/, because the default solution file name ‘coordinatesSolution’ has no directory. As small API changes are made anyway, this is the time: coordinatesSolutionFileName, solverInformationFileName and restartFileName default to solution/…; a script that sets such a name itself, or reads the solution file back by its old name, has to be changed consistently, and exudev scripts finds both; sensors, the resultsFile of the processing functions and exported images write wherever the script names them, so the scripts of the repository are checked for names without a directory, and the example and test suites show what still lands beside a script. revision2026b step RG12.24.

    • notes: The files a run writes by default are in the directory solution/: the solution file is solution/coordinatesSolution.txt, and the solver information and the restart file are there too, so a run writes nothing beside the script. A script that reads the solution file back as ‘coordinatesSolution.txt’ has to read ‘solution/coordinatesSolution.txt’; exudev scripts finds that, and every file a script names without a directory. The documentation of the environment variables says how Spyder sets an output directory for every run.

    • date resolved: 2026-09-27 18:18, date raised: 2026-09-27

  • 1.12.127 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG the repository’s own examples and test models use what exudev scripts reports: 54 findings in 17 files (#2714)

    • description: Measured 2026-09-27 with exudev scripts (#2712) over python/Examples, python/TestModels and python/MiniExamples, 342 scripts that import exudyn: 54 findings in 17 files. Four are real breaks of scripts that are in no suite - NGsolveGeometry.py, humanRobotInteraction.py and stlFileImport.py call AddEdgesAndSmoothenNormals without graphics., and nMassOscillatorEigenmodes.py uses graphics without importing it. The rest are deprecated forms that still work: exu.StartRenderer/StopRenderer (21), general.drawWorldBasis and other relocated settings (about 20), exu.SolveStatic/SolveDynamic (6), SC.GetRenderState/SetRenderState, renderer.Detach. The examples are what users copy, so they should show the current forms. revision2026b step RG10.1.2.

    • notes: The examples and test models of the repository use the current forms of everything exudev scripts reports: four scripts that failed with a NameError run again (NGsolveGeometry.py, humanRobotInteraction.py, stlFileImport.py, nMassOscillatorEigenmodes.py), and the renderer calls, solver calls and relocated visualization settings are the ones the documentation shows. exudev scripts also reports SC.WaitForRenderEngineStopFlag() and mbs.WaitForUserToContinue().

    • date resolved: 2026-09-27 17:29, date raised: 2026-09-27

  • 1.12.126 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG a static checker for user scripts after the API changes: exudev scripts <folder> (#2712)

    • description: The maintainer, 2026-09-27: RG10.1 is next, needed for teaching next week - ‘a command-line exudev tool for now, only a static checker of folders, looking at all .py files where exudyn is imported’. It parses and never runs, and reports per file and line: names a star import from exudyn no longer provides (np, sin, graphics, …) with the import line, removed names with their replacement (the vector helpers, the GraphicsData aliases, LoadImage), deprecated functions and settings read from definitions/ with what to use instead, removed settings and arguments, and submodules used as exu.<submodule> that import exudyn does not load. revision2026b step RG10.1.

    • notes: exudev scripts <folder> checks the Exudyn scripts in a folder for what changed in Exudyn, without running them: names that a star import from exudyn no longer provides (np, sin, graphics, …) with the import line to add, removed names and settings with their replacement, deprecated functions and settings with what to use instead, and submodules used through exu.<submodule> without their import. A maintainer tool for now (tools/checkUserScripts.py).

    • date resolved: 2026-09-27 16:45, date raised: 2026-09-27

  • 1.12.125 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG PlotImage writes its figure beside the script instead of into exudyn.config.outputDirectory (#2711)

    • description: The maintainer, 2026-09-27: ‘the PlotImage should also get the output directory added.’ PlotSensor saves its figure through OutputFilePath (#2454), so a figure goes where every other output of a run goes; PlotImage wrote fileName exactly as given, so serialRobotKinematicTree.py wrote solution/… into python/Examples/ even under a runner that sets the output directory. revision2026b step RG2.3.5.

    • notes: exudyn.plot.PlotImage saves its figure inside exudyn.config.outputDirectory, like PlotSensor and every other output of a run.

    • date resolved: 2026-09-27 16:45, date raised: 2026-09-27

  • 1.12.123 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG the mass-spring-damper tutorial is the last tutorial in the documentation, and should be the first (#2708)

    • description: The maintainer, 2026-09-27: ‘The mass-spring-damper tutorial shall be the first tutorial in the docs, not the last one.’ It is the section of docs/manual/tutorial.md itself, and the toctree of the other four tutorials stands above it, so it comes after them (4.5 of the PDF). It becomes a page of its own, tutorialSpringDamper.md, first in that toctree. revision2026b step RG3.27.

    • notes: The mass-spring-damper tutorial is the first tutorial of the documentation, on a page of its own.

    • date resolved: 2026-09-27 15:49, date raised: 2026-09-27

  • 1.12.122 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG the first page of the PDF shows the Exudyn logo twice (#2707)

    • description: The maintainer, 2026-09-27: ‘The PDF docs has twice the exudyn logo on page 1. just remove the first one and make the second as wide as the piston engine image (the third image on page 1).’ The second logo and the piston engine are one file, intro2.jpg, so they cannot have one width until they are two files. revision2026b step RG3.3.2.

    • notes: The first page of the PDF documentation shows the Exudyn logo once, as wide as the picture of the piston engine below it.

    • date resolved: 2026-09-27 15:15, date raised: 2026-09-27

  • 1.12.121 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG PlotImage(plot3D=True, trianglesAsLines=False) draws a model of triangles into the limits of its lines (#2706)

    • description: Reported by the maintainer with serialRobotKinematicTree.py: GetGraphicsData() and PlotImage produce a PDF of the line drawing, but with trianglesAsLines=False the 3D model is not visible - ‘a zoom problem or so; also check the coordinates stored in triangles’. Measured: the triangle coordinates are right (the robot spans -0.39..0.69 m); the 30 lines are marker and sensor bases of +-1.5 mm, and the axes limits were +-1.7 mm. ax.autoscale() of a 3D axes takes the lines and not a Poly3DCollection, and plt.autoscale() afterwards would have undone any limits set in the 3D branch. revision2026b step RG2.3.4.

    • notes: exudyn.plot.PlotImage(…, plot3D=True) sets the limits of the plot from everything it draws, triangles included, so a model drawn with trianglesAsLines=False is visible and to scale instead of being zoomed onto its few lines.

    • date resolved: 2026-09-27 15:15, date raised: 2026-09-27

  • 1.12.120 CHANGE LOW EFF raised by: Claude-JG resolved by: Claude-JG the import note about ~/.exudyn/config.json is too long, and the file cannot switch it off (#2705)

    • description: The maintainer, 2026-09-27: ‘NOTE: 0 setting(s) from %USERPROFILE%/.exudyn/config.json, and 8 visualizationSettings for every such structure that is created (exudyn.misc.overrideSettings.Print() for the list; EXUDYN_NO_USER_SETTINGS=1 to ignore them) => this is too long; 0 setting(s) => leave this away; … => and 8 visualizationSettings read from ~/.exudyn/config.json - everything else I would not like to see in the module import output. There shall be a further flag suppressOverrideSettingsWarning in config.json, per default not existing. Also mention in docs.’ revision2026b step RG12.10.1.

    • notes: import exudyn prints one short line when ~/.exudyn/config.json holds settings, e.g. ‘NOTE: 8 visualizationSettings read from ~/.exudyn/config.json’; a count of 0 is left out and the home directory is shown as ~. “suppressOverrideSettingsWarning”: true in the file switches the note off; a setting that cannot be applied is still reported.

    • date resolved: 2026-09-27 15:15, date raised: 2026-09-27

  • 1.12.119 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG 88 bare plan step numbers are left in comments and docstrings, without the word revision2026 (#2703)

    • description: Measured 2026-09-27 at the end of revision2026b step RG3.13.1 (#2649), which removed every mention of ‘revision2026’ from the comments and docstrings of src/, tools/, python/ and definitions/: the same rule (CLAUDE.md rule 8, code cites the issue, not the plan step) is broken 88 more times in 39 files by step numbers written WITHOUT the plan’s name - ‘step R6.3.8’, ‘the rule RG6.2.11 wrote down’, ‘dies with the LaTeX branch in R7.1.7’, ‘measured before RG9.1’. They were out of RG3.13.1’s measure, which counted ‘revision2026’. The same three passes apply - a parenthetical keeps its issue, a two-line reference is rejoined, the rest gets a sentence - with the same proof that no code changed: the Python AST without docstrings and the C++ tokens without comments are identical. revision2026b step RG3.13.2.

    • notes: The comments and docstrings no longer cite revision plan steps by bare number: 87 of them cite the issue or nothing, and a dozen that promised work the plan had already done describe what is there. Only comments, docstrings and nothing else changed.

    • date resolved: 2026-09-27 13:51, date raised: 2026-09-27

  • 1.12.118 BUG LOW EFF raised by: Claude-JG resolved by: Claude-JG PlotImage(plot3D=True) fails with every current matplotlib, and its 2D and 3D coordinates are shifted wrongly (#2701)

    • description: Found in revision2026b step RG2.3.1 (#2700), measured with matplotlib 3.11.0: PlotImage(…, plot3D=True) raises TypeError: FigureBase.gca() got an unexpected keyword argument ‘projection’ - fig.gca(projection=’3d’) was removed in matplotlib 3.6, so the 3D mode, which is the only one that draws triangles, has not worked for years; both NGsolve examples that use it do so in an if False block. Two more defects in the same function: the 2D branch adds the translation p0[0] to y and z as well as to x, and the 3D branch ends every line segment at z[j] instead of z[j+1]. Neither shows with the default HT, which is why nobody saw them. Fix: fig.add_subplot(projection=’3d’), p0[1] and p0[2], z[j+1], and a test that draws in 3D. revision2026b step RG2.3.2.

    • notes: exudyn.plot.PlotImage(…, plot3D=True) works with current matplotlib again and uses the azim and elev it is given; a translation in HT moves each coordinate by its own component; and a figure drawn with the non-interactive Agg backend is no longer shown.

    • date resolved: 2026-09-27 13:46, date raised: 2026-09-27

  • 1.12.117 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG index.md and pdfIndex.md are two hand-written tables of contents that must agree (#2697)

    • description: The maintainer, 2026-09-27: ‘index.md and pdfIndex.md: I see that there are two files, which have different structure. Maybe this is necessary, but it is really brittle and requires a clear indication to sync the toctrees. The main difference - if I remember correctly - are the examples/models/etc. not to be included in PDF, and a different front page. The rest should be practically identical, if possible.’ Measured on 2026-09-27, and it is more than that: index.md has 25 toctree entries and pdfIndex.md has 23. Only in index.md: README, docs/manual/performanceErrors, docs/generated/examples/examplesIndex, docs/generated/testModels/testModelsIndex. Only in pdfIndex.md: docs/manual/commandLine, docs/manual/resultsMonitor - which in the HTML are nested under introductionAdvanced instead. And the ORDER of the entries they share is not the same. So the examples and the front page are the intended differences; performanceErrors missing from the PDF and the different nesting and order are not, and nothing tells anybody when they drift again. Options for the step: generate pdfIndex.md from index.md with a declared list of exclusions (then one file is the truth and the other is a build product, which also needs a rule for the front page); or keep both and add a check to tools/ that compares the two entry lists against a declared difference, which is cheap and catches drift on the next commit; or accept the difference and document it at the top of both files. revision2026b step RG3.26.

    • notes: index.md and pdfIndex.md stay two hand-written files, and tools/checkTocs.py - part of exudev generate –all-checks - requires them to list the same pages in the same order, apart from the pages declared as HTML only (README, the examples and the test models). A page added to one and not the other fails the check.

    • date resolved: 2026-09-27 13:39, date raised: 2026-09-27

  • 1.12.116 DOCU LOW MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG 235 references to the revision plan are left in comments, each inside a sentence (#2649)

    • description: What RG3.13 could not do mechanically. Of the 887 mentions of revision2026 outside docs/revision, 652 were parentheticals or appended clauses and could be removed by rule, keeping the issue number where there was one. The remaining 235 in 149 files are inside a sentence - ‘step R4.3 is moving outputs from the old generators to separate emitters’, ‘the name the function had between steps R8.7 and R8.3.4’ - and each needs a sentence written for it, which a pattern cannot do: an attempt that allowed the phrase to wrap across two comment lines matched from a code line into a comment and merged prose into code (tools/generators/generatorPaths.py:35), so that pass was withdrawn and every file rebuilt from its committed content with the line-based rules only. None of the 235 is in a published page; they are comments in src/, tools/ and python/, where the rule is the older one of CODING_STYLE 6.1 - a comment cites the issue - so this is tidiness rather than a defect.

    • notes: The comments and docstrings of the code say what the code does and cite an issue where they cite anything: 330 references to the revision plan in 177 files are gone, and the published pages of the Python utilities with them. Nothing but comments, docstrings and three printed messages changed, which was checked for every file.

    • date resolved: 2026-09-27 11:37, date raised: 2026-09-24

  • 1.12.115 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG the PDF lacks the chapter on performance and errors, and orders its user manual differently from the HTML (#2702)

    • description: Measured for #2697: revision2026b step RG3.15 (#2657, #2661) restructured the user manual in index.md - a new chapter performanceErrors, and the command line and the results monitor moved under Advanced topics - and pdfIndex.md was not changed with it. So the PDF has no chapter ‘Performance, errors and solver failures’, lists the command line and the results monitor as chapters of their own, and puts Advanced topics before the Tutorial. This is the part of #2697 that is a defect rather than a decision: pdfIndex.md takes the user-manual order of index.md, and what remains different is what is meant to (README, the examples and test models, the front page). How to keep the two from drifting again stays #2697. revision2026b step RG3.26.1.

    • notes: The PDF documentation has the chapter ‘Performance, errors and solver failures’ again, and its user manual is in the same order as the HTML one, with the command line and the results monitor under Advanced topics.

    • date resolved: 2026-09-27 11:21, date raised: 2026-09-27

  • 1.12.114 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG a tab instead of a backslash puts “exttt{…}” on three pages of the Symbolic manual (#2683)

    • description: Three descriptions of definitions/pybindSymbolic.py contain a TAB followed by ‘exttt{…}’ where ‘texttt’ was meant: someone wrote a backslash-t in a string that was not raw, and the tab is now in the source. The Symbolic page of the reference manual prints it as it is, on lines 11, 179 and 271 of docs/generated/cInterface/Symbolic.md: ‘turing on recording by using <tab>exttt{exudyn.symbolic.SetRecording(True)}’. Inline code in a description is a backtick span (definitions/README.md, ‘Writing a description’), so the fix is `exudyn.symbolic.SetRecording(True)`. Two typos are in the same sentences and in the paragraph above them: ‘turing’ for ‘turning’, three times, and ‘veryfy’ for ‘verify’. Why no check caught it: checkDefinitions rejects a LaTeX command outside mathematics by looking for a backslash, and there is no backslash left - the tab ate it. A check for a raw tab inside a description would find this class of defect; that is the part worth deciding rather than just fixing the three lines.

    • notes: The Symbolic page of the reference manual no longer shows ‘exttt{exudyn.symbolic.SetRecording(True)}’ in the introductions of Real, Vector and Matrix: it is a code span, and four typos in the same paragraphs are corrected. tools/checkDefinitions.py rejects a TAB in a description, which is what a backslash-t in a literal that was not raw turns into - and which the check for LaTeX commands cannot see, because the backslash is gone with it.

    • date resolved: 2026-09-27 11:14, date raised: 2026-09-26

  • 1.12.113 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the graphics data can be read as a dictionary without a window, and the TXT image export is removed (#2700)

    • description: The maintainer, 2026-09-27: ‘yes do that and totally remove the .txt graphics export’. SC.renderer.GetGraphicsData() returns the drawing elements of the scene - lines, spheres, circles, texts and triangles, each with the item that drew it - built with the renderer inactive, the path RedrawAndGetImage(True) already uses, so a test can ask for it with no window. It is the oracle of the graphics regression suite (RG2.3, #2582): counts per item are exact, coordinates are compared with a tolerance. The TXT export of exportImages (saveImageFormat=’TXT’ and the four saveImageAsText* settings) needed the running OpenGL renderer, dropped the item of every primitive, spheres and texts, and is removed together with its reader exudyn.plot.LoadImage. revision2026b step RG2.3.1.

    • notes: SC.renderer.GetGraphicsData() returns the drawing elements of the scene - lines, spheres, circles, texts and triangles - as numpy arrays, each with the item that drew it (system, item type, index), and needs no render window, so a test can check what a model looks like. exudyn.plot.PlotImage draws what it returns, e.g. PlotImage(SC.renderer.GetGraphicsData(), fileName=’model.pdf’). The text export of an image is removed: saveImageFormat ‘TXT’, the four exportImages.saveImageAsText settings and exudyn.plot.LoadImage.

    • date resolved: 2026-09-27 11:09, date raised: 2026-09-27

  • 1.12.112 CHANGE LOW EFF raised by: Claude-JG resolved by: Claude-JG the latexSymbol family of the generators is called mathSymbol (#2699)

    • description: The maintainer, 2026-09-27, chose option B of revision2026b step RG3.24.4: latexSymbol, ExtractLatexSymbol, stringLatexSymbol and addLatexSign become mathSymbol, ExtractMathSymbol, mathSymbolString and mathSign. The name says what the thing is - the symbol of a parameter, the leading dollar-sign span of its description - and the markup stays the converter’s business. Gate: the regeneration is a no-op. revision2026b step RG3.24.4.

    • notes: The generator names for the symbol of an item parameter are mathSymbol, ExtractMathSymbol, mathSymbolString and mathSign: they name what the thing is, the leading dollar-sign span of a parameter description, rather than its markup. The generated code and documentation are unchanged.

    • date resolved: 2026-09-27 10:54, date raised: 2026-09-27

  • 1.12.111 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG The simulation settings section does not mention that the settings can be browsed before writing a model (#2659)

    • description: The Simulation settings section of Exudyn Basics explains the substructures and how to assign values, and says nothing about looking a setting up. Since revision2026b step RG6.2 there is ‘python -m exudyn dialogs sim’, which opens the same tree the renderer’s V key opens, with no model and no renderer - which is exactly what somebody reading this section for the first time needs. One sentence, with a link to the command line chapter; the same applies to ‘dialogs vis’ where the visualization settings are introduced.

    • notes: The two sections that introduce a settings structure now say how to look a setting up: the Simulation settings section of Exudyn Basics names ‘python -m exudyn dialogs sim’ with CTRL-F to find a setting and copy line to take the statement that sets it, and the visualization settings dialog section names ‘python -m exudyn dialogs vis’ beside the V key, which needs a running render loop. Both link to the command line chapter.

    • date resolved: 2026-09-27 09:02, date raised: 2026-09-25

  • 1.12.110 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG The generator API still says Latex where it writes Markdown (#2681)

    • description: The maintainer, 2026-09-26: DefLatexDataAccess and similar Latex commands need to be renamed consistently; search for latex, rename where it is clear (Markdown) and suggest options where it is not. Measured the same day over tools/generators/ and definitions/: 28 files carry the word. The declaration API every definition file uses - DefLatexDataAccess (64 uses), DefLatexStartTable (32), DefLatexFinishTable (27), DefLatexOperator (17), DefLatexStartClass (13) - writes Markdown and has done since RG3.14; PyLatexRST (18 uses) writes Python, a stub and Markdown and neither LaTeX nor RST. Names that describe real LaTeX stay: GetTypesStringLatex and Str2Latex feed mathematics and C++ comments, and latexToMarkdown.py is named after what it converts from. The open kind is latexSymbol and its family, the dollar-symbol of an item parameter, which IS LaTeX inside Markdown. A rename of 64 call sites changes no output, so the gate is that the regeneration stays a no-op.

    • notes: The generator API no longer says Latex where it writes Markdown: the declaration calls the definition files are written in are DefDataAccess, DefStartTable, DefFinishTable, DefOperator and DefStartClass, the class that collects the pybind code, the stub and the documentation of one declaration run is DeclarationWriter, and GetTypesStringLatex and Latex2RSTlabel are GetTypesStringDocu and MarkdownLabelName - 184 occurrences. What is named after real LaTeX keeps its name: Str2Doxygen, latexToMarkdown.py, LatexText2Markdown, ToLatex, CleanLatex, RemoveLatexCommands. Reading every occurrence also removed 55 lines that nothing runs - a dead function writing LaTeX lists, commented-out longtables, three unread locals - and corrected a field name in definitions/README.md that exists nowhere in the code. The regeneration writes byte-identical files, which was the gate. The latexSymbol family is not renamed: it names a real dollar-sign symbol and the options go to the maintainer (revision2026b step RG3.24.4).

    • date resolved: 2026-09-27 08:12, date raised: 2026-09-26

  • 1.12.109 EXTENSION NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the plot windows of PlotSensor cannot be stored while the renderer is still open (#2698)

    • description: The maintainer, 2026-09-27, on revision2026b step RG12.12, which stores a plot window’s position by its sequence: ‘how could storing of positions work? the sensor windows are opened at a point when the renderer is usually already stopped (though this could also be done). Possibly there should be a script then from exudyn.misc.overrideSettings which would grab the according PlotSensor windows (which are matplotlib); possibly the matplotlib figures need to be stored in an internal list - either in plot.py or in exudyn.sys, cleared when doing closeAll; the figure references should get invalid on closing (that’s what I think), and thus a function could then try to grab the current figure’s positions and sizes and store them, allowing to reuse the size in the next PlotSensor commands. The positions could be stored either with the visualizationSettings dialog itself. In this case, the user must open the sensors before closing the render window.’ What RG12.12 built: a plot window is PLACED where the window of the same sequence number was left, and its position is stored when it closes if PlotSensorDefaults().storeWindowPositions is on. What the maintainer is pointing at is the moment of storing: a close handler fires per window, whereas a user wants to arrange several windows and then store them all at once - and the settings dialog, which is the place where storing happens for everything else, is usually gone by then because the renderer has stopped. So the step is a FUNCTION a script or a dialog can call - ‘store where the plot windows are now’ - which needs the list of live figures that the maintainer describes: kept in plot.py, cleared by closeAll, and pruned of figures that have been closed. revision2026b step RG12.23.

    • notes: exudyn.plot.StorePlotWindowGeometry() stores where the plot windows are now, while they are open, and returns how many it stored - the call for a user who has arranged several plots after the renderer has stopped, when the settings dialog and its store positions button are gone. The windows are remembered by their sequence, the order PlotSensor made them in, and PlotSensor(…, closeAll=True) starts that order over; a window that has been closed since is skipped and forgotten. A stored window now comes back with its size as well as its position, and the position still only if it would be reachable on the current screen.

    • date resolved: 2026-09-27 07:39, date raised: 2026-09-27

  • 1.12.108 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG Pages that still describe the state before a step that is already done (#2673)

    • description: The maintainer, 2026-09-24: the documentation of the steps that are done, where a page still describes the state before one of them. Six weeks of revision2026 and revision2026b changed behaviour that hand-written pages describe - the renderer keys, the settings dialogs, the output directory, the star imports, the command line, the results monitor - and a page is only corrected when someone walks past it. The first job of the step is to LIST them: what a page claims against what the code does, per chapter, because nothing can be planned before that list exists. [2026-09-27, Claude-JG]: Asked for by the maintainer on 2026-09-27: ‘I don’t understand any more what was the reason, and what is the content (which exact audit - there are a couple of open tasks).’ THE REASON: they asked on 2026-09-24 for the hand-written documentation to be checked against what the code now does. Six weeks of revision2026 and revision2026b changed behaviour that docs/manual/ pages describe, and a page is corrected only when somebody walks past it, so some pages still describe how Exudyn worked in August. THE CONTENT, which is one audit and not several: docs/manual/ only - not docs/generated/, which is rewritten from definitions/ and cannot be stale, and not docs/dev/ or docs/howTo/, which describe the workflow rather than the behaviour. The subjects are the ones the closed issues name: the renderer keys and the dialogs, the output directory, the star imports and exudyn.config, the command line, the results monitor, the override settings, the deprecated names, and the PlotSensor defaults. THE METHOD, and the reason it is cheap: docs/manual/revisions.md is the list of what changed for a user, and every closed issue of the two revisions carries its release note - so this is a comparison of two lists against the pages, not a re-reading of the manual. THE FIRST DELIVERABLE is the LIST: per page, what it claims against what the code does. Nothing else can be planned before it exists, and it decides whether the rest is one commit or five. revision2026b step RG3.21.

    • notes: The manual no longer teaches the deprecated module-level solver calls: solver.md, the tutorial, the FAQ and the introduction say mbs.SolveDynamic(…), mbs.SolveStatic(…), mbs.ComputeLinearizedSystem(…) and mbs.ComputeODE2Eigenvalues(…), which is what the examples use and what does not warn. Three wrong identifiers were corrected (among them openGL.raytracer.imageSizeFactor), and the settings dialog page now describes all four of its buttons and what each one stores. Measured: of 496 identifiers named in the manual 3 were wrong, and of 129 settings paths none was deprecated.

    • date resolved: 2026-09-27 07:39, date raised: 2026-09-26

  • 1.12.107 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG The results monitor exits when the file does not exist yet, and the documentation says it waits (#2672)

    • description: Reported by the maintainer, 2026-09-26: StartResultsMonitor (revision2026b step RG11.3, #2670) does not work as promised. The cause is in MonitorResults: inside the ‘while fileName != :’ loop it tests ‘if not os.path.exists(fileName): print(ERROR: file not found); return None’ BEFORE WaitForData, and WaitForData only waits for a data ROW in a file that already exists. A monitor started before the solver - which is the point of StartResultsMonitor, and what springDamperTutorial.py and 3SpringsDistance.py both do - therefore prints an error and exits at once. The docstring of StartResultsMonitor and docs/manual/resultsMonitor.md both say the file does not have to exist yet, which is false. The fix is to move the existence test into the waiting loop so that –wait 0 waits for the file to appear, and to decide what –wait N means for a file that never appears.

    • notes: MonitorResults waits for the file to appear, which its documentation had promised all along. WaitForData waits for the file, then for the header, then for the first row; the caller’s existence test - which returned ‘file not found’ before any waiting could happen - now applies only to –once, which plots what exists and returns, so waiting there would be waiting for nothing. waitTimeout keeps its meaning and gains the file: 0, the default, waits without limit, which is what a monitor started before the solver needs, and N gives up after N seconds with a message naming the file. What is being waited for is announced, naming the file, because waiting forever for a file that will never appear is what a typo in the name looks like. So StartResultsMonitor works as its docstring says, and the two examples that start a monitor before the solver do what they show. Four tests, one of which writes the file from another thread after 0.4 s - the solver’s part - and asserts that the monitor picked it up.

    • date resolved: 2026-09-27 01:19, date raised: 2026-09-26

  • 1.12.106 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the results monitor takes the focus and comes to the front on every update (#2696)

    • description: The maintainer, 2026-09-27: ‘resultsMonitor: always takes focus (so one cannot use the control panel); always in front of terminal => this should not be the case, except optionally alwaysOnTop.’ The cause is plt.pause, which the update loop calls once per update period: it calls show(block=False) every time, and for the TkAgg backend show() does deiconify() and lift() - so the window was raised and given the focus one to twenty times a second, which is why the control panel beside it could not be typed into. canvas.start_event_loop(seconds) waits and processes events and does nothing else. The ‘except optionally’ half is a new monitor setting, alwaysOnTop (default False), which sets the window above the others without taking the keyboard - and, being a monitor setting, is stored in the resultsMonitor section of ~/.exudyn/config.json like the rest. There is a –always-on-top flag for the command line. revision2026b step RG12.22.

    • notes: The results monitor no longer takes the keyboard focus and no longer comes to the front while it updates. The cause was plt.pause in the update loop: it calls show(block=False) every time, and TkAgg’s show() does deiconify() and lift(), so the window was raised and focused once per update period - which is why the control panel beside it could not be typed into. canvas.start_event_loop(seconds) waits and processes events and does nothing else, with plt.pause as the fallback for a backend that has no event loop. The ‘except optionally’ half is a new monitor setting alwaysOnTop, default False, stored in the resultsMonitor section of ~/.exudyn/config.json like the rest, with –always-on-top on the command line; it puts the window above the others and still does not take the keyboard. It works with the tkinter backend and says so otherwise, because a Qt window would need a Qt enum and Exudyn does not depend on a Qt binding. Two tests and a line in the manual.

    • date resolved: 2026-09-27 01:08, date raised: 2026-09-27

  • 1.12.105 CHANGE NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG python -m exudyn info prints the home directory of whoever ran it (#2695)

    • description: The maintainer, 2026-09-27: ‘python -m exudyn info: you mention that this shall be used when submitting issues. But I believe that it should either not show the user path (replace user path with something like %USERPROFILE%; there could be an option –showPaths, which shows the real paths’. The output names the package directory and the Python executable, both of which are usually under the home directory and therefore carry an account name - and the command’s whole purpose is to be pasted into an issue. The home directory is shown as %USERPROFILE% on Windows and as ~ elsewhere, which is also what a reader would type themselves, and –showPaths gives the real ones for a problem that is about a path. revision2026b step RG12.21.

    • notes: ‘python -m exudyn info’ shows the home directory as %USERPROFILE% (Windows) or ~ instead of the real path, in the package location, the Python executable and the output directory - the command exists to be pasted into an issue, and those paths carried the account name of whoever ran it. –showPaths prints them as they are, for a problem that is about a path. Two tests: nothing of the home directory in the normal output, and all of it with the flag.

    • date resolved: 2026-09-27 01:08, date raised: 2026-09-27

  • 1.12.104 CHANGE NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG a render window geometry in the settings and in the config file can conflict silently (#2694)

    • description: The maintainer on 2026-09-26, seeing where RG12.16 leads: ‘The mechanism for the positions and sizes probably needs a further refinement, in particular for the render window: it has a position and size in the view settings; if size or position are different from default values, and the .exudyn/config.json file also names such quantities, the non-default visualizationSettings parameters should win - but there should be a separate warning ONLY if there are conflicting settings (not if they are equal). This problem should not happen for other dialogs, as they have only one position for storage and the manual position commands would override the global ones. When storing render window positions and size, the values should also be updated in the current visualizationSettings, otherwise a re-open would not have the just stored positions.’ The render window is the only window whose geometry lives in TWO places - the settings structure and, because those settings are ordinary ones, the visualizationSettings section of the file - and they are applied at different moments: the file at construction, a script afterwards. So a script silently wins today, which is the wanted outcome, but a user whose file says something else is told nothing. What the step has to work out: WHERE the comparison happens (when the renderer starts is the only moment both are known), what counts as ‘different from default’ for a pair of integers, how to warn once rather than per view and per run, and the second half - that storing the geometry updates the live visualizationSettings, so that reopening the renderer in the same session uses what was just stored rather than what the structure still says. revision2026b step RG12.20.

    • notes: The render state carries currentWindowPosition beside currentWindowSize, read from GLFW wherever the size is - every Render - rather than through a window-move callback, so that one place knows where the window is. It is in SC.renderer.GetState(), and SetState writes it AND view*.window.renderWindowPosition, exactly as it has always done for the size: the maintainer’s ‘when storing render window positions and size, the values should also be updated in the current visualizationSettings, otherwise a re-open would not have the just stored positions’. The write-back of #2689 reads the state instead of asking GLFW itself. And the conflict is said out loud: the render window is the only window whose geometry lives in two places - the view settings and, because those are ordinary settings, the visualizationSettings section of the file - applied at different moments, so a script already wins and nobody was told. SC.renderer.Start() now warns ONCE per process, naming both values, and only when they really differ; it is silent when they agree, which is the normal case for someone who stored the geometry and has not touched it since. It runs before the suppressRenderer guard, because the conflict is between the file and the session whether or not a window opens, and with no settings file it returns at once. Documented in the Exudyn module page and in the render state list of docs/manual/GUI.md.

    • date resolved: 2026-09-27 00:48, date raised: 2026-09-27

  • 1.12.103 CHANGE NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the settings dialog should store settings and positions with two separate buttons (#2693)

    • description: The maintainer on 2026-09-26, after using the store button of revision2026b step RG12.11: ‘I am still thinking, how the workflow for storing the window positions and sizes could be. The store settings means store positions at the same time. I would like to opt for two buttons, one for the settings and one for the positions.’ Today one button writes both the visualizationSettings that differ from the defaults and the geometry of the dialog itself, and the confirmation window says so - but they are two decisions: ‘I like this look’ and ‘I like this window here’. Two buttons say that, and each one’s confirmation shows only what it writes. What has to be decided with it, because it stops being obvious once the buttons are separate: which of them stores the RENDER window geometry, which since #2689 is part of the visualizationSettings (view*.window.renderWindowSize and renderWindowPosition) and so would go with the settings button although it is a position; and whether the positions button also stores the geometry of the other dialogs it knows about, or only its own. revision2026b step RG12.19.

    • notes: The settings dialog has two buttons: ‘store settings’ writes the visualizationSettings that differ from the defaults, and ‘store positions’ writes the size and position of the dialog itself. Each shows exactly what it will write, with store/cancel, before writing. The geometry of the RENDER window rides along in the settings button, which is the maintainer’s decision: view*.window.renderWindowSize and renderWindowPosition are ordinary visualizationSettings, ‘it is the straightforward way and becomes now natural, because it is only stored if it differs from default’.

    • date resolved: 2026-09-27 00:48, date raised: 2026-09-27

  • 1.12.102 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the documentation does not say that a script can place a dialog (#2688)

    • description: The maintainer asks whether the dialog positions can be set inside a script. They can: exudyn.misc.overrideSettings.StoreDialogGeometry(name, size, position) is public and writes the dialogs section, and DialogKey(name) is the key it uses - but nothing in the documentation says so, and the section about the override settings only describes the file. An example belongs beside it, in the generated Exudyn module page: placing the visualization settings dialog from a script, and the note that the size comes back always while the position is used only when the window would still be reachable. Wait for revision2026b step RG12.13, because a placement that nothing reads back is not worth an example. revision2026b step RG12.15.

    • notes: A script can place a dialog, and the Exudyn module page says how: overrideSettings.StoreDialogGeometry(name, size, position) with the dialog’s title, which is what DialogKey turns into the key; the size comes back always and the position only if the window would still be reachable. The render window is not a dialog and is placed by its own two settings, view*.window.renderWindowSize and renderWindowPosition, with the note that the position is that of the OpenGL area rather than the title bar - so a small value hides part of the title bar and 0 hides it completely, which is a way to have a view without one. And the footnote the maintainer asked for: writing into exudyn.special.overrideSettings directly works, holds for one run and does not touch the file, and is not the recommended way because nothing checks what is put there - a value of the wrong shape is simply not used.

    • date resolved: 2026-09-27 00:08, date raised: 2026-09-26

  • 1.12.101 EXTENSION NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG the render window and the SolutionViewer do not remember their size and position (#2689)

    • description: Asked for by the maintainer on 2026-09-26: both should be able to store position and size, as the settings dialogs do since revision2026b step RG12.5.3. The render window has visualizationSettings.view*.window.renderWindowSize, which is an INITIAL size and is not written back, and it has no position at all: GlfwClient.cpp never calls glfwSetWindowPos or glfwGetWindowPos (measured). So this needs C++ - reading the position when the window closes and setting it when it opens - and a section of ~/.exudyn/config.json to keep it in, which is the mechanism exudyn.special.overrideSettings already is. Several views exist, so each needs its own entry. The SolutionViewer is the cheaper half: its dialog is a tkinter window like the settings dialogs, so it can use RestoreWindowGeometry and StoreWindowGeometry once revision2026b step RG12.13 makes those work without the renderer flag. The reachability rule of RG6.2.11 applies to both: the size comes back always, the position only when the window would still be reachable. revision2026b step RG12.16.

    • notes: The render window and the dialogs of exudyn.interactive remember their size and position. The render window: view*.window.renderWindowPosition places it (glfwSetWindowPos, which GlfwClient.cpp never called), view*.window.useRenderWindowPosition says whether to, and view*.window.storeRenderWindowGeometry writes back where the window was when it closes - the size, the position and the flag - so that ‘store settings’ in the visualization settings dialog, or overrideSettings.Store(SC), keeps a render window where it was left. All three are ordinary settings, one set per view, so the settings file carries them with nothing added. The write-back is off by default, because a settings structure that changed by itself would make ‘diff to default’ report a window position after every run - the same reason dialogs.storeDialogPositions exists. The (-1,-1) sentinel the maintainer proposed could not be used: the settings dialog refuses a negative IndexArray, the type the position shares with the size, and that rule is the only guard there is - the C++ accepts a negative sensor number and a negative window size, both measured. The SolutionViewer: its window is an InteractiveDialog, and so are the mode shapes and an interactive simulation, so all of them now restore and store themselves under their own title through RestoreWindowGeometry/StoreWindowGeometry - the same mechanism and the same ~/.exudyn/config.json section as the settings dialogs, with the reachability rule of RG6.2.11 and the storeDialogPositions flag deciding whether a dialog stores itself on closing. RestoreWindowGeometry leaves the size to the layout when nothing is stored, which a dialog whose size is computed from its widgets needs. The reference of parameterConversionTest was rewritten twice, for the two new settings.

    • date resolved: 2026-09-26 23:38, date raised: 2026-09-26

  • 1.12.100 EXTENSION NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the override settings are read only at import, so a changed file needs a new session (#2687)

    • description: The maintainer, testing 1.12.95 in Spyder: the settings file is only picked up after restarting the console, which makes storing something look as if it had not worked. ‘import exudyn’ reads the file once, and a second import of an already imported module does nothing, so a file written by the store button - or edited by hand - has no effect until the interpreter is restarted. Spyder keeps the kernel, which is where this is met. Wanted: a function that re-reads the file into exudyn.special.overrideSettings and applies what can be applied at once, so that a session can pick up what it has just stored, and a line in the documentation saying which settings need a restart and why. One thing to decide in the step: the subclasses that apply the visualizationSettings to every new structure are installed at import and ONLY when the file holds such a section, so a reload cannot make them appear - either they are installed whenever the file could hold one, or the reload installs them, or the documentation says that this part needs a restart. revision2026b step RG12.14.

    • notes: exudyn.misc.overrideSettings.Reload() reads ~/.exudyn/config.json again into exudyn.special.overrideSettings and applies what can be applied, so a file edited while a session runs - or stored by another session - takes effect without restarting the interpreter. That is the Spyder case: import exudyn reads the file once and importing an already imported module does nothing, which made a stored setting look as if it had not been stored. The store is emptied first, so a section removed from the file is gone from it; the config section is applied; and the visualizationSettings reach every structure created afterwards - INCLUDING the case where the file had none at import, which is when the reload is what installs the wrapped constructors. A reload does not undo: a setting that already reached exudyn.config, and a structure that already exists, keep what they were given, and that is documented. The step was much smaller than it was raised, because the maintainer noticed that StoreSection already updates the store as well as the file, and because the wrappers close over that same dictionary - so a store already takes effect in its own session. Three tests and the documentation of the workflow under the Exudyn module.

    • date resolved: 2026-09-26 23:02, date raised: 2026-09-26

  • 1.12.99 CHANGE NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the renderer link is an untyped entry of exudyn.sys and should be a member on the C++ side (#2692)

    • description: Asked for by the maintainer on 2026-09-26: ‘exudyn.sys[“currentRendererSystemContainer”] stores the currently active SystemContainer (as an old, dirty hack), as glfw can only hold one at a time. => however, we can just store it on the C++ side of the code - module-wide, like in special.currentRendererSystemContainer. => this would immediately return the correct link, similar to the current GUI function.’ The entry is written by MainSystemContainer.cpp (AttachToRenderEngineInternal sets it to the pointer, Reset sets it to 0) and read by three places in exudyn.misc.GUI, one of which has to check what class it holds - because a dictionary entry can hold anything, which is exactly how #2691 happened: a Python subclass under the module’s own name made the isinstance False and every dialog that needs the container stopped working, in silence. A typed member cannot be wrong about its own type. To decide in the step: exudyn.sys[‘currentRendererSystemContainer’] is public and documented, and basicUtilities filters it out of the variables it prints, so whether it stays as a deprecated alias or goes needs a word; and the lifetime question of #2679 applies - a global holding a Python object must not release it after the interpreter has finalized, which is why EPyUtils::OverrideSettings() is allocated once and never freed. revision2026b step RG12.18. [2026-09-26, Claude-JG]: Correction from the maintainer: ‘exu.sys[“currentRendererSystemContainer”] is an internal (“sys”) variable, and never intended to be used by any user!’ So the question this issue raised about a deprecated alias does not exist: exudyn.sys is reserved by the system - its own documentation says so - and the entry can simply move to the C++ side with no alias, no deprecation and no note in the revisions chapter. What is left to decide is only the lifetime question: a global that holds a Python object must not release it after the interpreter has finalized.

    • notes: The renderer link is exudyn.special.currentRendererSystemContainer, a pointer the C++ side holds (MainSystemContainer::currentRendererContainer) and hands to Python by casting it, so a script gets the very SystemContainer it created and nothing keeps a Python reference that would have to be released after the interpreter finalized. exu.sys[‘currentRendererSystemContainer’] is gone. It also fixes something the dictionary entry never did: the pointer is cleared in Reset(), which the destructor calls, so a destroyed container leaves None instead of a link to freed memory - the entry was only cleared by an explicit detach, which is why the reader had to be guarded against a dead object twice (#2623, #2676). And the three readers in exudyn.misc.GUI became one: GetExudynDisplayScaling and the dialog’s redraw both call GetRendererSystemContainer() now, so one place knows how the link is found and the guard applies to all of them. Nothing else in the package, the examples or the models used the entry - checked - and basicUtilities.ClearWorkspace no longer takes the renderer away from its container as a side effect of clearing exudyn.sys.

    • date resolved: 2026-09-26 22:15, date raised: 2026-09-26

  • 1.12.98 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG a settings file with visualizationSettings kills the V key and the right-mouse dialog (#2691)

    • description: Reported by the maintainer against 1.12.96: with a ~/.exudyn/config.json holding a visualizationSettings section, pressing V in the render window opens no dialog and the console says ‘problems with the SystemContainer, probably not attached to the renderer yet’. Without the file everything works. Reproduced and measured: revision2026b step RG12.10 installs a Python SUBCLASS as exudyn.SystemContainer when that section exists, and GUI.GetRendererSystemContainer() does isinstance(guiSC, exudyn.SystemContainer) on what the C++ side stores - MainSystemContainer.cpp does exudynModule.attr(‘sys’)[‘currentRendererSystemContainer’] = this, a POINTER, which pybind casts to an object of the COMPILED class. isinstance of that against the subclass is False, so the probe returns None and every dialog that needs the container does nothing. This is the THIRD thing the subclass broke in two days: DefaultSettingsDictionary constructed it and reported the overrides as the defaults (#2684), an isinstance of mine in the settings dialog stopped recognising SC.visualizationSettings (#2685), and now this. The mechanism has to stop changing what a class is: the constructor of the compiled class is wrapped IN PLACE instead (measured: pybind11 heap types allow it), and then no name and no isinstance moves. The defaults then cannot be constructed any more - every construction applies the overrides - so they are snapshotted at import before the wrapper is installed, which is what was decided for exudyn.config in #2685. Two more things came with it, both asked for by the maintainer: GetRendererSystemContainer() said NOTHING when it failed, which is why this took a reproduction rather than a message - it now says once per process what went wrong, while the normal ‘no renderer’ answer stays quiet; and ShowVisualizationSettingsDialog printed ‘ERROR: ShowRightMouseSelectionDialog: …’, a copy-paste error that named the wrong function in the one message a user sees. revision2026b step RG12.17.

    • notes: A settings file holding visualizationSettings no longer kills the dialogs. The cause was the Python subclass that RG12.10 installed as exudyn.SystemContainer: GUI.GetRendererSystemContainer() does isinstance() against that name on the object the C++ side stores as a pointer, which is of the COMPILED class, so the probe found nothing and the V key and the right-mouse dialog did nothing. The constructor of the compiled class is now wrapped IN PLACE instead of subclassed, so no name and no isinstance moves - the third thing that subclass broke in two days, and fixing the callers one at a time cannot work because the set of places that ask what a class is includes every user script. The defaults, which can then no longer be constructed, are snapshotted at import before the wrapper, as the defaults of exudyn.config are. Two things the maintainer asked for came with it: GetRendererSystemContainer() says once per process what went wrong instead of returning None in silence (the normal ‘no renderer’ answer stays quiet), and ShowVisualizationSettingsDialog no longer prints ‘ERROR: ShowRightMouseSelectionDialog’, a copy-paste error that named the wrong function in the one message a user sees. The ‘strange position coordinates’ [-10, 0] are not a defect: Windows reports the invisible resize border, and the reachability rule already allows screenX-16 for exactly that.

    • date resolved: 2026-09-26 21:00, date raised: 2026-09-26

  • 1.12.97 EXTENSION NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the settings file has no version, so a file written by another Exudyn cannot be recognised (#2690)

    • description: Asked for by the maintainer on 2026-09-26: ‘there should be a version in the config file, as we may change the structure or anything in the future, and only a version can help to decide whether or how an older file can be used. Currently, we could just decide to require exact version match (and the version will not change before a different release is pushed on github).’ ~/.exudyn/config.json carries four sections and no version at all, so a file written by an older Exudyn - whose sections, keys or value shapes were different - is read as if it were current. The structure has already changed twice within one day (the resultsMonitor section was folded in, the dialogs section was added), which is the case being guarded against. WHICH version is the decision, and it matters more than it looks: the micro version is derived from the count of resolved issues, so an exact match on the full version (1.12.95.dev1) throws a user’s settings away on every issue that is resolved - unusable during development, and it would also drop the file on every patch release. Options: the full version with an exact match (what was asked for, and the strictest), the release version major.minor with an exact match (stable across a development cycle, which is what ‘will not change before a different release’ means), or a format version of the file itself, bumped by hand when the structure changes, with the Exudyn version written beside it for information. Whatever is chosen, a file that does not match is IGNORED with one note naming the file and both versions, never silently, and never repaired by guessing. revision2026b step RG12.13.2.

    • notes: ~/.exudyn/config.json carries a format version, and it has to match: overrideSettings.fileFormatVersion is 1, Save writes it into every file - always the current one, whatever the file said - and Load IGNORES a file whose version differs, including one with no version at all, which is every file written before this change. The note names both versions and says to store the settings again. The version is never a section and never reaches exudyn.special.overrideSettings. It is a plain integer and it is bumped BY HAND, only when Exudyn has been released since the last bump AND the meaning of something in the file has changed - so it does not move with the micro version, which changes on every resolved issue and would kill a user’s settings every few days.

    • date resolved: 2026-09-26 21:00, date raised: 2026-09-26

  • 1.12.96 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG a stored dialog geometry is written but never read back (#2686)

    • description: Reported by the maintainer against 1.12.95: the store button of the settings dialog saves the settings and the position, but reopening the dialog does not restore the position. Measured: RestoreWindowGeometry returns early unless StoreDialogPositions() is true, so the geometry the store button writes is never read - and the button exists precisely so that a user does not have to switch visualizationSettings.dialogs.storeDialogPositions on (revision2026b step RG12.11). With the flag off the window is asked for the default ‘900x700’ although ‘1122x1751+7+14’ is stored. A second, wider half: StoreDialogPositions() asks GetRendererSystemContainer(), which is None whenever no container is attached to a running renderer, so the whole dialogs mechanism - storing AND restoring - is off for a dialog opened without a renderer, for instance by ‘python -m exudyn dialogs’ or by a script before renderer.Start(). Measured: GetRendererSystemContainer() is None and StoreDialogPositions() is False even when the container’s own flag is True. The rule should be: the flag decides whether a dialog STORES itself when it closes; a geometry that IS stored is used whatever the flag says, and the reachability rule of RG6.2.11 still decides whether the position may be used. NOT YET REPRODUCED, and it needs the message: the maintainer also reports that opening the visualization settings with a config.json holding a dialogs entry ‘reports an error’, and that removing the entry makes it load. Building the same dialog in a withdrawn window with exactly that file raises nothing, so the text of the error is needed. revision2026b step RG12.13.

    • notes: A geometry that IS stored is used whenever a dialog opens, whatever visualizationSettings.dialogs.storeDialogPositions says. RestoreWindowGeometry asked that flag first and returned early, so what the store button of RG12.11 wrote was never read back - measured: the window was asked for the default 900x700 while 1122x1751+7+14 was stored. The flag now decides only what its name says, whether a dialog stores ITSELF when it closes, which is where RememberWindowGeometry still asks it. StoreDialogPositions(settingsStructure=None) asks the structure being edited before the renderer’s SystemContainer, because GetRendererSystemContainer() is None whenever no container is attached to a running renderer - so for ‘python -m exudyn dialogs’, and for any script before renderer.Start(), the flag was False however it was set and such a dialog could never store itself. And a stored SIZE is now cut down to the current screen, for the reason the position is checked at all: a dialog is taller than it is wide and its buttons are in the bottom row, so a size stored on a larger or rotated monitor put the close button off the screen. The reachability rule for the position is unchanged. Five new tests, which measure what the function asks the window manager for, because a withdrawn window reports 1x1+0+0 whatever it was given.

    • date resolved: 2026-09-26 19:54, date raised: 2026-09-26

  • 1.12.95 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG storing an override setting guesses the defaults of exudyn.config, and the dialog cannot store at all (#2685)

    • description: Storing an override setting has three defects, all of them about not knowing the defaults. (1) overrideSettings.Store(config=exudyn.config) stores every value that is not ‘’, 0 or False, because exudyn.config has NO defaults anywhere: it is a facade over globals, so a freshly constructed Config reports the CURRENT values - measured, after exu.config.outputPrecision = 12 a new one says 12 - and the trick every settings structure uses (type(structure)()) cannot work. So it guesses, and it stores settings a user never changed. The maintainer on 2026-09-26: ‘you have to improve the config mechanism (could add a Get/Set dict access or so, and also the defaults)’. (2) the settings dialog’s ‘diff to default’ does not say what a user needs once an override file exists: a stored setting is a difference to the default and is listed as one, with nothing to say it is already stored. The maintainer decided the dialog shows the difference to the REAL default and names the settings the file already covers separately, with a comment between them, because comparing against default-plus-override would hide exactly the settings this file is about. (3) there is no way to keep a look from inside the dialog without switching storeDialogPositions on: a ‘Store settings’ button belongs where a user already is when they decide they like what they see, applying only to visualizationSettings and dialogs, clearly written in the pop-up hints. It writes to the home directory from one click, so it shows exactly what it will write and asks first. revision2026b step RG12.11.

    • notes: exudyn.config has a dictionary interface and its defaults: GetDictionary(), SetDictionary(d) and GetDefaults(). The defaults are SNAPSHOTTED during module import, because they cannot be constructed - ExudynConfig is a facade over globals, so a second one reports the current values - and what Exudyn starts with is the default, taken while it still is. The settings are listed once, in configSettings in Pybind_manual_classes.cpp, with the three read-only ones marked, so a new setting reaches the dictionary, the defaults and everything comparing against them; Main/Config.h stays free of pybind11, as eight translation units include it. overrideSettings.Store(config=…) now stores what differs from GetDefaults(); it used to store every value that was not ‘’, 0 or False, which stored settings a user never touched - printToConsole from every run, and outputPrecision because 6 is not 0. The settings dialog has a ‘store settings’ button: it writes the visualizationSettings that differ from the defaults and the dialog’s own size and position, nothing else, and it shows exactly what it will write with a store/cancel pair before writing - one click reaching the home directory. It stores the geometry whether or not storeDialogPositions is on, because that flag is about remembering on closing and this is a user asking. ‘diff to default’ stays a difference to the real default, and the settings the override file already stores are named again under a comment line saying so: comparing against default-plus-override would hide exactly the settings that file is about. The grouping is GUI.SplitStoredFromChanged, a function, so it is tested without opening a window; the geometry parser became GUI.StoreGeometryString, used by both writers. Eleven new tests.

    • date resolved: 2026-09-26 18:22, date raised: 2026-09-26

  • 1.12.94 CHANGE NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the override settings are applied only by a SystemContainer, and the monitor keeps its own file (#2684)

    • description: The override settings of ~/.exudyn/config.json are read once into exudyn.special.overrideSettings (#2679), but only a SystemContainer applies the stored visualizationSettings - through a Python subclass installed in __init__.py - so a structure created by exu.VisualizationSettings() gets nothing, and a script that edits one before creating a container sees the defaults. The maintainer wrote the workflow out on 2026-09-26: read the whole file at import, apply what can be applied at once (exudyn.config), keep the rest in exudyn.special.overrideSettings, and apply the visualizationSettings whenever such a structure is CREATED. A Python subclass of VisualizationSettings does that, and it has a trap that has to be closed in the same change: settingsUtilities.DefaultSettingsDictionary(structure) calls type(structure)(), so on an instance of the subclass it would return the OVERRIDDEN value as the default - measured: openGL.multiSampling reads 4 as its own default - which would silently break the dialog’s ‘diff to default’ and Store(SC). It has to construct the compiled base class instead. The results monitor also still keeps a file of its own, ~/.exudyn/resultsMonitor.json. The maintainer deleted it on 2026-09-26 and decided it shall not be used again: the monitor reads and writes the resultsMonitor section of the one file, and the old name disappears from the documentation. The finished workflow goes into the documentation, under the Exudyn module where the override settings are documented (#2680), because a mechanism that is not written down is a mechanism nobody uses on purpose. revision2026b step RG12.10.

    • notes: A stored visualizationSetting now reaches EVERY VisualizationSettings structure when it is created - the one a SystemContainer builds and one built by exu.VisualizationSettings(), which got nothing before - through two small subclasses that ‘import exudyn’ installs only when the file holds such a section. The trap that came with them is closed in the same change: settingsUtilities gained CompiledSettingsClass(structure), and DefaultSettingsDictionary uses it, so the defaults of an overridden structure are still the DEFAULTS - constructing type(structure) would have returned the override as its own default (measured: multiSampling 4 as the default of 1) and silently broken every ‘diff to default’, the dialog’s marking and Store(SC). The results monitor has no file of its own any more: LoadSettings and SaveSettings read and write the resultsMonitor section of ~/.exudyn/config.json, SettingsFileName is gone, and ~/.exudyn/resultsMonitor.json is neither read nor written nor mentioned in the documentation. overrideSettings.StoreSection(name, values) is the one writer of a section - the dialogs, the monitor and Store all go through it - and a setting is recorded once however many structures apply it, so Print() says what was stored rather than how many structures exist. The workflow is written down in the Exudyn module page beside the file it describes, in six steps, with the sentence that a stored setting is not a new default. Six new tests.

    • date resolved: 2026-09-26 17:57, date raised: 2026-09-26

  • 1.12.93 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the default values make a round trip through a C++ literal string and back (#2682)

    • description: A default value in definitions/ travels Python -> C++ literal -> Python: itemModel.DefaultValueString() calls definitionTypes.CppLiteral() to make a C++ source string, and autoGenerateHelper.DefaultValue2Python() converts that string back with about twenty str.replace() calls and three substring find() heuristics on ‘Index’, ‘Float’ and ‘Vector’. Measured on 2026-09-26 over the 872 item members that have a default: 1001 of 2837 inputs are changed by it, 322 of them steered by the substring heuristics. It ends with an unconditional s.replace(‘f’, ‘’) to strip the float suffix of ‘0.05f’, which eats the letter f out of anything else: ‘Transformation66List()’ becomes ‘Transormation66List()’ for three members of ObjectKinematicTree, and ‘NoDefaultValue’ becomes ‘NoDeaultValue’ for a settings parameter. Nothing visible is wrong today - the three members are CFNoInterface and the settings default is filtered before the call - so the defect is contained by accident rather than by design; one new parameter whose type name contains an f would ship a silently wrong Python default. The one symptom that does reach the tree is cosmetic: a stray leading space in the defaultValue of ObjectContactConvexRoll.coefficientsHull reaches the generated signature as ‘coefficientsHull = []’, because a default that is a string is not validated. The fix is a converter that dispatches on the TYPE, which the member carries, instead of on substrings of a C++ string: 402 of the 872 defaults exist only as C++ source text (142 CppValue and 260 plain str, in 29 distinct expression shapes), so they need a Python value in definitions/ first; the other 470 are already plain Python values and need no conversion at all. Options are in revision2026b step RG3.24.3, with the call-site map in RG3.24.1/.2.

    • notes: A default value is no longer reconstructed from its C++ literal. definitionTypes.py gained PythonLiteral(value, typeName) and DocumentLiteral(value, typeName) beside CppLiteral: a CppValue is ASKED for its renderings - ToPython() and ToDocument() existed from the start and nothing had ever called them - a plain number, flag or string is its own Python value, and a default written as C++ source text is translated by named tables, dispatching on the spelling and the declared type. An expression no rule covers raises instead of reaching a generated file wrong. DefaultValue2Python, Str2Latex, SplitString and CutLinesFromString are gone - 201 lines, 14 call sites that were measured to change 0 of 3720 inputs - and so is the emitter workaround “don’t do this for file names, because ‘f’ is erased!”. What this repairs in the published documentation: 85 table cells read ‘[ invalid [-1] ]’ instead of ‘[ invalid (-1) ]’, 30 read ‘Matrix[]’, ‘PyMatrixContainer[]’ or ‘MatrixI[]’ instead of ‘[]’, one read ‘[Matrix3DF[3,3,1.,0.,0., …]]’ where its own description says [[1,0,0],[0,1,0],[0,0,1]], and the signature of ObjectContactConvexRoll carried ‘coefficientsHull = []’ with a double space. 74 lines in 47 generated files, and every one of them is one of these; nothing else moved. 17 new tests, each naming the defect it forbids.

    • date resolved: 2026-09-26 16:40, date raised: 2026-09-26

  • 1.12.92 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG The override settings are documented in a hand-written page rather than with the module they belong to (#2680)

    • description: docs/manual/userSettings.md was written by hand in revision2026b step RG12.5.1. The maintainer, 2026-09-26: it should be integrated into the Python-C++ command interface, under the Exudyn module, either written there or imported there, and consistent in both cases. The same step adds one hint to the troubleshooting section of performanceErrors.md: a user who sees strange behaviour should delete the ~/.exudyn folder or its config file - which is the first thing to try and is nowhere said today.

    • notes: The override settings are documented under the Exudyn module of the Python-C++ interface, section ‘Settings that persist between runs’: the file and its sections, what may be stored, how a dialog remembers its size and its columns, and a new list of the SIX environment variables the package reads - EXUDYN_NO_USER_SETTINGS, EXUDYN_CONFIG_FILE, EXUDYN_OUTPUTDIRECTORY, EXUDYN_SUPPRESS_UI_WINDOW_OPEN, EXUDYN_MODULE and EXUDYN_IMPORT_VERBOSE - of which three were documented nowhere before. exu.special.overrideSettings is a documented data member beside exu.sys and exu.variables. docs/manual/userSettings.md keeps its place in the table of contents as a pointer to it, and the troubleshooting chapter now says that deleting ~/.exudyn returns everything to the defaults, and that EXUDYN_NO_USER_SETTINGS=1 answers the question without deleting anything.

    • date resolved: 2026-09-26 15:59, date raised: 2026-09-26

  • 1.12.91 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG The override settings belong in exudyn.special.overrideSettings, not in a Python module of their own (#2679)

    • description: The maintainer, 2026-09-26, having seen revision2026b step RG12.5.1 built: the settings of ~/.exudyn are for convenience and are to be used rarely and with caution, so they belong under exudyn.special - exudyn.special.overrideSettings - and the dict should live on the C++ side, which also makes it accessible from C++. python/exudyn/settings.py becomes python/exudyn/misc/overrideSettings.py, because it is not intended to be used directly. What stays from RG12.5.1: the file and its format, the reader, the plain-values rule, the note at import, EXUDYN_NO_USER_SETTINGS and the runners that set it, and the tests. What moves is where the values live and when they are applied - a VisualizationSettings structure applies them when it is CREATED, not only a SystemContainer. Three options for the C++ carrier are written in the plan step RG12.9.

    • notes: The override settings of ~/.exudyn/config.json now live in exudyn.special.overrideSettings, a dictionary that ‘import exudyn’ fills once and that both Python and the C++ core read; the module that reads and writes the file is exudyn.misc.overrideSettings (formerly exudyn.settings, which no longer exists - it is internal and a user reaches the values through exudyn.special.overrideSettings). Every function that took settings=None now means that dictionary instead of a second read of the file, so the dialogs and the settings can no longer disagree within a run. Three new tests; the settings dialog and the results monitor are unchanged for a user.

    • date resolved: 2026-09-26 15:33, date raised: 2026-09-26

  • 1.12.89 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG 745 LaTeX underscore escapes are left in the generated Markdown, 38 of them inside mathematics (#2677)

    • description: Measured 2026-09-26 by the audit of revision2026b step RG3.14.13: 33 generated pages carry a backslash-underscore. 707 of them are OUTSIDE mathematics - Coordinates\_t in an item table, \_\_all\_\_ in the tracker log - where Markdown renders the escape as a plain underscore, so the page looks right and the source carries LaTeX that nothing needs. They come from three producers: Str2Latex, which escapes every underscore it is given; an explicit replace of the output variable names in itemDocsEmitter; and the issue tracker, which escapes the text of an issue. The remaining 38 are INSIDE mathematics and are a real rendering defect: in math mode a backslash-underscore is a literal underscore, so BeamSectionGeometry shows c_Y as text where a subscript was meant, and ObjectJointGeneric has UF\_t_{k} in a display equation. Those need one judgement each - subscript or literal - which is why this is a step of its own and not a mechanical replace.

    • notes: 115 LaTeX escapes removed from the generated Markdown - the other 638 counted are the tracker log, where escaping issue text is the rule of #2545 and is correct. Five producers: Str2Latex, structureDocsEmitter, itemDocsEmitter, itemModel and five example comments. 38 were inside mathematics, where the escape is a literal underscore, so subscripts such as c_Y, h_{max} and t_{end} render for the first time; one display equation needed a judgement and took the notation of the equation above it. Two utility functions got their Relevant Examples list back (revision2026b step RG3.14.14).

    • date resolved: 2026-09-26 13:01, date raised: 2026-09-26

  • 1.12.88 DOCU NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG The item and settings descriptions are written in LaTeX, not in Markdown (#2655)

    • description: The descriptions in definitions/ are the source of the reference manual, and a developer writing one meets 2684 LaTeX macro occurrences in 87 distinct macros: 709 rowTable, 160 hac, 127 mysubsubsubsection, 86 startTable, 69 refSection, 35 userFunction. The build converts them (tools/generators/latexToMarkdown.py) and the published pages are correct, so this is not a defect in the output - it is that the input is a language nobody writing an item description should have to know, and that nothing checks it. Replace the structural macros by a small documented set plus data in the definition dict, keep the math as it is, and remove the onlyRST/ignoreRST switches.

    • notes: The item and settings descriptions are Markdown: one converter, the rules in definitions/README.md, eleven checks that hold them, and no LaTeX escape left in what is published. Closed with revision2026b step RG3.14.14, which removed the last five escapers and the 38 subscripts inside mathematics that had never rendered.

    • date resolved: 2026-09-26 13:01, date raised: 2026-09-25

  • 1.12.87 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG GetRendererSystemContainer returns a container whose C++ object is gone (#2676)

    • description: #2623 made the lookup survive a destroyed SystemContainer, but only the lookup: the function checks that exudyn.sys[‘currentRendererSystemContainer’] exists and has the right type, and the first USE of the returned object then raises RuntimeError - Access violation - in whichever caller happens to be next. Found on 2026-09-26 by the new dialog tests of revision2026b step RG12.7, which failed at random in a parallel pytest run, in DialogScaling at guiSC.visualizationSettings.dialogs.fontScaling. A user meets it when a dialog is opened after the container that started the renderer has been deleted. The fix is one cheap read inside the guard, so that a dead container becomes the None every caller already handles.

    • notes: GetRendererSystemContainer reads one cheap setting of the container it is about to return, so a container whose C++ object is gone becomes the None every caller already handles. #2623 had guarded the lookup only, and the first use raised RuntimeError in whichever caller came next - found by the new dialog tests of RG12.7, which failed at random in a parallel pytest run.

    • date resolved: 2026-09-26 10:53, date raised: 2026-09-26

  • 1.12.86 EXTENSION LOW LOW EFF raised by: Claude-JG resolved by: Claude-JG Ctrl and the mouse wheel change the font size of a dialog (#2668)

    • description: The font size of the settings dialogs is a setting that has to be found and typed. The maintainer asks whether the mouse wheel could change it directly - about 10 percent per notch, up and down (maintainer, 2026-09-26). The dialog already computes every metric from the font size through DialogFontSize and DialogRowMetrics, so the question is mostly about rebuilding the tree at a new size and about which modifier, since the wheel alone scrolls.

    • notes: Ctrl and the mouse wheel change the font size of an open settings dialog, about 10 percent per notch and between 0.4 and 4 times the scaled size; the row height, the column widths and the font of a changed row follow it. The bare wheel still scrolls (revision2026b step RG12.7).

    • date resolved: 2026-09-26 10:53, date raised: 2026-09-26

  • 1.12.85 EXTENSION LOW LOW EFF raised by: Claude-JG resolved by: Claude-JG The column widths of a settings dialog are fixed pixels; make them relative and configurable (#2667)

    • description: GUI.py gives the tree four fixed widths - 325, 188, 113 and 420 pixels, scaled by the dialog scaling - so a name that is long is cut off whatever the screen. The maintainer asks for relative widths in visualizationSettings, each in 0..1: columnWidthName, columnWidthValue, columnWidthType, with the description column taking what is left (maintainer, 2026-09-26).

    • notes: The three fixed columns of a settings dialog take a share of its width - visualizationSettings.dialogs.columnWidthName, columnWidthValue and columnWidthType, each a fraction - and the description column takes what they leave. Each is at least 0.05, and if together they would leave the description less than a tenth of the dialog, all three are scaled down (revision2026b step RG12.6).

    • date resolved: 2026-09-26 10:53, date raised: 2026-09-26

  • 1.12.84 EXTENSION NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG A settings dialog remembers its size and its position (#2675)

    • description: The leftover of #2608: RG6.2.11 went through the catalogue of optional dialog features on 2026-09-23 and decided all of them except this one, which stayed undecided, with the rule that would make it safe recorded in the log - restore the size always, the position only when the window still lies inside the virtual desktop. The maintainer asked for a proposal on 2026-09-26 and approved it: it belongs in the user settings file of #2666, under a dialogs section, and is switched on by a new visualizationSettings.dialogs.storeDialogPositions.

    • notes: A settings dialog remembers its size and position when visualizationSettings.dialogs.storeDialogPositions is True: both are stored in the dialogs section of ~/.exudyn/config.json, the size is restored always and the position only when the window would still be reachable on the current screen (revision2026b step RG12.5.3, the leftover of #2608).

    • date resolved: 2026-09-26 10:11, date raised: 2026-09-26

  • 1.12.83 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG ObjectContactConvexRoll.pContact is computed state stored in parameters (#2413)

    • description: pContact is the currently computed contact point; written by the computation and read by the visualization (src/Objects/VisuNodePoint.cpp:2756 via GetPContact()). It lives in the parameter structure; so it is neither part of the system state nor kept per configuration and no history exists. It should be a data variable; which would also make the value available in the visualization configuration rather than whatever the last computation left behind. Found while removing the inert V flag from this member (revision2026 step R4.1.2).

    • notes: ObjectContactConvexRoll.pContact is a computed value that Python reads - it already was, and its description now says so instead of carrying a typo. rBoundingSphere beside it was computed from coefficientsHull AND settable, which did nothing because SetObjectParameter ends in ParametersHaveChanged(); it is read-only now. python/testing/test_computedParameters.py checks both: readable, in the dictionary, rBoundingSphere equal to the hull polynomial at 0, and writing either raises (revision2026b step RG4.2).

    • date resolved: 2026-09-26 09:12, date raised: 2026-09-13

  • 1.12.82 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG Six pages of the Python-C++ command interface repeat their own title as the first section (#2660)

    • description: 12.3 SystemContainer / 12.3.1 SystemContainer, 12.4 Renderer / 12.4.1 Renderer, and the same for MainSystem, SystemData, Symbolic and GeneralContact - in the PDF and in the HTML sidebar alike. The page title comes from markdownPageTitles in pybindEmitter.WriteMarkdownPages and the section from the class’s own DefPyStartClass, and for these six the two are the same word. The section heading carries the target a reference points to, so it cannot simply be deleted: the label has to move to the page title. The item pages of the reference manual have the same shape - ‘# ObjectGround’ then ‘## ObjectGround’ - and should be looked at in the same step.

    • notes: A page does not repeat its own title: latexToMarkdown.DropRepeatedTitle removes a first heading that only says the page name and returns its label, which the emitters write above the page title. The MainSystem extensions (create) and (general) are in the table of contents for the first time, because the repeated section no longer holds the level they needed. Six interface pages and 178 item pages; the item label sec:item:<Item> moved to the title and every reference still resolves, checked in the strict HTML build and in the PDF (revision2026b step RG3.18).

    • date resolved: 2026-09-26 08:58, date raised: 2026-09-25

  • 1.12.81 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG Five hand-written docstrings still send the reader to theDoc.pdf (#2656)

    • description: theDoc.pdf has not existed since decision D8. The generators no longer produce the name - revision2026b step RG3.14.10 made a section reference name its section - but five docstrings in the shipped package say it in their own text: python/exudyn/solver.py (3, two of which also carry a Markdown link written [Section](#sec:solverSubstructures), whose target spelling is the LaTeX one and not the MyST one), python/exudyn/misc/mainSystemExtensions.py (1) and the module header of python/exudyn/__init__.py, which links to the file on GitHub. They are hand-written, so no regeneration reaches them.

    • notes: The five theDoc.pdf references are gone: the two solver docstrings name MainSolverStatic and MainSolverImplicitSecondOrder beside their section links, the module header points at readthedocs, and the comparison in mainSystemExtensions names the reference manual. Both section targets already resolved, so only the words in front of them were wrong. The same two docstrings said staticSolver where SolveDynamic stores dynamicSolver. The name theDoc.pdf is explained once, in the revisions chapter (revision2026b step RG3.14.12).

    • date resolved: 2026-09-26 08:40, date raised: 2026-09-25

  • 1.12.80 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG springDamperTutorial.py crashes at the end: OutputFilePath is not imported (#2669)

    • description: The tutorial solves and then reads its own output with OutputFilePath(…), which it never imports - from exudyn.utilities it imports a named list, and OutputFilePath is in exudyn.basicUtilities. A user who runs the tutorial to the end gets NameError: name OutputFilePath is not defined, after the simulation has finished. It is not in the example test suite, which is why nothing noticed. Found on 2026-09-26 while adding the results monitor to the example (revision2026b step RG11.3).

    • notes: springDamperTutorial.py imports OutputFilePath, which it used at its last line and never imported.

    • date resolved: 2026-09-26 08:31, date raised: 2026-09-26

  • 1.12.79 IMPROVEMENT NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG A user function is described in five places and typed in none of them (#2664)

    • description: Traced 2026-09-25 for ObjectGenericODE2.forceUserFunction. The same signature is stated in the ItemParameter’s type (TPyFunctionVectorMbsScalarIndex2Vector), in the std::function that definitionTypes maps it to, in the prose block of the item description with its own argument table, in the generated userFunctionArgsDict of itemInterface.py, and in the hand-written call in evaluateUserFunctions.cpp. Nothing checks that the five agree, and the one a user could actually use is the weakest: userFunctionArgsDict names the arguments arg0, arg1, arg2, arg3 and types them with the C++ names (StdVector, Real, Index), which is what advancedUtilities builds the symbolic function interface from. The registry the maintainer asked for therefore already exists and is only half filled in. Proposal (maintainer 2026-09-25, from a design discussed the same day): one typed Python function per user function in the ItemDefinition, parsed with ast and never executed, as the single source of the argument names, the Python types, the per-argument description - where the size of an argument is a formula in the description rather than part of the type - the documentation block, the entries of userFunctionArgsDict, and a Protocol per user function in itemInterface so that an editor can complete and check a user function’s arguments. 23 distinct signatures under 17 names, in 35 blocks; to be tried on one function first.

    • notes: A user function is one typed Python function in definitions/, and the documentation block, the argument table, the entries of userFunctionArgsDict, the Protocol in itemInterface.py and the check against the C++ std::function are generated from it. All 34 user functions are converted; a parameter of a PyFunction type without a def is a finding of tools/checkDefinitions.py (revision2026b step RG12.4).

    • date resolved: 2026-09-26 08:31, date raised: 2026-09-25

  • 1.12.78 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG The manual mixes sentence case and Title Case in its headings (#2662)

    • description: Measured 2026-09-25 over docs/manual/*.md and index.md: 116 of the 189 headings are sentence case - ‘Mouse input’, ‘Render state’ - and the rest are not. Filtering out the proper nouns (Runge-Kutta, Newmark, Generalized-alpha, Hurty-Craig-Bampton, Lagrange-d’Alembert, Tait-Bryan, Ubuntu) and the code names that are capitalised because the code is (GraphicsData: Line, Items: Nodes, Objects, …), about fifteen are Title Case and should not be: Installation and Getting Started, Exudyn Basics, Execute Command and Help, Generating Animations, Parameter Variation, Genetic Optimization, Modeling of Contact in Exudyn, Sphere-sphere contact: Equations, Sphere-triangle contact: Equations, Dynamics: Mechanical principles, Generalized Principle of Virtual Work, Generalized Forces, Lagrange’s Equations of Motion, Euler’s and Chasles’s Theorems, Install from specific Wheel. The maintainer decided 2026-09-25: sentence case - ‘This is a heading’ - everywhere. A checker can report a mid-heading capital that is not in a list of names, which is how the fifteen were found.

    • notes: Every heading of the hand-written documentation is sentence case, and tools/checkHeadings.py keeps it so over 353 headings (revision2026b step RG3.16).

    • date resolved: 2026-09-26 08:31, date raised: 2026-09-25

  • 1.12.77 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG The command line and the results monitor are chapters of their own, between the manual and the theory (#2661)

    • description: index.md lists docs/manual/commandLine and docs/manual/resultsMonitor as top-level chapters, between the graphics chapter and the notation. Neither is something a reader needs before writing a first model: ‘python -m exudyn’ is five verbs for looking things up and reporting a bug, and the results monitor is a second process watching a running simulation. Both belong in Advanced topics, as sections or as sub-pages of it.

    • notes: The command line and the results monitor are sections of Advanced topics, nested through its own toctree, instead of chapters between the manual and the reference (revision2026b step RG3.15).

    • date resolved: 2026-09-26 08:31, date raised: 2026-09-25

  • 1.12.76 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev docs –pdf needs Perl and does not say so (#2658)

    • description: The third stage runs latexmk, which is a Perl script: MiKTeX answers “MiKTeX could not find the script engine ‘perl’ which is required to execute ‘latexmk’” and the stage fails in 0.4 s. It succeeds in a Git Bash shell and fails in PowerShell on the same machine for one reason: Git for Windows ships perl in its usr/bin, which Git Bash puts on PATH and PowerShell deliberately does not. So the PDF build has never depended on the TeX installation alone - it depended on which shell it was started from, and nothing said so. Two fixes, and the second is the one worth having: prepend the directory of any perl that can be found to the PATH of the latexmk subprocess, which needs no installation; or run xelatex directly - three passes plus makeindex - which is what latexmk automates and needs no Perl at all. Either way the stage must say what is missing instead of failing with a MiKTeX message in the user’s system language.

    • notes: exudev docs –pdf runs xelatex and makeindex directly and repeats the run until the cross-reference files are stable, so the PDF builds where no Perl is installed; verified with every perl directory removed from PATH and confirmed by the maintainer.

    • date resolved: 2026-09-26 08:31, date raised: 2026-09-25

  • 1.12.75 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG The visualization documentation is spread over three chapters with no structure (#2657)

    • description: Measured 2026-09-25. docs/manual/GUI.md, the chapter Graphics and visualization, holds mouse input, keyboard input, render state, the GraphicsData reference and UTF-8 encoding - five topics at one level. Exudyn Basics holds ten more visualization sections between the non-visualization ones: Renderer and 3D graphics, Visualization settings dialog, Execute Command and Help, Graphics pipeline, Raytracing, Storing the model view, Graphics user functions via Python, Color RGBA and alpha-transparency, Solution viewer, Storing images and generating animations. Advanced topics holds an eleventh, Camera following objects and interacting with model view. A reader looking for how to turn the renderer on has to know which of three chapters to open. Proposal: the visualization chapter becomes the one place, with four parts - the renderer window, the model view, images and animations, and writing your own graphics - and Exudyn Basics keeps one short section that points at it; the internals (Graphics pipeline, Raytracing) and the GraphicsData reference move to Advanced topics.

    • notes: The visualization documentation is one chapter, Renderer, graphics and visualization, in the four sections the maintainer decided, and the solver and performance material is its own chapter (revision2026b step RG3.15).

    • date resolved: 2026-09-26 08:31, date raised: 2026-09-25

  • 1.12.74 FIX LOW LOW EFF raised by: Claude-JG resolved by: Claude-JG the item docstrings show addExampleImage{X} to a user of help() (#2652)

    • description: The classDescription of an item is the docstring of its class in python/exudyn/itemInterface.py, and the emitter drops the backslash of a LaTeX command instead of the command: help(ObjectJointRevoluteZ) ends with ‘addExampleImage{RevoluteJointZ} addExampleImage{RevoluteJointZ2}’. It affects the six items that carry a picture (#2651 added three of them, so the count went from three to six) and it is the same for any other command that is not translated. The emitter should drop the whole command - there is no image in a terminal - the way latexToMarkdown turns it into an image directive for the page.

    • notes: The class description of an item carries no LaTeX any more, so help(ObjectJointRevoluteZ) ends with the marker types and not with addExampleImage{RevoluteJointZ}: the figures of an item are MyST figure directives since revision2026b step RG3.14.

    • date resolved: 2026-09-26 08:31, date raised: 2026-09-25

  • 1.12.73 EXTENSION LOW MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG 59 bare except: remain in the shipped package (#2497)

    • description: Successor of #1988; which asked to change “except:” into “except Exception as e:” so that a KeyboardInterrupt passes through a long parameter variation. The change was never made; but it is no longer invisible: ruff E722 lists every one of the 59 with file and message in tools/ci/ruffBaseline.txt since revision2026 step R5.5.3; and a NEW one fails the check. Each needs a decision on which exception was actually meant; which is why they were baselined rather than rewritten. revision2026 step R6.1

    • notes: No bare except: is left in python/exudyn - measured 2026-09-26: zero occurrences in the package and zero E722 entries in tools/ci/ruffBaseline.txt, where all 59 were listed. They went one at a time with the module cleanups of revision2026 and revision2026b; a new one fails the ruff check.

    • date resolved: 2026-09-26 08:31, date raised: 2026-09-17

  • 1.12.72 TESTING NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG One test for all user functions at once (#2671)

    • description: Every user function is now a Python def in definitions/ (#2664), from which four things are generated: the documentation block, the entries of userFunctionArgsDict, the Protocol in itemInterface.py, and the check against the C++ std::function. Nothing tests that the four agree at runtime, and the item-by-item test models exercise a handful of user functions only. The maintainer asks for one test that covers all of them at once (2026-09-26).

    • notes: python/testing/test_userFunctions.py: 41 cases over all 34 (item, user function) pairs, reading only the installed package - every entry names a Protocol the module has and exports, the Protocol takes the registry’s argument names in order, no argument is still arg0, the first is mbs of type MainSystem, every Protocol has a docstring, an item class keeps an ordinary function given for its user function, and every type is one the interface exchanges. No simulation: that is what the test models are for.

    • date resolved: 2026-09-26 01:31, date raised: 2026-09-26

  • 1.12.71 EXTENSION NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG The results monitor beside a running simulation, in a second process (#2670)

    • description: RG11.1 (#2610) evaluated the four ways to watch results while a simulation runs and recommended a second process: the solution file is already the protocol, python -m exudyn monitor already exists, nothing is shared so no backend, GIL or thread-safety question arises. MonitorResults blocks until its window closes, which is right in a console and wrong in a script that still has to run the simulation. This is the function that starts the monitor and returns at once.

    • notes: StartResultsMonitor(fileName, …) starts python -m exudyn monitor in a second process and returns at once, so a script can watch its results while it computes them. The child is left running when the script ends, and the returned subprocess.Popen is the handle to stop it; nothing is started when windows are suppressed. Two examples use it, one on a sensor file and one on the coordinates solution (revision2026b step RG11.3).

    • date resolved: 2026-09-26 01:26, date raised: 2026-09-26

  • 1.12.70 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG A comment in a description is still a LaTeX percent comment (#2663)

    • description: The maintainer, 2026-09-25: ‘In the itemDefs… files I still see % used for comments - latex style. Shouldnt we use <!– This is a single-line comment –> comments? % could still survive as the % symbol, but maybe just inside a formula.’ Measured the same day over definitions/: 513 lines are nothing but a % comment, 7 carry a % comment after text, and exactly one backslash-percent escape exists. Two of the 513 sit INSIDE a multi-line inline formula, where a continuation line of the formula is commented out - and that is the case that decides the design. MathJax and LaTeX both honour % as a comment inside mathematics, so a % there needs no handling at all; it only has to be left alone. Outside mathematics a comment becomes <!– … –>, which the converter removes so that it does not reach the page, and which cannot silently eat the next line of a formula the way % can: latexToMarkdown.StripComments runs BEFORE the mathematics is protected, so today a stray % anywhere truncates the rest of its line whatever it is. A commented-out block - a table, a figure - is then one <!– … –> rather than a % on every line.

    • notes: A comment in a description is <!– … –> and is removed by the converter; a % survives only inside mathematics, where MathJax and LaTeX read it. tools/checkDefinitions.py enforces both, and the ten % lines left in definitions/ are all inside formulas (revision2026b step RG3.17).

    • date resolved: 2026-09-26 01:05, date raised: 2026-09-25

  • 1.12.69 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG The arguments of a documented function are one paragraph, not one per line (#2665)

    • description: In the reference manual - the Python utility functions, and the MainSystem extensions of the Python-C++ command interface - the Args: block of a docstring is joined into a single paragraph, so a function of ten arguments is one wall of text and the argument names are in the body font. The old RST pages had one argument per line with the name in a monospace font. The HTML and the PDF are both affected, because both are built from the same generated Markdown. Reported by the maintainer with a screenshot of the old rendering, 2026-09-26.

    • notes: The input tag of a documented function is a nested list now, one argument per line with its name as code, in the Python utility functions and in the MainSystem extensions alike; 30 pages. A tag that is prose rather than a list of arguments is written as it was.

    • date resolved: 2026-09-26 00:30, date raised: 2026-09-26

  • 1.12.68 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the command window of the renderer lost the model scope (#2654)

    • description: Pressing X in the render window opens a command window whose label says it ‘operates in global scope of you Python model’ - mbs, SC and everything else the script defined. It does not any more: the command runs in the namespace of exudyn.misc.GUI, so ‘mbs’ is a NameError. Cause, found in the history: until revision2026b step RG6.2.1 (#2595) the dialog was a Python string inside src/Main/rendererPythonInterface.cpp, and the C++ executed every such string with py::object scope = py::module::import(‘__main__’).attr(‘__dict__’) - a line whose own comment says ‘use this to enable access to mbs and other variables of global scope’. The dialog’s exec(commandString, globals(), locals()) therefore saw __main__. Now the dialog is a function of a module, the C++ still executes its one-line wrapper in __main__, and globals() inside that function is the module’s namespace. Second, smaller fault in the same line: exec(…, globals(), locals()) puts an assignment into the local scope of the nested handler, so ‘k = 5000’ is forgotten as soon as it returns - the command window is meant for changing a running model.

    • notes: The command window of the render window runs in the scope of the model again: exudyn.misc.GUI.ModelScope() returns vars(__main__) and the command is executed in it, so mbs, SC and everything the script defined are there. One dictionary and not two, so an assignment survives the command - the window offers to change a running model. Until revision2026b step RG6.2.1 the dialog was a Python string that the C++ executed in __main__; as a function of a module, globals() was the module. Three tests pin it without opening a window. revision2026b step RG6.2.27.

    • date resolved: 2026-09-25 01:26, date raised: 2026-09-25

  • 1.12.67 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the header of definitionLoader.py reads like the file is dead (#2653)

    • description: The maintainer read it and asked whether the file is still used or a backup of the conversion. It is live: itemDocsEmitter.py calls LoadItemDefinitions for the item pages, structureDocsEmitter.py calls LoadStructureDefinitions through structureModel.py for the settings pages, and structureModel.py takes the LIST of definition modules from it, so every structure emitter needs the file for that alone - without it three generators do not run. What made it look dead is its header, which opens with what the old line parser produced and ends with two promises: ‘Removed once the generators read definitions/ directly’ and ‘this adapter is deleted with them’. That is the fault CLAUDE.md 6a is about, in a file header. Found while checking: itemModel.LegacyItems() with its two tables is genuinely dead - nothing has called it since the item emitters stopped using the old form.

    • notes: definitionLoader.py says what it is and who uses it: itemDocsEmitter for the item pages, structureDocsEmitter for the settings pages through structureModel, and structureModel itself for the list of definition modules - so three generators stop without it. It is not a backup, and the header no longer opens with what the old parser produced or promises its own removal, which is what made it look dead. itemModel.LegacyItems() with its two tables was genuinely dead and is removed; the regeneration is byte-identical. revision2026b step RG10.10.

    • date resolved: 2026-09-25 01:03, date raised: 2026-09-25

  • 1.12.66 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG three item pictures are in the repository and on no item page (#2651)

    • description: RevoluteJointZ2.png, SphericalJoint.png and UniversalJoint.png show exactly one item each - a revolute joint between two bodies, a spherical joint, a universal joint - and no page shows them; the old itemDefinition.tex did not either. Three sibling pictures ARE shown, through \addExampleImage{X} in the classDescription, which names the file WITHOUT its extension: that is why a search for ‘figures/X.png’ does not find them, and why they were reported as unreferenced in #2594. They belong to ObjectJointRevoluteZ (which already shows one picture and gains the one with both bodies), ObjectJointSpherical and ObjectJointGeneric, whose description explains the universal joint as its one-constrained-axis case. TutorialRigidBody1.png is the figure of a tutorial that no longer exists and goes.

    • notes: The item pages of ObjectJointRevoluteZ, ObjectJointSpherical and ObjectJointGeneric show the picture of their item: the revolute joint between two bodies with the axes labelled, the spherical joint, and the universal joint - which is what the generic joint is when a single rotation axis is constrained. The pictures were in docs/figures/ and on no page. TutorialRigidBody1.png, the figure of a tutorial that no longer exists, is removed. revision2026b step RG3.8.3.

    • date resolved: 2026-09-25 00:55, date raised: 2026-09-25

  • 1.12.65 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the four sub-tutorials are nested under the Mass-Spring-Damper tutorial (#2650)

    • description: Same cause as the installation instructions of #2646: a toctree places its entries where the directive stands, and the one in docs/manual/tutorial.md stands at the end of the page, which is inside its only section. So the rigid body, flexible beams, symbolic and FFRF tutorials appear one level below ‘Mass-Spring-Damper tutorial’ in the sidebar instead of beside it. The toctree belongs at the top level of the page. Checked at the same time: of the four toctrees in the hand-written pages this was the last one that was nested.

    • notes: The toctree of docs/manual/tutorial.md is at the top level of the page, so the rigid body, flexible beams, symbolic and FFRF tutorials stand beside ‘Mass-Spring-Damper tutorial’ instead of below it. Same cause as the installation instructions of #2646; a check of every toctree in the hand-written pages says this was the last nested one. revision2026b step RG3.8.2.

    • date resolved: 2026-09-25 00:31, date raised: 2026-09-25

  • 1.12.64 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the published pages tell the reader about the revision instead of about themselves (#2648)

    • description: The rule of CLAUDE.md 6a and CODING_STYLE.md section 6 - documentation says what IS, not what it was - applied to what is already there. Measured 2026-09-24: 887 mentions of revision2026 in 257 files outside docs/revision/. The maintainer’s example is the header of python/TestModels/GraphicsDataTest.py, which opens with ‘one of the ten small tests that lived in python/testing/modelUnitTests.py from 2019 until revision2026b step RG10.6.5 made each of them an ordinary test model’ - the test models are documentation pages, and a reader of that page wants to know what the model computes. Tier by tier: the published model headers and the definitions, which are the reference manual, then the manual and the developer pages, then the comments in src/ and tools/, where the older rule already says that a comment cites the issue and not the plan step. What must survive is the issue number, which a reader of the documentation can follow, and any sentence carrying a measurement or a decision; what goes is the name a thing had before, when it changed, and which plan step changed it. revision2026b step RG3.13.

    • notes: The published pages say what the thing is. The ten converted test models describe what they compute, read out of the model itself, instead of what they were called before; the one published settings description and the 25 definition file headers lose the plan step; the manual and the developer pages keep only the two references that are ABOUT the plan, and where a sentence was a promise about a step it now states what is true today. In the comments of src/, tools/ and python/, 652 of the 887 mentions were parentheticals or appended clauses and went by rule, keeping the issue number where there was one. 235 remain, each inside a sentence and none of them published, which is #2649. revision2026b step RG3.13.

    • date resolved: 2026-09-24 23:46, date raised: 2026-09-24

  • 1.12.63 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG regenerated_files fails on linux: the generator writes pybind_modules.h, the repository has Pybind_modules.h (#2647)

    • description: From the GitLab job of 1.12.61, which the maintainer supplied. structureHeaderEmitter.py writes directoryString+’pybind_modules.h’ and generate.py declares the same lowercase name among the outputs of that stage, while the file tracked in git - and the one src/Pymodules/Pybind_modules.cpp includes - is Pybind_modules.h with a capital P. On Windows the filesystem is case-insensitive, so the emitter overwrites the right file and the post-check glob finds it; on linux it is a different name, so WriteTextIfDifferent reports ‘illegal file’ and returns without writing - Pybind_modules.h is NEVER REGENERATED THERE - and the post-check reports ‘src/Autogenerated/pybind_modules.h (does not exist)’ and fails the job. Two things make it invisible: WriteTextIfDifferent refuses to create a file that does not exist instead of writing it, and the post-check globs, which is case-insensitive on Windows. A comparison of all 37 declared single-file outputs against git ls-files with exact case finds this one and no other.

    • notes: The generator and the repository agree on one spelling of Pybind_modules.h. Until now the emitter wrote pybind_modules.h: the same file on Windows, a different one on linux, where the real header was therefore never regenerated and the regenerated_files job failed with ‘does not exist’. Also fixed, because they are what hid it: WriteTextIfDifferent now creates a file it is asked to write instead of printing ‘illegal file’ and writing nothing, and generate.py checks a declared output CASE-EXACTLY on every platform - glob is case-insensitive on Windows, which is why this could not be seen here. Reproduced on Windows by putting the lowercase name back, and all 37 declared outputs were compared against git ls-files with exact case: this was the only one. revision2026b step RG10.9.

    • date resolved: 2026-09-24 23:12, date raised: 2026-09-24

  • 1.12.62 DOCU HIGH HIGH EFF raised by: Claude-JG resolved by: Claude-JG building from source and the development workflow are told three times and never from the start (#2646)

    • description: Measured 2026-09-24 at the maintainer’s request. THE ORDER IS WRONG: gettingStarted.md ends with the toctree that nests Installation instructions, so a reader meets ‘Run a simple example in Python’ before being told how to install. THREE PLACES DESCRIBE THE BUILD and disagree: gettingStartedInstall.md has Build under Windows / Mac OS X / Ubuntu (about 170 lines, still saying ‘go to main of your cloned github folder’ although the main/ level went in revision2026 step R3.1, still Ubuntu 18.04 with Python 3.6 and a USE_GLFW_GRAPHICS define in BasicDefinitions.h that no longer exists), docs/howTo/buildFromSource.md is the current reference at 151 lines, and docs/dev/README.md has a third short version. NOTHING SAYS HOW TO GET THE CODE: there is no git clone anywhere, no choice between ssh and https, and no page on branches, commit messages, pull, push and merge - which an external contributor needs and which keeps the internal workflow consistent. WORKFLOW.md is 845 lines whose sections run 0, 1, 2, 0a, 2a, 2b, 3, so the one-time setup of a clone stands after versioning; section 0 starts from an environment that exists without saying where it came from. And the developer documentation calls Visual Studio 2022 the primary development environment, which is only half true: it is the mixed Python/native debugger, while the everyday work - Python, definitions, documentation, Claude Code - happens in VS Code, which is where the co-developers will be, so the command line git commands belong in the documentation.

    • notes: Building from source and the development workflow are told once each, from the start. The user manual installs: its three ‘Build and install under X’ sections - which still described Ubuntu 18.04, Python 3.6 and a main/ directory removed in revision2026 step R3.1 - are one short section saying when a build is needed at all, and gettingStartedInstall.md went from 317 to 153 lines; the installation is now rendered BEFORE ‘run a simple example’, which moved to a page of its own. The developer documentation builds: docs/dev/BUILD.md is the single reference, with a platform-independent part first and then Windows, Linux and macOS, absorbing docs/howTo/buildFromSource.md (deleted) and what was only in the manual; docs/dev/GETTING_STARTED.md goes from nothing to a passing test run in seven steps and is the first page with a git clone in it, over https or ssh; docs/dev/GIT.md carries branches, the everyday loop, commit messages, branching, merging, what a contribution provides and the way back from the usual mistakes. WORKFLOW.md is renumbered 1 to 10 in the order the work is done, testing is its own section instead of a sub-section of CI, and the one-time setup of a clone moved into GETTING_STARTED.md. And the editors are said correctly: the invariant is mixed Python/native debugging in VS2022, not which IDE is primary - the everyday work happens in VS Code. Three LaTeX relicts (-{}-pre) went with it. revision2026b step RG3.12.

    • date resolved: 2026-09-24 22:31, date raised: 2026-09-24

  • 1.12.61 CHANGE NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG remove OpenVR (#2645)

    • description: OpenVR blocks the rendering revision, it cannot be tested in CI or by most users - it needs a head mounted display or an emulator - and it carries a vendored SDK of 1.2 MB and a prebuilt 808 KB binary in the repository. It is compiled only behind __EXUDYN_USE_OPENVR, which no shipped wheel sets, so what it costs today is the guards in the renderer, the settings that document a feature nobody can reach, a library that setup.py copies into the package, and a source file in every build list. Scope: src/Graphics/OpenVRinterface.cpp and its header, every __EXUDYN_USE_OPENVR guard, the –openvr flag and -lopenvr_api in setup.py, include/openVR/, libs/libs64/openvr_api.dll and .lib, visualizationSettings.interactive.openVR, the renderState key openVR, the example openVRengine.py with its action manifest, and the manual sections. A user who needs OpenVR takes Exudyn <= 1.11, and the release notes say so. revision2026b step RG6.1, from revision2026 step R11.1.

    • notes: OpenVR is removed. Gone are src/Graphics/OpenVRinterface.cpp and its header, every __EXUDYN_USE_OPENVR guard in the renderer, GlfwClient::SetProjectionMatrix (whose only caller it was), the classes OpenVRaction and OpenVRState with the openVRstate member of the render state, the openVR entry of the render state dictionary, the settings visualizationSettings.interactive.openVR, the useOpenVR/–openvr flag with the macro and -lopenvr_api in setup.py and pyproject.toml, include/openVR/ and libs/libs64/openvr_api.dll and .lib, the example openVRengine.py with its action manifest, the OpenVR section of Advanced topics and the Valve licence block - 2.1 MB in 13 tracked files. IF YOUR SCRIPT NEEDS OPENVR, STAY ON EXUDYN 1.11: it could only ever be used by compiling it in yourself, no released wheel carried it, and it stood in the way of the coming rendering work; docs/manual/revisions.md says so under ‘What can break a script’. Deliberately kept: the projection matrix of the render state and the branch of SetProjection that uses it, because SetState accepts a projectionMatrix from Python and OpenVR was only its first user. revision2026b step RG6.1.

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

  • 1.12.60 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev has three Windows-only spots, and it is needed on linux and macOS too (#2644)

    • description: Measured on 2026-09-24 by running every exudev command with –dry-run –no-conda under WSL: generate, build, test, docs, perf, examples, issue and env plan the same steps there as on Windows - the conda lookup already tries bin/conda, the wheel lookup carries no platform tag and the stale package copy is found through build/lib.*. Three places are Windows-only and wrong elsewhere. ‘exudev clean’ matches build/lib.win-amd64-*, build/temp.win-amd64-*, build/bdist.win32 and build/bdist.win-amd64, so on linux and macOS it removes nothing. ‘exudev docs –open’ calls xdg-open, which macOS does not have; it wants ‘open’. ‘exudev linux’ drives the manylinux container through ‘wsl -e bash -lc’, which on linux itself has no wsl to go through and on macOS cannot build an x86_64 manylinux wheel at all.

    • notes: exudev plans the same steps on Windows, linux and macOS. The three Windows-only places are the platform’s own now: clean builds its patterns from sys.platform, docs –open calls cmd/open/xdg-open, and the manylinux container runs through WSL only on Windows and is refused on macOS with the reason. python/testing/test_exudev.py pins the three by pretending to be each platform. revision2026b step RG10.8.

    • date resolved: 2026-09-24 18:54, date raised: 2026-09-24

  • 1.12.59 BUG HIGH MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG macOS: the settings dialog crashes the process through a re-entrant DoIdleTasks (#2643)

    • description: Fatal Python error in PyEval_RestoreThread, SIGABRT, macOS 14.5 arm64, Python 3.13, after interacting with the visualization dialog of an interactive example (maintainer, 2026-09-24, tmp/MacOS/mactest.txt). The 103 frames of the crashed thread show DoIdleTasks entered TWICE: a tkinter after-callback of interactive.py calls SC.renderer.DoIdleTasks(0); its PyProcessExecuteQueue runs the queued Python that opens the settings dialog; the dialog’s wait_window pumps Tcl events; a Tk binding calls GUI.py UpdateSettingsStructure, which calls SC.renderer.DoIdleTasks(0) again when dialogs.multiThreadedDialogs is set - and that inner call reaches _glfwPlatformPollEvents, which on macOS runs the SHARED Cocoa run loop, redraws the Tk window and calls back into Python at a point where the GIL bookkeeping of _tkinter is inconsistent. Windows survives it because polling GLFW events there does not pump the Tk event loop. The renderer idle loop must not be re-entrant; the workaround is dialogs.multiThreadedDialogs=False, whose description already says it may cause problems on some platforms.

    • notes: GlfwRenderer::idleOperationDepth counts the idle operations on the stack, and only the outermost polls events and runs the queued Python. A nested one - the settings dialog calling DoIdleTasks(0) on every change - still renders, so the live update keeps working, but it no longer starts a second event pump inside the first, which on macOS runs the shared Cocoa run loop and aborts the process in PyEval_RestoreThread. Both guarded blocks are in the single-threaded path, which is what macOS always uses and what Windows and Linux only reach if multithreaded rendering is turned off. revision2026b step RG6.6.

    • date resolved: 2026-09-24 18:46, date raised: 2026-09-24

  • 1.12.58 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the plan does not say what to do next (#2642)

    • description: RG10.7 made the plan hold the open work again, and the question it does not answer is the one a reader opens it for: what now. The open steps are spread over twelve groups and are read by scrolling past the finished ones. The maintainer asked on 2026-09-24 for a final section, updated from time to time: what is still open or was raised during the current work, and what is recommended next - each line with its issue number and its RG number and a short title, never a second copy of the step.

    • notes: The revision plan ends in a section ‘Next steps recommended’: the open steps with their issue and a short title, what the current work raised without making it a step, and a recommended order with the reason for it. It copies nothing - a step keeps its full text in its group - and is updated from time to time. revision2026b step RG10.7.1.

    • date resolved: 2026-09-24 13:40, date raised: 2026-09-24

  • 1.12.57 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG issue serve: a search for digits finds every field except the issue number (#2641)

    • description: Searching for ‘249’ with status=all lists #2377, #1988 and #1142, which name it in their text, and #244 and #694, which carry it in resolvedInVersion (0.1.249 and 1.0.249) - but it MISSES #2497 and every other #249x, which is what the maintainer was searching for. The number is the one field the substring search skips: #2636 made it a separate exact test, so ‘249’ finds issue 249 and no other. It shall be searched as a substring like every other field, so that a partial number finds the issues that start with it.

    • notes: The web view searches the issue number as a substring like every other field, so ‘249’ finds #249 and #2490 to #2499, and not only the issues whose text mentions it. revision2026b step RG10.2.2.

    • date resolved: 2026-09-24 13:34, date raised: 2026-09-24

  • 1.12.56 IMPROVEMENT NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the value cell of an enum still shows the type name, so the selected value cannot be read (#2640)

    • description: #2635 shortened the list of the combo box, and the maintainer reports what is left: the moment the box collapses, the cell shows ‘OutputVariableType.Torque’ again, which is the same problem one step later - the value column is as wide as the box was. The short name shall be THE value string: ConvertValue2String produces it, so the cell, the marking of a changed value and the comparison of ChangedSettings all use it, and ValueLiteral puts the type back, because that is the only place where Python needs the full name.

    • notes: The short name is the value string of an enum: ConvertValue2String produces it, so the cell of the dialog, the marking of a changed value and the comparison of ChangedSettings all speak it, and ValueLiteral puts the type back because the generated Python is the only place that needs the full name. CheckType and ConvertString2Value accept both spellings. revision2026b step RG6.2.25.1.

    • date resolved: 2026-09-24 13:25, date raised: 2026-09-24

  • 1.12.55 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the tooltips of the settings dialog are invisible while the dialog is topmost (#2639)

    • description: The pop-up hints of the tree rows and of the buttons do not appear when the dialog is topmost, which it is by default and in every dialog of ‘python -m exudyn dialogs’. Turning off visualizationSettings.dialogs.alwaysTopmost and reopening the dialog makes them work, which names the cause: the tooltip is a Toplevel of the dialog without the topmost flag, and on Windows a topmost window is always above one that is not - the same mechanism as the window of the changes in #2621, which had to be given the flag before it could be seen. The tooltip needs it too; the dialog must stay topmost, because it blocks the render window.

    • notes: The tooltip window of the settings dialog carries -topmost and is lifted when it is placed, so the pop-up hints appear while the dialog is topmost - which it stays, because it blocks the render window. Same mechanism as #2621 and #2614: on Windows a topmost window is a stacking band, and a Toplevel without the flag can never be drawn above one that has it. revision2026b step RG6.2.26.

    • date resolved: 2026-09-24 13:11, date raised: 2026-09-24

  • 1.12.54 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the revision plan carries the full text of the steps that are finished (#2638)

    • description: The plan states its own rule - a done step keeps one line here: status, date, outcome, link to the log; an open step keeps its full text - and does not follow it: 971 of its 1391 lines are steps that are done, several of them 30 to 130 lines of how the work was done, why, and which options were weighed. That belongs in the log, which has an entry for every one of them, and the problem as it was first stated belongs to the issue. The plan is where the OPEN work is read, and it is unreadable when four fifths of it is finished work.

    • notes: The revision plan holds the open work again: a finished step keeps its status, date, outcome and the link to its log entry, which is the rule the plan states in its own header. 1391 lines to 939, no anchor, step number or group heading lost, and no open step touched. The review of GUI.py, the one piece of analysis that lived only in the plan, is a log entry now. revision2026b step RG10.7.

    • date resolved: 2026-09-24 12:57, date raised: 2026-09-24

  • 1.12.53 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG changelog and tracker page print the same issue in two different formats (#2637)

    • description: The two pages are renderings of one store, but a resolved issue looks different in each: the changelog prints ‘- **1.12.50** `FIX` title (#2634) - raised by X’ and the tracker page prints ‘- Version 1.12.49: resolved Issue 2633: title (improvement)’ with a sub-list. So the changelog has no issue number in the tracker’s spelling, no date raised and no date and time resolved, and the tracker page has no type badge. One entry format for both: the type as the changelog writes it, the priority and the effort as badges right after it, ‘raised by’ and ‘resolved by’ in the same style, and the sub-list of the tracker for the rest. The changelog also claims to point at ‘the full issue tracker’, which is wrong - the page holds the issues resolved before the current release.

    • notes: The changelog and the issue tracker page print an issue in one format: the type, then the priority and the effort as badges, then who raised and who resolved it, then the title with its number, and the description, the notes and the dates below it. One function, IssueEntry(), writes both pages. The changelog no longer claims to point at ‘the full issue tracker’. revision2026b step RG3.10.1.

    • date resolved: 2026-09-24 12:45, date raised: 2026-09-24

  • 1.12.52 IMPROVEMENT NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG issue serve: the search misses fields, and the list stops at 400 issues (#2636)

    • description: Two things in the web view of the issue tracker. The text search looks at title, description, workingRemarks and releaseNotes only, so an author cannot be searched for although every issue names two of them - who raised it and who resolved it - and neither can a file, a plan step or a version. And the listing sends at most 400 rows, so the early issues cannot be reached by scrolling at all: the store holds more than 2500. The search shall cover every field of an issue, and the listing shall send what matches.

    • notes: The web view of the issue tracker searches every field of an issue, the two authors included, and its list is no longer capped at 400 rows, so the oldest issues can be reached. revision2026b step RG10.2.1.

    • date resolved: 2026-09-24 12:30, date raised: 2026-09-24

  • 1.12.51 IMPROVEMENT NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG settings dialog: the combo box of an enum repeats the type name in every entry (#2635)

    • description: The combo box that edits an enum setting - contour.outputVariable, the item types, the solver types - lists its entries as str(value), which is ‘OutputVariableType.Displacement’. The box has the width of the value column, so the type name, which is the same in every entry and is already shown in the type column, takes the room that the part which actually distinguishes the entries needs, and the choice cannot be read. The entries shall be listed without the ‘XXXType.’ prefix; the value the settings structure and the generated code carry stays the full name.

    • notes: The combo box that edits an enum lists its entries without the type name in front of them: ‘Displacement’ instead of ‘OutputVariableType.Displacement’. Only the list is shortened - the value the settings structure holds, and the line that a settings dialog writes for a script, keep the full name. revision2026b step RG6.2.25.

    • date resolved: 2026-09-24 12:22, date raised: 2026-09-24

  • 1.12.50 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the dialogs opened from the command line are larger and blurred (#2634)

    • description: revision2026b step RG6.2.24, maintainer 2026-09-24. python -m exudyn dialogs vis|sim|help opens the same dialogs as the renderer, but they come out larger, in a different font, and visibly blurred. Two causes, both from the missing renderer. (1) The process is not DPI aware: GLFW makes it so when the render window opens, and Windows then draws tkinter at the real resolution; started from a shell there is no GLFW, so Windows bitmap-stretches the window and everything is soft. (2) GetExudynDisplayScaling() reads the display scaling from the renderer’s state and returns 1 when there is no renderer, so GetGUIContentScaling sets the tk scaling to 1.4 instead of 1.4 times the display scaling - a different size than the same dialog has when the renderer opens it.

    • notes: revision2026b step RG6.2.24. The dialogs of ‘python -m exudyn dialogs’ are drawn like the ones the render window opens. Two causes, and they compound: the process was not DPI aware - GLFW sets that when it creates the render window, so a dialog opened with V inherits it, while from a shell Windows draws at 96 dpi and stretches the bitmap, which is both soft and, on a 175% display, 1.75 times too large - and GetExudynDisplayScaling() read displayScaling out of the renderer’s state and returned 1 when there is no renderer, so the content was laid out for an unscaled display and then stretched. MakeProcessDpiAware() is now called once in GetTkRootAndNewWindow before the first window (afterwards Windows refuses, which is not an error: something else has already done it), and GetExudynDisplayScaling(root) asks tkinter when it cannot ask a renderer - root.winfo_fpixels(‘1i’)/96, measured as 1.749 on this machine where it used to say 1.

    • date resolved: 2026-09-24 11:44, date raised: 2026-09-24

  • 1.12.49 EXTENSION LOW MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the settings dialog could edit simulationSettings as well (#2624)

    • description: revision2026b step RG6.2.18, low priority, from the catalogue of RG6.2.11. Everything below the widgets is ready: GetDictionaryWithTypeInfo is bound for SimulationSettings, SettingsPrefix writes simulationSettings… into the code line, and DefaultSettingsDictionary falls back to the constructor for a structure that is not on a SystemContainer. What is missing is a way to OPEN it - a function in exudyn.misc.GUI - and the decision whether the renderer offers a key for it while a solver runs, where changing a solver setting mid-step is not as harmless as changing a colour. Maintainer, 2026-09-23.

    • notes: revision2026b step RG6.2.18. The settings dialog is reachable from a shell: python -m exudyn dialogs vis | sim | help, the form the maintainer proposed on 2026-09-24 - not from the renderer, where changing a solver setting mid-step is not the harmless thing that changing a colour is. Everything below the widgets was ready since RG6.2, so the step is a command of 40 lines in python/exudyn/__main__.py, added to the CommandTable that already held monitor, plot, info and demo. It builds its own settings structure and never a SystemContainer (creating one attaches it to the render engine, #2625), and since RG6.2.20 a plain structure carries the values a user really starts from. When the dialog closes, the command prints ChangedSettingsCode(settings) from RG12.3 - the lines that set what was changed, ready to paste - because browsing 470 settings is only useful if something can be taken away from it. The command dialog is deliberately not among them: a window that executes Python in the scope of a running model means nothing without one. The command asks UIWindowSuppressed(‘Dialogs’, …) first and returns quietly in an automated run, which is what makes it testable; python/testing/test_commandLine.py calls every form of it.

    • date resolved: 2026-09-24 10:59, date raised: 2026-09-23

  • 1.12.47 DOCU raised by: Claude-JG resolved by: Claude-JG CHANGELOG.md and the issue tracker page hold the same list twice (#2599)

    • description: Maintainer, 2026-09-23. Both are written by issueTracker.py from the same store and both list every resolved issue per release, newest first: CHANGELOG.md is 2384 lines, the tracker page 8987, and about 2370 lines of the first are a shorter rendering of what the second says in full - the tracker page adds the author, the description, both dates, and it also carries the open issues and the known bugs, which the changelog does not. In the PDF that is roughly 35 duplicated pages. It also shows why releases 1.10 and older are one line per issue in the changelog while 1.11 and newer carry a paragraph: the old issues have a title and no release note, so there is nothing else to print. What has to be decided is what each of the two is FOR. Options, to be weighed by the maintainer: (a) CHANGELOG.md becomes the CURRENT release only - which is what a reader of the GitHub page or of PyPI wants to know - and the full history lives in the tracker page, which the documentation publishes; (b) CHANGELOG.md keeps every release but only as an index, one line per issue, and the release notes are printed only in the tracker page; (c) CHANGELOG.md is a repository artifact like README.md and leaves the documentation altogether, so that the published documentation has exactly one issue history; (d) leave both as they are. revision2026b step RG3.10.

    • notes: revision2026b step RG3.10. CHANGELOG.md and docs/generated/trackerlog.md are both written by issueTracker.py from the same store and both listed every resolved issue of every release - 2440 and 9153 lines, of which about 2370 were a shorter rendering of what the other says in full, roughly 35 duplicated pages in the PDF. CHANGELOG.md is now the CURRENT release with its release notes, and the table of all releases stays above it: 124 lines. The tracker page is everything BEFORE it, under the heading ‘Resolved issues and resolved bugs before version 1.12’, with a line pointing at the changelog for the current one: 8923 lines. Every issue is published and searchable, none twice. The pointer to the tracker page sits in the intro prose ABOVE the release block, because exudev release cuts RELEASE_NOTES.md from the first ‘## Version ‘ heading to the next one or to the end of the file, and with one block there is no next one. trackerlog.html keeps every issue and needed nothing: it is untracked and git-ignored. One existing test asserted the old property and now asserts the new one; a second says it from the tracker page’s side; a third covers the cut boundary, a changelog with a single ‘## Version’ block.

    • date resolved: 2026-09-24 10:15, date raised: 2026-09-23

  • 1.12.46 IMPROVEMENT NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG the TestModels import the test suite to find out whether they are being tested (#2632)

    • description: revision2026b step RG10.6, maintainer 2026-09-23. 125 of the 129 files in python/TestModels/ carry the same nine-line try/except block that imports exudynTestGlobals from modelUnitTests, and 90 of them also hard-code a reference solution that runTestSuite already holds. The step replaces both with exudyn.sys, which did not exist when the tests were written. The details, the recommendation and the options are in the plan step.

    • notes: revision2026b step RG10.6, eight sub-steps. A test model said it was being tested in nine lines and an import of modelUnitTests; it says it in one: testIsActive = exu.sys.get(‘testIsActive’, False). The runners write exu.sys[‘testIsActive’] and read exu.sys[‘testResult’], a model may state exu.sys[‘testTolerance’] instead of scaling its result, and the performance models add exu.sys[‘testTimings’] through AddTiming. 129 test models, 24 generated mini examples and 7 performance models are converted; modelUnitTests.py, runUnitTests.py and ExudynTestStructure are deleted; the ten ‘model unit tests’ are ordinary test models, which also revealed that they had not been running since V1.6; 99 hard-coded reference solutions went out of the models, since runTestSuiteRefSol.py holds them; and docs/dev/WORKFLOW.md documents the pattern for the first time - the old one had propagated by copy-paste for seven years without ever being written down. One reference solution moved on purpose (kinematicTreeAndMBStest, whose *= 1e-7 hid its tolerance inside its result); every other result is identical in the serial suite, the parallel suite, pytest and the performance runner.

    • date resolved: 2026-09-24 09:16, date raised: 2026-09-23

  • 1.12.45 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG restoring the saved render state takes two lines in 82 places (#2633)

    • description: revision2026b step RG6.5, maintainer 2026-09-24. SC.renderer.Stop() saves the render state of every open view in exudyn.sys, and every model and example that wants the previous view back writes the same two lines: if ‘renderState’ in exu.sys: SC.renderer.SetState(exu.sys[‘renderState’]). Measured: 82 occurrences in 85 files, in five spelling variants, four of them still using the deprecated SC.SetRenderState. exudyn.sys lives on the C++ side, so C++ can read it: SC.renderer.RestoreSavedState() does the whole thing and returns False when nothing has been saved yet, which is the ordinary case on the first run of a script and is why the two lines had a guard at all.

    • notes: revision2026b step RG6.5. SC.renderer.RestoreSavedState() restores the render state that SC.renderer.Stop() saved in exudyn.sys, and returns False when nothing has been saved yet - the first run of a script, which is what the old guard was for. It is C++ because the dictionary is C++: MainRenderer::RestoreSavedState(viewID) reads the key PyStopOpenGLRenderer writes (renderState for the main view, renderState<N> for the others) and hands it to the existing SetState; the binding comes from definitions/pybindRenderer.py, so the pybind header, the stub and docs/generated/cInterface/Renderer.md follow from one regeneration. The two-line idiom is gone from 85 files: 82 occurrences in five variants, of which four still used the deprecated SC.SetRenderState, with indentation of 0 to 12 spaces, two bracket spellings and one call on SC2 rather than SC. docs/manual/introductionBasics.md, tutorialRigidBody.md and GUI.md say the new form. python/testing/test_rendererState.py covers nothing-saved, a state that comes back, an unknown key, a bad value that raises as SetState does, and that no source file carries the old idiom any more.

    • date resolved: 2026-09-24 01:25, date raised: 2026-09-24

  • 1.12.44 EXTENSION NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG there is no way to see which settings differ from the defaults (#2590)

    • description: A user who wants to know what a model actually changed in simulationSettings or visualizationSettings has to compare by hand: both have GetDictionary(), and a default instance is one call away (exudyn.SimulationSettings(), exudyn.VisualizationSettings()), but nothing subtracts them. A helper in the utilities should print the difference AS PYTHON CODE, so that it can be pasted into a script and reproduces the settings - which is also what makes a session in the visualization dialog reusable. Worth considering as additional information in solution and sensor files, for reproducibility. The GUI should show the same thing for the current settings.

    • notes: revision2026b step RG12.3. ChangedSettings, ChangedSettingsCode and PrintChangedSettings say which settings a model changed, as the Python that sets them, for visualizationSettings and simulationSettings alike. They live in the new exudyn.misc.settingsUtilities, which is the window-free half of exudyn.misc.GUI: that module imports tkinter at module scope, because the dialog class inherits from tk.Frame, so a model script on a machine without tkinter could not use any of it. 322 lines moved - the type predicates, the conversions and the settings layer of RG6.2.8 to RG6.2.10 - and the names stay importable from exudyn.misc.GUI, which is where they were public. A reference argument turns ‘differs from the defaults’ into ‘changed since this moment’, which is what the dialog calls changes since start. Tests: a fresh interpreter imports the module and ‘tkinter’ in sys.modules must be False, and the generated block is exec-ed against a fresh structure and must reproduce the settings it was read from. No C++ change for solution files: solutionSettings.solutionInformation is already written into the solution header and takes the block as it is, which the docstring says.

    • date resolved: 2026-09-24 00:14, date raised: 2026-09-22

  • 1.12.43 BUG NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG dialogs.fontScaling only works at 0: the rows and the columns do not follow the font (#2631)

    • description: revision2026b step RG6.2.23, maintainer 2026-09-23. Setting dialogs.fontScaling=1.0 gives a larger font but much too small a row height and too narrow columns, and changing the value does not help - only 0.0 is usable. Measured with a withdrawn Tk root: DialogScaling sets systemScaling=fontScaling when fontScaling>0, and systemScaling is what the row height and the column width are computed from - TkTextHeight returns int(treeviewDefaultFontSize*textHeightFactor*systemScaling), which is 13 pixels at fontScaling=1.0 while the font really renders with a linespace of 16 to 18 pixels, because the point-to-pixel conversion follows the tk scaling that GetGUIContentScaling set and fontScaling never touches. The columns are worse: the scale factor is max(1,int(round(systemScaling))), an INTEGER, so it is 1 for every fontScaling below 1.5. The fix is to stop guessing: the row height and the column width are MEASURED from the font the tree will actually use (linespace and the width of the digits), so that any fontScaling works and the default appearance is unchanged.

    • notes: revision2026b step RG6.2.23. dialogs.fontScaling works at any value now. DialogScaling set systemScaling=fontScaling, and the row height and the column width were computed from that number, which is not what decides how large a glyph comes out: the point-to-pixel conversion follows the tk scaling of the display. Measured with a withdrawn Tk root: at fontScaling=1 the rows were 13 pixels for a font whose linespace is 16 to 18, so the text was clipped, and the column factor max(1,int(round(systemScaling))) was an integer and stayed at 1 for every value below 1.5. The new DialogRowMetrics(root, fontFactor) builds the font the tree will use and asks it: the row height is metrics(‘linespace’) times rowHeightFactor=1.15, chosen to reproduce the pixel height the dialog had at the default font, and the column scale is the width of the digits in that font over the width in the unscaled one. Measured after: fontScaling 1.0/1.25/1.5/2.0 gives row heights 17/20/25/31 and column scales 1.00/1.14/1.57/1.86. The default appearance is unchanged - at fontScaling=0 the column scale is exactly 1 and the row height is within a pixel of what it was. A test requires every row to be at least as tall as the linespace of its own font.

    • date resolved: 2026-09-23 23:30, date raised: 2026-09-23

  • 1.12.42 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG a double click on a bool setting no longer toggles it (#2630)

    • description: revision2026b step RG6.2.22, maintainer 2026-09-23. It used to switch True/False and it does not any more. The cause is the cell editor of RG6.2.4 (#2604): the tree binds ButtonRelease-1 to OnTreeEdit, which opens the editor immediately, and for a bool that is a Combobox placed OVER the value cell. The second click of a double click therefore lands on the combobox, not on the tree, so the Double-1 binding never fires and the toggle in OnTreeEditOrDoubleClick is unreachable. The toggle code itself is intact. Fix: for a bool row the cell edit is scheduled with after(…) instead of opened at once, and a double click cancels that job and toggles; every other type keeps the immediate editor, so nothing else becomes slower.

    • notes: revision2026b step RG6.2.22. A double click on a bool setting toggles it again. The toggle code was never removed: RG6.2.4 (#2604) bound the cell editor to ButtonRelease-1, and for a bool that editor is a Combobox placed OVER the value cell, so the second click of a double click landed on the combobox and the Double-1 binding on the tree never fired. On a bool row the cell edit is scheduled with after(220 ms) now and a double click cancels the job before it fires; every other type keeps the editor that opens at once, so nothing else became slower. Checked with a withdrawn Tk root: a single click arms the job and changes nothing, the double click toggles True to False and back, each as its own undo step, and a float row schedules nothing and has its editor up immediately.

    • date resolved: 2026-09-23 23:30, date raised: 2026-09-23

  • 1.12.41 BUG NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the item header emitter writes files in the locale encoding, not UTF-8 (#2629)

    • description: revision2026b step RG9.2, found while regenerating for #2628. tools/generators/itemHeaderEmitter.py reads an existing generated header with encoding=’utf8’ but writes it with a bare open(fileName,’w’), which uses the LOCALE encoding - cp1252 on this Windows machine. It only bites when a header that contains a non-ASCII character is rewritten: CObjectFFRF.h and CObjectFFRFreducedOrder.h carry the author name Zwoelfer with an o-umlaut, and the moment RG9.2 changed every user-function header, those two were written as cp1252 and the NEXT run of the generator could not read them back - UnicodeDecodeError, byte 0xf6, and the whole regeneration step failed. The committed files were valid UTF-8 before, so this had been latent for as long as those two headers did not change. The write gets encoding=’utf8’.

    • notes: revision2026b step RG9.2. tools/generators/itemHeaderEmitter.py now writes the generated item headers with encoding=’utf8’; it read them with it already, and the bare open(fileName,’w’) used the locale encoding, so a header with a non-ASCII author name was written as cp1252 on Windows and the next run of the generator failed to read it back (UnicodeDecodeError, byte 0xf6). Latent until RG9.2 changed every user-function header and rewrote CObjectFFRF.h and CObjectFFRFreducedOrder.h, whose author line carries an o-umlaut.

    • date resolved: 2026-09-23 22:54, date raised: 2026-09-23

  • 1.12.40 IMPROVEMENT NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG fourteen item sources include ExceptionsTemplates.h without using it, and pay pybind11 for it (#2628)

    • description: revision2026b step RG9.2, from the measurement of RG9.1 (#2622). src/Utilities/ExceptionsTemplates.h is included by 17 sources in src/ImplObjects/, and exactly ONE of them uses anything from it: CObjectANCFBeam.cpp:45 calls GenericExceptionHandling; CObjectFFRF.cpp:423 and CObjectFFRFreducedOrder.cpp:459 have their call commented out. The header defines no macros - it is four function templates - and it includes pybind11/pybind11.h at line 19, which is the ONLY route to pybind11 for eight of those sources: the seven CObjectConnectorCoordinate/CoordinateSpringDamper/CoordinateSpringDamperExt/CoordinateVector/Gravity/HydraulicActuatorSimple/SpringDamper and CObjectJointRollingDisc. So the fix is deletion, not restructuring: the include goes from the fourteen sources that refer to nothing in it. NOT part of this: hiding the py:: uses (the error_already_set and builtin_exception catches at lines 59, 94, 111, 143, 155) behind a non-template helper - they sit in template bodies, and RG9.1 measured that decoupling 33 sources moved the build clock by nothing, so that complexity has no evidence behind it.

    • notes: revision2026b step RG9.2. src/Utilities/ExceptionsTemplates.h was included by 17 sources in src/ImplObjects/ and used by exactly one (CObjectANCFBeam.cpp:45, GenericExceptionHandling); two more have their call commented out. The include is gone from the fourteen that referred to nothing in it, and the number of item sources reaching pybind11 fell from 19 to 11 - the eight whose only route it was now compile without it. The build then found what the include had been hiding: the generated header of every item with a user function (24 of them) names py::object and had been taking the namespace py alias from whatever happened to be included before it; two failed at once. itemHeaderEmitter.py emits the alias beside the Pymodules/PythonUserFunctions.h it already emitted, which only forward declares pybind11::object and costs no pybind11 - the same shape as the four VisuObject*.h headers in RG9.1. Clean build 56.4 s against 58.0 s after RG9.1 and 57.1 s before it: the time did not move, the dependency did. Deliberately NOT done: hiding the py:: uses of the header behind a non-template helper - they sit in template bodies and there is no measurement supporting the complexity. test_cppIncludes.py holds the count at 11.

    • date resolved: 2026-09-23 22:51, date raised: 2026-09-23

  • 1.12.39 BUG raised by: Claude-JG resolved by: Claude-JG reading a deprecated visualization setting on a standalone VisualizationSettings segfaults (#2603)

    • description: Two lines of pure Python kill the process: ‘import exudyn as exu; exu.VisualizationSettings().general.drawWorldBasis’ exits with a segmentation fault (verified 2026-09-23, exit code 139). It is not that member: EVERY one of the 93 deprecated members of visualizationSettings does it, on read and on write. The cause is the backlink. A deprecated member forwards to its replacement through ‘backlink->view0.scene.drawWorldBasis’ (src/Autogenerated/VisualizationSettings.h), the backlink of every sub-structure is set by VisualizationSettings::Init(&settings), and that call happens in exactly ONE place - VisualizationSystemContainer.h line 153, i.e. for the settings that belong to a SystemContainer. A VisualizationSettings that Python constructs on its own never gets Init called, so every backlink stays nullptr and the first deprecated access dereferences it. Through SC.visualizationSettings everything works. The same will apply to SimulationSettings as soon as RG12.1 gives it deprecated members. A fix has to decide what a copy of a settings structure means - a constructor that calls Init(this) is one line, but a copied object would then carry a backlink to the original. Found while adding dialogs.fontScaling in revision2026b step RG6.2.3.1 (#2602), whose deprecated fontScalingMacOS behaves exactly like the 93 others.

    • notes: revision2026b step RG4.4. exu.VisualizationSettings().general.drawWorldBasis no longer segfaults, and neither do the other 92 deprecated members: the top settings class calls Init(this) in its default constructor, so a structure that Python builds links its own sub-structures instead of leaving every backlink at nullptr. The question the step left open - what a COPY means - is answered in the generated code: the top class defines a copy constructor and a copy assignment that copy the members and then call Init(this), because the implicit ones would leave the copy pointing at the original, so writing a deprecated member of the copy would change the original’s replacement. The same emitter will give simulationSettings the same code when RG12.1 gives it deprecated members. In addition every deprecated forwarding now checks its backlink and raises with a sentence naming the member and its replacement instead of dereferencing nullptr, which is what a standalone sub-structure such as exu.VSettingsGeneral() still hits. python/testing/test_settingsBacklinks.py reads every member of a standalone structure and of a container’s - 314 read, 93 deprecated, zero problems - because a segfault cannot be caught and touching everything is the only way to find one.

    • date resolved: 2026-09-23 21:47, date raised: 2026-09-23

  • 1.12.38 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the light and shadow descriptions of visualizationSettings are misleading (#2609)

    • description: revision2026b step RG6.4. Two things, both from the maintainer, 2026-09-23. First, every member of a light repeats “of GL_LIGHT0” (1,2,3): within a light that is noise and it should read “of this light”, with the mapping of light0..light3 to GL_LIGHT0..GL_LIGHT3 said once, at the enable flag of the light. Second, the remarks are out of date: they say light0 is the one used for shadows, which was a performance decision that no longer holds - every light can cast shadows now. And the sentence “approximates directional lights by enlarging the direction to 200 times maxSceneSize” belongs to the shadow settings, not to a light, and it should not name a factor that has already changed once and will change again.

    • notes: revision2026b step RG6.4. The six members of VSettingsLight that repeated ‘of GL_LIGHT[0,1,2,3]’ read ‘of this light’ now, and the mapping - light0 to light3 are OpenGL GL_LIGHT0 to GL_LIGHT3 - is stated once, at enable. The claim in position that light0 is the light used for shadows is gone: shadow says that every light can cast one and that the effects accumulate, which the raytracer half of the same description had said all along. The directional-light approximation moved from position, where it described shadows rather than a light, into shadow, and it names no factor any more - ‘a multiple of maxSceneSize’ instead of ‘200 times maxSceneSize’, because a constant that lives only in a description is wrong the day someone tunes it. A stale reference to light0Position in shadowSmoothingSteps and two deprecated names in docs/manual/introductionBasics.md (openGL.enableLight1, openGL.light0position) went with them.

    • date resolved: 2026-09-23 21:39, date raised: 2026-09-23

  • 1.12.37 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the defaults of the lights and the raytracer materials are hidden in C++ constructors (#2626)

    • description: revision2026b step RG6.2.20. exu.VisualizationSettings() is not the state a user starts from: VisualizationSystemContainer() overrides nine light settings in its constructor (light1-3 diffuse, specular, enable, light1.position) and MainGraphicsMaterialList::Reset() fills the ten raytracer materials, about 59 values in total. That is why the settings dialog cannot say what differs from the defaults without creating a SystemContainer - which it must not do (#2625). The values belong in definitions/structureDefsVisualizationSettings.py as the defaultValue of the members, so that the generated structure carries them and the constructor is the truth; the C++ lines then go. Behaviour does not change, since the container sets the same values today. [2026-09-23, Claude-JG]: MAINTAINER, 2026-09-23, after testing ‘diff to default’ in 1.12.34, and it sharpens what has to be fixed: the dialog compares against the defaults of the STRUCT TYPE - VSettingsMaterial and VSettingsLight - but a user never sees those. What the renderer uses are the defaults of material0, material1, … and of light1, light2, light3, which are set LATER, in C++ constructors, and which differ from the struct defaults for diffuse, specular and enable. So ‘diff to default’ is not merely noisy, it compares against a state that does not exist. The maintainer asks for a SOLID fix, not a filter: the per-instance defaults must become the defaults, so that they can also be written in the documentation - which today cannot state what the default of light1.diffuse is, because the generated reference shows the struct default and the renderer uses another value. That means the defaultValue of the members of the light and material INSTANCES in definitions/structureDefsVisualizationSettings.py, after which the C++ lines in VisualizationSystemContainer() and MainGraphicsMaterialList::Reset() go, the generated docs are right, and exu.VisualizationSettings() is the state a user starts from.

    • notes: revision2026b step RG6.2.20. The defaults of the three dimmed lights and of the ten raytracer materials are defaults of the STRUCTURE now, not values set by C++ after construction. StructureParameter gained memberDefaults - for a member whose type is another structure, this instance’s own starting values, written as that sub-member’s defaultValue would be - and the 89 values (80 material, 9 light) are in definitions/structureDefsVisualizationSettings.py. structureHeaderEmitter.py writes them into the generated constructor; the lines in VisualizationSystemContainer() are gone and MainGraphicsMaterialList::Reset() copies from a fresh VSettingsRaytracer. structureDocsEmitter.py appends them to the reference row, so the documentation can finally state what light1.diffuse and material1.baseColor start from, and the apology in the class description is gone. All 89 values were read out of the C++ at the previous commit, parsed and compared: identical. containerInitialisedSettings in exudyn.misc.GUI is empty, the note in the diff window is gone, and the test of RG6.2.19 now requires the difference between a SystemContainer and a plain exu.VisualizationSettings() to be empty; test_settingsDefaults.py pins the values.

    • date resolved: 2026-09-23 21:12, date raised: 2026-09-23

  • 1.12.36 FIX NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the settings dialog asks before reset and revert, and undo does not take them back (#2627)

    • description: revision2026b step RG6.2.21, maintainer 2026-09-23 after using the dialog. Two things about the second button row. (1) reset and revert each ask a yes/no question that was never asked for and is not needed: a wrong click is taken back by undo or by revert, so a question that is always answered with yes is only in the way. Both are gone. (2) undo went back ONE VALUE and was switched OFF by reset and revert, which are exactly the two clicks one would want to take back. The maintainers own proposal is the fix: undo goes back to the PREVIOUS STATE. The dialog now keeps a stack of whole states - about 470 short strings per entry, which costs nothing next to the redraw it triggers - pushed by a single edited value, by reset and by revert alike, so a chain of them is taken back one by one.

    • notes: revision2026b step RG6.2.21. The settings dialog no longer asks before reset and before revert - a wrong click is taken back by undo or by revert, so a question that is always answered with yes was only in the way. And undo now goes back to the PREVIOUS STATE instead of one value: the dialog pushes the whole state (the ~470 value strings the tree shows) onto a stack before a single edit, a bool toggle, a reset and a revert alike, and undo pops one, so a chain of them comes back one by one and the button disables itself when the stack empties. ApplyValues gained one argument, pushUndo, false only for the undo itself.

    • date resolved: 2026-09-23 20:42, date raised: 2026-09-23

  • 1.12.35 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the item sources pay for pybind11 through the graphics helpers (#2622)

    • description: revision2026b step RG9.1, proposed at the maintainers request 2026-09-23. src/Graphics/VisualizationItemHelpers.h is included by every C<Item>.cpp that draws something, and it includes Graphics/VisualizationSystemContainer.h, which includes pybind11 - the dependency the per-item split of revision2026 step R11.4.4 was meant to avoid. Measured: the py:: in that header is six free-function declarations called from two .cpp files, easily moved; but the header also includes Main/CSystem.h (its own “REMOVE: temporary” line), and CSystem.h includes Pymodules/PythonUserFunctions.h, which includes pybind11. An experiment with that include removed fails ONLY in Graphics/VisualizationSystem.h lines 33-34, which declare PostProcessData* and CSystemData* members without including their headers - and both of those headers are pybind-free. Acceptance is the build time before and after, which exudev prints since #2617: 57.9 s today.

    • notes: revision2026b step RG9.1. The graphics headers no longer include pybind11: VisualizationSystem.h includes Main/CSystemData.h and Graphics/PostProcessData.h itself (in that order - PostProcessData.h uses CSystemState and includes nothing), VisualizationSystemContainer.h drops its temporary Main/CSystem.h, and the six Py…BodyGraphicsData… declarations move to the new Graphics/BodyGraphicsDataPython.h. Two generated headers were free-riding on the same include and now say what they need: the four VisuObject*.h with a graphicsDataUserFunction include Pymodules/PythonUserFunctions.h, which only forward declares pybind11::object, and the eight MainObject*.h with a BodyGraphicsData parameter include the new header; itemHeaderEmitter.py emits both. Measured on a clean build: of the 52 sources in src/ImplObjects/, 52 reached pybind11 before and 19 after, and those 19 for reasons of their own (user functions, PyMatrixContainer, pybind11/numpy.h, ExceptionsTemplates.h), none through the graphics headers. The build time did NOT change: 57.1 s before, 58.0 s after - the gain is structural, not in the clock. python/testing/test_cppIncludes.py walks the include graph and holds both properties.

    • date resolved: 2026-09-23 20:18, date raised: 2026-09-23

  • 1.12.34 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG opening the settings dialog closes the render window (#2625)

    • description: revision2026b step RG6.2.19. Reported by the maintainer 2026-09-23 and traced in the C++: MainSystemContainer() calls AttachToRenderEngineInternal() in its CONSTRUCTOR, and its destructor calls Reset(), which calls visualizationSystems.DetachFromRenderEngine(). So a temporary SystemContainer created while a renderer runs takes the render window away from the real container and gives it back to nothing - the window closes. DefaultSettingsDictionary (#2612) creates one to read the defaults every time the settings dialog opens. It must not: the reference goes back to exu.VisualizationSettings(), and the window that lists the differences says which settings a SystemContainer initialises and therefore always appear there.

    • notes: The settings dialog creates no SystemContainer any more: MainSystemContainer() attaches to the running render engine in its constructor and detaches in its destructor, so the temporary container that #2612 created to read the defaults took the render window away from the container that owns it - opening the dialog closed the window. The reference is exu.VisualizationSettings() again, and the window listing the differences says which settings a SystemContainer initialises instead of reporting them as changed; #2626 removes the need for that note. The dialog also gives up its -topmost while that window is open, so it no longer comes up behind it.

    • date resolved: 2026-09-23 18:17, date raised: 2026-09-23

  • 1.12.32 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG opening the settings dialog re-points exudyn.sys at a throw-away SystemContainer (#2623)

    • description: revision2026b step RG6.2.17. Constructing an exudyn.SystemContainer() REPLACES exudyn.sys[“currentRendererSystemContainer”] - measured 2026-09-23. DefaultSettingsDictionary (#2612) creates one to read the defaults, so from the moment the settings dialog opens, everything that asks for the renderers container gets the throw-away one: ApplyDialogWindowSettings reads topmost and alpha from it, and UpdateSettingsStructure sends the redraw signal to it, so a settings change stops reaching the renderer. Once the temporary is collected, reading a member of it is an access violation (“no RTTI data”), which is what made the two change windows do nothing at all. The entry is saved and restored around the construction, and GetRendererSystemContainer also catches RuntimeError, because a dangling container must not take the dialog down.

    • notes: DefaultSettingsDictionary saves and restores exudyn.sys[“currentRendererSystemContainer”] around the SystemContainer it creates to read the defaults: constructing one replaces that entry, so since #2612 the settings dialog handed the renderer a throw-away container - the redraw signal went to it, the window settings were read from it, and once it was collected, touching it was an access violation, which is what made the two change windows do nothing. GetRendererSystemContainer also catches RuntimeError now.

    • date resolved: 2026-09-23 17:56, date raised: 2026-09-23

  • 1.12.31 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the window with the changes is invisible, and the buttons sit under the scroll bar (#2621)

    • description: revision2026b step RG6.2.16. Maintainer, 2026-09-23: “diff to default” and “this session” show nothing. The content is right - a probe that builds the dialog without mapping a window finds the changes and raises nothing - so the window itself never becomes visible: the settings dialog is topmost, and the Toplevel opens at the same position behind it. It is made modal (grab_set), lifted, focused and offset from the dialog, so that it cannot hide behind it. Two more from the same message: “this session” is called “changes since start”, and the button rows at the top and the bottom span the columns of the tree only, so that the right-most button no longer sits under the vertical scroll bar of the tree.

    • notes: The window that shows the changes of the settings dialog is transient to the dialog, topmost, offset by 60 pixels and modal, so it can no longer open behind the dialog - which is why “diff to default” and “this session” appeared to do nothing although their content was right. The button is called “changes since start”, and the rows at the top and the bottom span the columns of the tree only, so that no button sits under its vertical scroll bar.

    • date resolved: 2026-09-23 17:50, date raised: 2026-09-23

  • 1.12.30 CHANGE NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the demos write a solution directory into whatever directory they are started in (#2620)

    • description: revision2026b step RG11.2. exudyn.demos.Demo1 and Demo2 write solution/demo1.txt and solution/chain.txt, so “python -m exudyn demo 2” creates a solution/ directory in the current directory - in the repository that is an untracked directory beside the sources, which was almost committed by accident. They write to tmp/solution/ instead, which is git-ignored here and is created if it is missing, and solution/ is added to .gitignore so that an older version cannot leave one lying around unnoticed. Maintainer, 2026-09-23.

    • notes: The demos write to tmp/solution/ instead of solution/, through one function that creates the directory when it is missing, so “python -m exudyn demo 2” no longer leaves an untracked directory in whatever directory it was started in; solution/ is in .gitignore as well, because an installed older version still writes there.

    • date resolved: 2026-09-23 17:50, date raised: 2026-09-23

  • 1.12.29 IMPROVEMENT NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG VS Code cannot follow a C++ include, because it has no include paths (#2619)

    • description: revision2026b step RG10.5. In VS Code the C/C++ extension reports “include errors detected - update your include paths” and “cannot open source file ../Eigen/Sparse (dependency of Main/CSystem.h)”, so navigation to an included file does not work. The reason: the vendored headers are found through include/lest, include/glfw and include/pybind11local - a quoted include like “../Eigen/Sparse” resolves against those subdirectories - and nothing tells the extension about them. .vscode/ is git-ignored, so the fix follows the pattern of exudynTemplate.sln and pytestTemplate.py: a committed template that tools/setupLocalWorkspace.py copies into .vscode/. Maintainer, 2026-09-23.

    • notes: tools/vscodeCppPropertiesTemplate.json is copied to .vscode/c_cpp_properties.json by tools/setupLocalWorkspace.py, so VS Code can follow a C++ include: the vendored headers are reached through subdirectories of include/ - “../Eigen/Sparse” resolves as include/lest/../Eigen/Sparse - and the C/C++ extension knew none of those paths.

    • date resolved: 2026-09-23 17:25, date raised: 2026-09-23

  • 1.12.28 CHANGE NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG src/pythonGenerator holds one file and should not exist any more (#2618)

    • description: revision2026b step RG10.4. Everything of the old generator directory moved to tools/generators/ in revision2026 step R4.3 except exudynVersion.py, which locates the repository root and reads version.txt. Three places use it: setup.py and conf.py exec() it, and itemDocsEmitter.py imports it through a sys.path entry that generatorPaths.py adds for that single file. It moves to tools/generators/, where the other build-time helpers already live and are already in MANIFEST.in, and src/pythonGenerator/ is deleted. Maintainer, 2026-09-23.

    • notes: exudynVersion.py moved to tools/generators/, where the other build-time helpers live, and src/pythonGenerator/ is gone - it had held that one file since revision2026 step R4.3. setup.py, conf.py, generatorPaths.py, MANIFEST.in and the developer documentation name the new path; the sys.path entry that existed for that single file is gone.

    • date resolved: 2026-09-23 17:25, date raised: 2026-09-23

  • 1.12.27 IMPROVEMENT NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG exudev does not say how long a step took (#2617)

    • description: revision2026b step RG10.3. The batch scripts exudev replaced printed the build time, and the maintainer reads it: a build that suddenly takes twice as long is the first sign that a header dependency grew. The summary table names each step and its verdict and says nothing about time. Every step is timed and the summary prints it, with the total. Maintainer, 2026-09-23.

    • notes: exudev times every step and prints the seconds in the summary table, with a total; the build time was visible in the batch scripts it replaced and is the first sign that a header dependency grew.

    • date resolved: 2026-09-23 17:25, date raised: 2026-09-23

  • 1.12.26 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG quitting the renderer BEFORE a simulation starts raises, quitting during it does not (#2616)

    • description: revision2026b step RG4.5. Closing the render window or pressing ESCAPE while a script waits - “Computation paused… press SPACE to continue / Q to quit” - sets forceQuitSimulation, and CSolverBase::SolveSystem then returns false before the solver ever starts. SolveDynamic reads false as a failure, prints the DYNAMIC SOLVER FAILED block and raises SolverError, so a user who simply quit gets a traceback. Stopping the SAME simulation one step later does not: SolveSteps returns !conv.stepReductionFailed, which is true when the user stopped it, and the script ends quietly. The two paths must agree, and the quiet one is the right one - a user stopping a run is not a solver failure. Reported by the maintainer 2026-09-23 from “python -m exudyn demo 2”.

    • notes: CSolverBase::SolveSystem returns true when the simulation was already stopped by the user before it started, instead of false: SolveDynamic and SolveStatic read false as a solver failure and raised SolverError, so closing the render window while a script waited ended in a traceback - while stopping the same simulation one step later has always been quiet. The note says that nothing was computed. NOT tested: forceQuitSimulation is set by GlfwClient.cpp alone and has no Python binding, so the state cannot be produced without a window; mbs.SetRenderEngineStopFlag sets the other flag, stopSimulation.

    • date resolved: 2026-09-23 17:06, date raised: 2026-09-23

  • 1.12.25 EXTENSION NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG a settings folder has a description in the definitions, and nothing shows it (#2615)

    • description: revision2026b step RG6.2.15. Every settings structure carries classDescription in definitions/ - “General settings for visualization that influence all windows, …” - and it reaches the reference manual and the C++ header comment, but not GetDictionaryWithTypeInfo, so the dialog has nothing to show when the mouse is over a folder. Only the leaves have a description there. The emitter should put the class description into the dictionary with type info under a reserved key, the way itemIdentifier is reserved, and the tooltip of the dialog should show it for a folder. Maintainer, 2026-09-23.

    • notes: GetDictionaryWithTypeInfo carries the class description of a settings structure under the reserved key structureDescription, so the settings dialog can show what a FOLDER is when the mouse rests on it; it had a description for the leaves only. GetDictionary is untouched, so nothing a script does changes.

    • date resolved: 2026-09-23 16:54, date raised: 2026-09-23

  • 1.12.24 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the settings dialog needs reset, revert, undo and close - and its windows must stay in front (#2614)

    • description: revision2026b step RG6.2.14. Maintainer, 2026-09-23, after using the dialog. The bottom gets a second row: “diff to default” and “this session” on the left, and on the right “reset” (to the defaults), “revert” (to the state the dialog opened with), “undo” (the last change, one step, greyed when there is nothing to undo) and “close” (what ESCAPE does). Every button gets a tooltip saying what it does, including the two existing ones. The tooltips of the tree open after a delay of 0.5 seconds - they are annoying while the mouse crosses the tree, and the find of RG6.2.10 means nobody has to sweep through the settings any more. And the window that shows the changes appeared BEHIND the dialog the second time it was opened, because the dialog is topmost (which it has to be, since it blocks the render window).

    • notes: The settings dialog has a second button row: diff to default and this session on the left, reset, revert, undo and close on the right. Reset and revert ask before they throw away what the model set; undo goes one step back and is greyed when there is nothing to undo. Every button has a tooltip saying what it does, and the tooltips open after 0.5 seconds instead of immediately. The window showing the changes is transient to the dialog and topmost, so it no longer appears behind it.

    • date resolved: 2026-09-23 16:54, date raised: 2026-09-23

  • 1.12.23 IMPROVEMENT NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG the find bar of the settings dialog needs no button, and says nothing when idle (#2613)

    • description: revision2026b step RG6.2.13. Maintainer, 2026-09-23, after using it: the search runs while the text is typed, so the “find” button is not needed and goes. The drop-down of the hits looks like something to click even when nothing has been searched for; it is greyed out until there is a search text.

    • notes: The find bar of the settings dialog lost its button - the search runs while the text is typed - and the drop-down of the hits is greyed out until there is a search text.

    • date resolved: 2026-09-23 16:54, date raised: 2026-09-23

  • 1.12.22 BUG HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the settings dialog calls 59 untouched settings changed, and marks no folder (#2612)

    • description: revision2026b step RG6.2.12. “diff to default” of RG6.2.9 compares against exu.VisualizationSettings(), a settings structure Python builds on its own - and a SystemContainer initialises 59 of them when it is created: the four lights and the ten raytracer materials. A user who changed nothing therefore sees all lights and all materials reported as changed, which the maintainer found in demo 2 (2026-09-23). The reference must be the state a user actually starts from, exu.SystemContainer().visualizationSettings. Second half of the same step: a changed value in a folded folder is invisible, so a folder whose subtree holds a changed value must be marked as well.

    • notes: The difference is measured against exu.SystemContainer().visualizationSettings instead of exu.VisualizationSettings(): a SystemContainer initialises 59 settings when it is created - the four lights and the ten raytracer materials - so the dialog reported all of them as changed for a user who changed nothing. A folder whose subtree holds a changed value is now marked as well, so that a folded folder does not hide the change.

    • date resolved: 2026-09-23 16:54, date raised: 2026-09-23

  • 1.12.21 IMPROVEMENT NORMAL HIGH EFF raised by: Claude-JG resolved by: Claude-JG the settings dialogs work but are hard to use, and GUI.py is hard to change (#2591)

    • description: python/exudyn/GUI.py does its job with tkinter - it runs everywhere and needs no installation - but it is in bad shape, and the dialogs are called from rendererPythonInterface.cpp, which executes Python inside C++. What the maintainer names (2026-09-22): the table of the visualization settings is restricted; illegal input is caught but there are no type hints; the font size cannot be adjusted on Linux; the columns can hardly be adjusted; a description should appear in a pop-up rather than only with a special key; fields cannot be edited inline; combo boxes are unhandy. Two things changed the ground under it: revision2026 step R4.10 makes the parameter TYPES available to Python, and the interface is generic enough that a second front end (Qt6, or a form that takes Qt5 and Qt6) would be a small overhead on top. A snapshot of the dialog as it is: docs/theDoc/figures/visualizationSettings.png in the history.

    • notes: The settings dialogs and GUI.py, in ten sub-steps: the dialogs left rendererPythonInterface.cpp, the layer under the widgets got tests, the validator was made to agree with the settings, one dialogs.fontScaling replaced fontScalingMacOS, the value is edited in its cell, the bottom row is the line that sets it, a setting differing from the defaults is shown in colour and can be copied as code, and a find bar with CTRL+F searches names first and descriptions second. The key bindings of the render window come from ONE table in exudyn.misc.keyBindings: the help dialog and the tables of the manual are generated from it, and a test compares it with GlfwClient.cpp - which found five bindings documented nowhere (H, R, CTRL+R, CTRL+V, CTRL+7) and the keypad rotation keys named wrongly in both copies. GUI.py was cleaned up last: the dead EXAMPLE block and 32 lines of commented-out code removed, the bare prints turned into exudyn.Print with WARNING/ERROR and the name of the function, and the dialog no longer writes treeEditOpenItems, which is the user configuration - what was open is remembered in treeEditLastOpenItems. A second front end (RG6.2.5) was dropped by the maintainer.

    • date resolved: 2026-09-23 15:10, date raised: 2026-09-22

  • 1.12.20 EXTENSION NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG settings dialog: find a setting by name, with CTRL-F (#2607)

    • description: revision2026b step RG6.2.10. The visualization settings are several hundred values in a tree of folders, and the only way to a setting is to know which folder it is in. A find is needed: CTRL-F and a find button, searching the NAMES first and the descriptions second, and jumping to the row that is chosen - which means expanding its folders, selecting it and scrolling it into view. The form is to be decided in this step; a recommendation is in the plan. Maintainer, 2026-09-23.

    • notes: A find bar above the settings tree: CTRL+F puts the cursor in it, RETURN or F3 or the find button steps to the next hit and around at the end, and a drop-down lists the hits so that one can be picked. It searches the names first and the descriptions second, and a description hit is labelled with the piece of description that matched. A hit is jumped to rather than filtered to: the folders it sits in are opened and the row is scrolled into view. FindMatches is a module level function on the leaf list, with tests for the order and for the promise that every hit names a setting the tree holds. The manual section on the visualization settings dialog now also says how the dialog is used at all.

    • date resolved: 2026-09-23 14:26, date raised: 2026-09-23

  • 1.12.19 IMPROVEMENT NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG settings dialog: a changed value should be visible, and all changes copyable at once (#2606)

    • description: revision2026b step RG6.2.9. Nothing in the tree says which values differ from what the dialog started with, so a user who has edited ten settings cannot see the ten. A changed row is shown boldface or in a colour (a blue that is dark enough to read), and a second button at the bottom copies every change at once, as the lines that set them. That is RG12.3 for one dialog session, and the two share the question of what “changed” means: against the value the dialog opened with, or against the defaults. Maintainer, 2026-09-23.

    • notes: A setting that differs from the Exudyn defaults is shown in blue and bold, from the moment the dialog opens. Two buttons at the bottom open a window that shows the changes as the code that makes them and copies it: “diff to default” for everything differing from the defaults, “this session” for what was edited since the dialog was opened. The comparison is on the string the dialog shows, not on the value, which is what makes a single precision float and an enum comparable; SettingsCodeLines and SettingsValueStrings are module level functions on dictionaries, so the marking, the windows and the tests are one piece of code.

    • date resolved: 2026-09-23 14:20, date raised: 2026-09-23

  • 1.12.18 IMPROVEMENT NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG settings dialog: the pastable line needs to look like code, and it is said twice (#2605)

    • description: revision2026b step RG6.2.8. The line that sets the selected item (RG6.2.4, #2604) works, but it does not read as code: it uses the dialog font at dialog size and sits on the window background. It should be smaller, in the same fixed font the cells use, and set apart by a box or a background of its own. The label under it repeats the description that the pop-up already shows in full, and that repetition goes. The button says “copy”, which does not say what is copied; it becomes “copy line” (or “copy last edit”), because a second button for all changes joins it in RG6.2.9. Maintainer, 2026-09-23.

    • notes: The line that sets the selected setting sits in a box of its own now, in the font of the cells one size smaller, and the button says “copy line”. The label under it is gone with the description it repeated - the tooltip shows that, and it carries the size of a vector or matrix setting as well. SettingsLeafList, ValueLiteral and SettingsPrefix left the tkinter class and are module level functions on dictionaries, so that they can be tested without a window; test_guiValues.py checks that every literal the dialog writes, for every setting of both structures, is one Python reads back.

    • date resolved: 2026-09-23 14:10, date raised: 2026-09-23

  • 1.12.17 DOCU NORMAL LOW EFF raised by: Claude-JG resolved by: Claude-JG “The C++ core” points at the repository instead of at the developer documentation (#2611)

    • description: revision2026b step RG3.11. The section stays - the maintainer wants it - but it sends the reader to GitHub URLs of files that are now published pages of this documentation (revision2026b step RG3.2). It should link to the developer documentation as a whole and to its architecture and coding style pages, and it should say that for a deeper understanding of the core, and for low-level changes, there is no way around the GitHub project itself. Maintainer, 2026-09-23.

    • notes: The “C++ core” section of Advanced topics now links to the developer documentation as published pages - the developer documentation itself, the C++ architecture and the coding style - instead of to raw files on GitHub, and it says that a deeper understanding of the core and any low-level change means visiting the GitHub project itself.

    • date resolved: 2026-09-23 12:36, date raised: 2026-09-23

  • 1.12.16 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG the settings dialog edits a value far away from the row it belongs to (#2604)

    • description: In TkinterEditDictionaryWithTypeInfo the value is not edited in the table: an Entry and a Combobox sit at the bottom of the window, occupy the same grid cell and swap places by z-order (lower()/lift()), so a user selects a row at the top and types at the bottom, and which of the two widgets is in front depends on the type of the selected item. Wanted (maintainer, 2026-09-22, refined 2026-09-23): edit IN THE CELL, and let the bottom row say what the selected item is instead - as the LINE THAT SETS IT, ‘SC.visualizationSettings.general.textSize = 16.0’, with a way to copy it, so that a session in the dialog can be pasted into a script. That is the same thing RG12.3 wants to produce for the whole settings structure. revision2026b step RG6.2.4.

    • notes: The value is edited in the cell. An Entry - or a Combobox for bool and for every enum - is placed over the value cell of the selected row, commits on Return or when the focus leaves, and is taken away on Escape; the bool double click still toggles. The two widgets that used to sit at the bottom of the window and swap by z-order are gone, and with them four handlers. The bottom row is the LINE THAT SETS THE SELECTED ITEM, in a read-only field with a copy button beside it: ‘SC.visualizationSettings.general.textSize = 16.0’. The value is written as a Python literal - a String and a FileName are quoted, an enum is prefixed with exu. - and the prefix follows the structure being edited, so the same dialog on simulationSettings writes ‘simulationSettings….’. Under it stands the type, the size where it is not scalar, and the description. The validation is the one of #2597: CheckType with the combo lists, then ConvertString2Value for the range, and the error box names the path and the expected type. ItemPath() builds the dotted path once for both the code line and the error message, where the loop that built it stood inside the click handler. revision2026b step RG6.2.4.

    • date resolved: 2026-09-23 11:44, date raised: 2026-09-23

  • 1.12.15 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG the dialog font size cannot be changed off macOS (#2602)

    • description: python/exudyn/misc/GUI.py does ‘if not IsApple(): fontFactor = 1’ - off macOS the font factor is forced to 1 and only the row height follows the display scaling, so a maintainer on Linux cannot make the settings dialog readable. The setting that exists is called dialogs.fontScalingMacOS and is applied on macOS alone, with default 1.35. Wanted (maintainer, 2026-09-23): one dialogs.fontScaling for every platform, default 0 meaning ‘as today on this platform’, any value above 0 setting the font factor everywhere - so nothing changes for anybody who does not touch it, and Linux gets the knob. fontScalingMacOS becomes deprecated and forwards to the new name through the mechanism the visualizationSettings already have (SFDeprecated plus Deprecated(since, expires) in definitions/structureDefsVisualizationSettings.py, which 93 members carry), so old scripts keep working and are told the new name. revision2026b step RG6.2.3.1.

    • notes: dialogs.fontScaling replaces dialogs.fontScalingMacOS and works on every platform. It defaults to 0, and 0 means what each platform did before the setting existed - a fixed factor on MacOS, the system display scaling on Windows and Linux - so nothing changes for anybody who does not touch it. A value above 0 sets the font factor AND the row height on every platform, which is what makes the dialog readable on a Linux desktop, where ‘if not IsApple(): fontFactor = 1’ made it unchangeable. fontScalingMacOS is deprecated through the mechanism the visualizationSettings already have (SFDeprecated plus Deprecated(‘1.12.15’, 2032)); the generated C++ forwards it to the new name and raises a DeprecationWarning, verified through a SystemContainer. The scaling logic itself lived TWICE in GUI.py - once in EditDictionaryWithTypeInfo, once in EditDictionary - and is one function now, DialogScaling(root), which is 30 lines less to keep in step and part of what RG6.2.7 would have had to clean up. The reference of parameterConversionTest changed in one line, as intended: the dictionary of VisualizationSettings.dialogs lists fontScaling where it listed fontScalingMacOS, because a deprecated member is not part of GetDictionary. The stubtest baseline gained exudyn.VSettingsDialogs.fontScalingMacOS, which is where every one of the 93 deprecated members is listed, and lost the stale exudyn.misc.resultsMonitor entry. revision2026b step RG6.2.3.1.

    • date resolved: 2026-09-23 11:20, date raised: 2026-09-23

  • 1.12.14 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG the settings dialog does not show the type, the columns are unusable and the description hides behind a key (#2601)

    • description: Maintainer’s complaints of 2026-09-22 on the visualization settings dialog, the visible half of revision2026b step RG6.2.3. (1) tree.column(…) is NEVER called in TkinterEditDictionaryWithTypeInfo, so every column keeps tkinter’s 200 px default: the name is cut, the description is unreadable and nothing can be dragged to a useful width. (2) The TYPE of an item is read into self.typeStorage and never shown, although it is what tells a user whether to type 3, 3.0, True or [1,2,3] - and the error message that rejects a wrong value does not name it either. (3) The description is behind the key ‘h’ and appears in a modal message box; the column heading literally reads ‘Description (press H to show)’. It should appear on hover, as a tooltip, like any other table. python/exudyn/misc/GUI.py.

    • notes: The settings tree has four columns now - Name, Value, Type, Description - and each of them has a width: tree.column() was never called before, so every column kept tkinter’s 200 px default, the name was cut and the description was unreadable. Only the description stretches with the window; the others keep what they are given, scaled with the display scaling. The TYPE is the new column: it was read into typeStorage and never shown, although it is what tells a user whether to type 3, 3.0, True or [1,2,3] - and the error box now names it too (‘general.textSize expects PFloat: …’) instead of only saying what is wrong. The description appears on HOVER, as a tooltip beside the pointer, with the name and the type above it: it was behind the key ‘h’ and a modal message box, and the column heading said so (‘Description (press H to show)’). The key still works. Tooltip is a small class in the same module - tkinter has none - and it builds its window the first time it is needed, so a dialog nobody hovers never creates one. revision2026b step RG6.2.3.

    • date resolved: 2026-09-23 10:36, date raised: 2026-09-23

  • 1.12.13 BUG raised by: Claude-JG resolved by: Claude-JG the settings dialog rejects values the settings themselves hold (#2597)

    • description: Found by the round trip test of revision2026b step RG6.2.2 (#2596), which puts all 622 current settings values through the dialog’s own conversion and checking. Five of them do not survive, and each one is a defect of CheckType in exudyn.misc.GUI. (1) EVERY ENUM VALUE is rejected: CheckType has no branch for an enum type, so ‘LinearSolverType.EXUdense’ falls through to the exec() fallback, raises NameError and comes back as ‘invalid array or matrix: check brackets and types’. It does not show today only because an enum is edited through the combo box, which calls ConvertString2Value directly and never asks CheckType - so the entry field and the combo box disagree about what is valid (affects linearSolverType, dynamicSolverType, contour.outputVariable, interactive.highlightItemType). (2) A FILE NAME CANNOT BE AN ABSOLUTE WINDOWS PATH: ‘:’ is not in validFileNameChar, so ‘C:/anything’ is refused - including the shipped default of interactive.openVR.actionManifestFileName, which is ‘C:/openVRactionsManifest.json’. (3) A value that passes CheckType but fails ConvertString2Value - ‘-3’ for a UInt, for instance, which CheckType does not range check - is dropped by GetDictionary with a print() to the console, so the user sees the dialog accept an edit that never reaches the settings. Also worth fixing in the same pass: CheckType parses with exec() while ConvertString2Value uses ast.literal_eval for the same job.

    • notes: All three are fixed and the round trip list of test_guiValues.py is empty. (1) CheckType takes the combo lists now and has an ENUM BRANCH: a value of an enum type is accepted when it is one of the listed values and rejected with a message that names them all, instead of falling into the exec() fallback and coming back as ‘invalid array or matrix’. The entry field and the combo box now agree about what is valid. (2) ‘:’ is a valid file name character, so C:/models/gear.stl can be typed - the dialog refused even its own default, C:/openVRactionsManifest.json. (3) A value whose SHAPE is right but whose RANGE is wrong no longer disappears: OnEditEntryItem asks ConvertString2Value after CheckType and shows its message (‘UInt must be >= 0’) in the error box, where before the dialog accepted the edit, GetDictionary printed ‘illegal value’ to a console nobody is looking at, and the setting silently kept its old value. And with it, GetComboBoxListsDict builds its lists from EVERY enum the module exposes - a pybind11 enum is recognised by its __members__ - instead of naming OutputVariableType, LinearSolverType and ItemType by hand: 14 enum types instead of 3, which is what closes the last round trip gap (timeIntegration.explicitIntegration.dynamicSolverType, a DynamicSolverType), and an enum added to exudyn arrives in the dialog by itself. revision2026b step RG6.2.3.

    • date resolved: 2026-09-23 09:34, date raised: 2026-09-23

  • 1.12.12 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG the issue table of ‘exudev issue serve’ has unlabelled columns and no priority (#2600)

    • description: Maintainer, 2026-09-23, on the local issue viewer of revision2026 step R8.5.1. (1) The table has no header at all: issueServer.py renders <table><tbody id=’list’> and fills it with rows of number, status, type, effort and title, so a reader has to guess what the second, third and fourth tag mean. It needs a header row, and the effort values need their meaning within reach - the vocabulary is LOW ‘within 2 hours’, MEDIUM ‘within 16 hours’, HIGH ‘within 40 hours’, HUGE ‘above 40 hours’. (2) PRIORITY IS MISSING from the table although the API already sends it and the filter bar already filters on it: /api/issues returns priority in every row (issueServer.py line 68) and the row renderer simply does not use it. (3) Effort and priority share their spelling - LOW and HIGH are values of both - so two bare tags in one row cannot be told apart. The maintainer’s rule: the effort tag carries the word, ‘LOW EFF’, ‘MEDIUM EFF’, ‘HIGH EFF’, ‘HUGE EFF’, and the priority tag stays plain, ‘LOW’, ‘NORMAL’, ‘HIGH’. revision2026b step RG10.2.

    • notes: The issue table has a header now, and the priority is in it. tools/issueTracker/issueServer.py: a sticky <thead> with the six columns - number, status, type, effort, priority, title - whose tooltips carry what the values mean, built from the tracker’s own vocabularies through /api/meta, so that ‘LOW: within 2 hours’ is one hover away and this page does not know the list itself. The priority column is new: the API already sent it in every row and the filter bar already filtered on it, only the row renderer left it out. And because effort and priority share their spelling - LOW and HIGH are values of both - the effort tag now reads ‘LOW EFF’, ‘MEDIUM EFF’, ‘HIGH EFF’, ‘HUGE EFF’ while the priority tag stays plain; each tag also carries its meaning as a tooltip. Two tests: one that the page has named columns, an effort tag that says EFF and a priority in the row; and one that the page script PARSES, through quickjs (which arrives with mermaidx, and is skipped when it is absent) - defining a function parses its body without running it, which is the check that #2574 needed and which the browser tests cannot give while the Edge of this machine prints no DOM. revision2026b step RG10.2.

    • date resolved: 2026-09-23 09:24, date raised: 2026-09-23

  • 1.12.11 DOCU raised by: Claude-JG resolved by: Claude-JG three corrections to the landing pages and the developer chapters (#2598)

    • description: Maintainer, 2026-09-23. (1) The landing pages say nothing about how Exudyn is developed: since version 1.11.0 it is heavily developed with Anthropic’s Claude Code - code, workflows, documentation, tests and examples - and that belongs at the very beginning of README.rst, which is the GitHub landing page and the first page of the HTML documentation, and of pdfIndex.md, which is the front page of the PDF. (2) pdfIndex.md counts the examples and the test models and the pages they would take. A number that is not generated is wrong the next day: published text must say it generically. (3) In the PDF the seven developer documents are chapters BESIDE ‘Exudyn developer documentation’ instead of under it, because index.md and pdfIndex.md list them as siblings; docs/dev/README.md should carry them, which nests them in the HTML sidebar as well. revision2026b step RG3.9.

    • notes: (1) ‘Since version 1.11.0, Exudyn is heavily developed with Anthropic’s Claude Code: code, workflows, documentation, tests and examples’ stands directly under the subtitle of README.rst - which is the GitHub landing page, the PyPI page and the first page of the html documentation at once - and under the subtitle of pdfIndex.md, the front page of the PDF. (2) pdfIndex.md no longer counts: ‘172 examples and 117 test models’ and ‘500 pages of Python’ became ‘the examples and the test models’ and ‘a large body of Python’. A number that is not generated is wrong as soon as somebody adds an example; the measurements stay in the log, the plan and the issue, each with the date it was taken. (3) docs/dev/README.md carries a hidden toctree of the seven developer documents, placed before its first section so that they attach to the document and not to a paragraph, and index.md and pdfIndex.md list only docs/dev/README. In the PDF the seven are sections under one chapter instead of chapters beside it, and the html sidebar nests the same way. The visible table of documents on that page is unchanged: it is what a human reads, the toctree is what Sphinx reads. revision2026b step RG3.9.

    • date resolved: 2026-09-23 08:45, date raised: 2026-09-23

  • 1.12.10 TESTING raised by: Claude-JG resolved by: Claude-JG nothing tests the value layer of the settings dialog (#2596)

    • description: ConvertString2Value, ConvertValue2String, CheckType and GetComboBoxListsDict in exudyn.misc.GUI decide what a typed value becomes and what reaches the settings structure, and no test calls any of them: allExudynModulesTest.py imports the module because it imports every module of the package, and that is all the coverage there is. They need no window, unlike everything above them, so pytest can take them. The strongest available test is not invented data but the real settings: 622 values between simulationSettings and visualizationSettings, each of which must survive the round trip the dialog puts it through - ConvertValue2String on the way in, CheckType and ConvertString2Value on the way out. revision2026b step RG6.2.2, from the review of #2591.

    • notes: python/testing/test_guiValues.py: 41 tests for the four functions that decide what a typed value becomes - ConvertString2Value, ConvertValue2String, CheckType and GetComboBoxListsDict - which had none, and which are the only part of the dialog that can be tested without a window. The test that matters walks the REAL settings: 622 values between simulationSettings and visualizationSettings, each put through the round trip the dialog performs on it. Five of them do not survive, and each is a defect, raised as #2597 for RG6.2.3: CheckType has no branch for an enum type (so it rejects every enum value, hidden today because the combo box bypasses it), ‘:’ is not one of its valid file name characters (so no absolute Windows path can be typed, including the shipped default C:/openVRactionsManifest.json), and a value that passes CheckType but fails ConvertString2Value is dropped with a print() to the console. The five are a list in the test file that is meant to shrink: taking one out while it still fails, or leaving one in after it works, fails the test - checked by removing an entry and watching it go red. A sixth gap, the enum types without a combo list, is an xfail that turns green by itself when RG6.2.3 builds the lists from the type name. revision2026b step RG6.2.2.

    • date resolved: 2026-09-23 07:10, date raised: 2026-09-23

  • 1.12.9 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG 220 of the 775 lines of rendererPythonInterface.cpp are Python in raw strings (#2595)

    • description: Four of the five renderer dialogs are written IN the C++ file that launches them, as R”PY(…)PY” literals: the help dialog (69 lines), the command window (10+93 lines), the quit question (29 lines) and the right-mouse dialog (built by C++ string concatenation). Only the visualization settings dialog is a call into exudyn.misc.GUI. In a raw string literal there is no syntax check, no ruff, no stub check and no import test: one of the blocks carries a leftover ‘\n”;’ inside a Python comment, which is what code looks like when nothing reads it. The window setup is assembled by C++ string concatenation from visualizationSettings.dialogs (-topmost, -alpha), although the same settings are readable from Python, which is how the settings dialog already does it. Move the four into exudyn.misc.GUI as functions and leave one call each in the C++. No behaviour change intended. revision2026b step RG6.2.1, from the review of #2591.

    • notes: The four dialogs the renderer opens are functions of exudyn.misc.GUI now, and rendererPythonInterface.cpp calls them: ShowHelpDialog, ShowPythonCommandDialog, ShowRightMouseSelectionDialog and AskQuitDialog, beside the ShowVisualizationSettingsDialog that the settings dialog already had. The file goes from 775 to 528 lines and its six raw Python string literals become five calls of five lines each; the window setup that the C++ assembled by string concatenation from visualizationSettings.dialogs is ApplyDialogWindowSettings on the Python side, where the same settings are read. No behaviour is changed: the same settings decide topmost and transparency, the quit question still answers through exudyn.sys[‘quitResponse’] as 2 or 3, and each dialog prints what it printed when tkinter is missing. What changes is that 220 lines of Python are Python: ruff reads them (the 2 new fenced call sites and the 300 moved lines pass without a baseline entry), the utility documentation emitter documents them, and the import test imports them. The help text and the command window examples are module constants, so the next step can generate the first from one source (RG6.2.6). revision2026b step RG6.2.1.

    • date resolved: 2026-09-22 22:27, date raised: 2026-09-22

  • 1.12.8 DOCU raised by: Claude-JG resolved by: Claude-JG display math opened at the end of a text line swallows the text (#2593)

    • description: In three documents a display math block starts at the end of a line of prose - ‘- $g = L - r_i + r_j$: $$’ - and closes after a blank line. MyST reads the sentence as the formula and the formula as prose: on the published page docs/manual/theoryContact.html the bullet text is typeset as a display formula and the formula that should follow it is shown as a code block of raw LaTeX. 27 such blocks in docs/manual/theoryContact.md and 18 in two generated item pages (ObjectContactFrictionCircleCable2D, ObjectConnectorCoordinateSpringDamperExt), where they come from the list conversion in tools/generators/latexToMarkdown.py: ConvertLists joins an item into one line, and the display math placeholder of ProtectMath is joined with it. A blank line inside a block has the same effect, and \nonumber left over from the eqnarray days is a hard LaTeX error. Found while building the PDF of revision2026b step RG3.3 (#2586), which cannot compile any of it.

    • notes: 45 display math blocks in three documents opened at the end of a line of prose, so MyST typeset the sentence as the formula and showed the formula as a code block of raw LaTeX - wrong on the published HTML, not only in the PDF. Two causes, two fixes. In tools/generators/latexToMarkdown.py the display blocks are protected by ProtectMath before ConvertLists runs, and ConvertLists joins an item into one line: display math now gets a placeholder of its own kind that stays on its own line. Two smaller things with it: the body was stripped of newlines but not of indentation, leaving a line of blanks before the closing dollar-dollar - and a blank line ends a block in MyST; and \nonumber, left from the eqnarray days, is ignored by MathJax and is a hard LaTeX error inside aligned, so it is dropped (30 in definitions/, 42 removed from four chapters). docs/manual/theoryContact.md was written that way by the conversion of revision2026 step R7.1.5 and is hand-written since, so all 87 of its display blocks were normalised in place, keeping the two equation labels on their closing line. revision2026b step RG3.7.

    • date resolved: 2026-09-22 21:20, date raised: 2026-09-22

  • 1.12.7 DOCU raised by: Claude-JG resolved by: Claude-JG a generated settings page contains a table with a header and no rows (#2592)

    • description: structureDocsEmitter.py writes the table header of a settings structure unconditionally, before the loop that writes the rows, and every parameter of a structure can be skipped by that loop (deprecated, or no pybind flag). VSettingsWindowDeprecated is such a structure today: all of its members are deprecated, so docs/generated/structures/VisualizationSettings.md carries five column headings with nothing under them, and the published page shows an empty box. It is also a hard blocker for a LaTeX build: sphinx.builders.latex.transforms.depart_table does next(node.findall(nodes.tbody)) and dies with StopIteration on a table with no body, which is what stops the PDF of revision2026b step RG3.3 (#2586). Fix in the emitter: emit the header only when at least one row follows, and a sentence instead when none does.

    • notes: structureDocsEmitter.py wrote the five column headings of a settings table before the loop that writes the rows, and the loop skips every parameter that is deprecated or has no pybind interface - VSettingsWindowDeprecated has nothing else left. The published page showed an empty box, and the LaTeX writer of sphinx aborted the whole build on it (next(node.findall(nodes.tbody)) raises StopIteration when a table has no body). The emitter now remembers where the header started and takes it back when no row followed, writing a sentence instead; the zero-row case is handled generically, not that one structure. revision2026b step RG3.6.

    • date resolved: 2026-09-22 21:20, date raised: 2026-09-22

  • 1.12.6 CHECK MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG there is no PDF of the documentation, and no decision on whether there should be (#2586)

    • description: The PDF ended with the LaTeX sources: decision D8 (2026-09-19) says theDoc.pdf does not survive the revision, because keeping it meant keeping a LaTeX toolchain and a second rendering of every page. The maintainer asked on 2026-09-22 whether a PDF from the Markdown sources is possible. It is: sphinx-build -b latex renders MyST and needs a LaTeX installation at build time only, and the math macros that conf.py declares to MathJax can generate the LaTeX preamble from the same list that tools/checkMathMacros.py checks. What is needed is a decision (is the PDF wanted at all, and for which audience) and, if yes, a release-only build that is not part of the documentation gate.

    • notes: The documentation has a PDF again, built from the Markdown: exudev docs –pdf, 1158 pages, 10.1 MB, zero LaTeX errors (the old theDoc.pdf was 1090 pages). Decision D17 records it and what it does not undo: D8 ended the LaTeX SOURCES and they stay ended; what comes back is a rendering. It holds everything except the 517 pages of example and test model listings, and it deliberately includes the complete issue history, which is what makes the document worth searching and worth feeding to an AI tool. The two builds are one build: sphinx -b latex with ‘-t pdf’ sets a tag that conf.py branches on once, making pdfIndex.md the root and excluding index.md, README.rst (ten badges fetched as SVG, three animated GIFs) and the listing directories. The LaTeX math preamble is GENERATED from the same mathjax3_config dict that declares the macros to the browser - 162 newcommands written by conf.py itself, no second list - with five names LaTeX already has decided by hand and everything else emitted as \newcommand, which fails loudly on a future collision. xelatex rather than pdflatex, for the box-drawing characters and arrows of the directory trees: zero missing glyphs. The mermaid diagrams are rendered by mermaidx, a pure-Python renderer in a new dev-only ‘pdf’ dependency group. A post-transform turns the 468 raw <br> of the settings tables into \newline for the latex builder only. It is in no gate: exudev docs alone is unchanged, –complete does not build it, Read the Docs cannot; a release builds it into dist/ beside the wheels and the checklist names it as an asset. revision2026b step RG3.3.

    • date resolved: 2026-09-22 21:20, date raised: 2026-09-22

  • 1.12.5 DOCU NORMAL MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG citations are silently dropped from the HTML documentation (#2550)

    • description: latexConverter.py removes every cite command without replacement, so the rendered pages contain sentences such as “similar but much more advanced and modular as earlier solvers by the main developer .” with the references simply gone - visible today in LHSRHSNamingConventionsInEXUDYN and in the theory chapter. The Markdown conversion of step R7.1.5 writes the citation keys in brackets instead, which is readable but not linked. The documentation needs a references page fed from docs/theDoc/bibliographyDoc.bib, and the keys need to point at it; sphinxcontrib-bibtex would do it as a dev-only dependency.

    • notes: The citations are links now. docs/generated/references.md is written by the new tools/generators/referencesDocsEmitter.py from docs/bibliographyDoc.bib - 100 entries, of which 54 are cited - and gives every entry a target. conf.py then appends one Markdown link definition per key ([Hairer1987]: #ref-hairer1987) to every Markdown document Sphinx reads, so CommonMark resolves the [Key] of the running text as a shortcut reference link. No source text is edited: not the 24 manual chapters, not the 450 generated pages, not the cite commands still standing in definitions/. Because the Markdown parser decides, a key inside a code fence or inline code stays literal text, which a regular expression over the sources could not have guaranteed. The emitter reports any key that is cited but missing from the bibliography; there is none today. Two characters of the .bib that had become U+FFFD in an old encoding conversion were repaired. revision2026b step RG3.5.

    • date resolved: 2026-09-22 19:11, date raised: 2026-09-19

  • 1.12.4 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG internal how-to notes are published to Read the Docs (#2585)

    • description: docs/howTo/ holds notes of two kinds: what a USER needs (building from source, conda environments) and what only a maintainer needs (converting videos with ffmpeg, matplotlib recipes, Visual Studio 2022, build quirks, what MSVC accepts where gcc does not). All of them are in the toctree and are published. The second kind should stay in the repository and be mentioned in one line - “further notes are in the repository” with a link - rather than being part of the manual. The mechanism is exclude_patterns in conf.py, which already excludes docs/revision/ and .github/.

    • notes: Five of the eight docs/howTo notes are maintainer material and leave the published documentation: buildQuirks, gccVsMsvcTraps, visualStudio2022, convertVideosFfmpeg and matplotlibExamples are now in exclude_patterns in conf.py, beside docs/revision/, CLAUDE.md and .github/. buildFromSource, condaEnvironments and sphinxDocs stay pages, because a user or a first contributor needs them. Nothing is deleted: the five stay in the repository, are named in one paragraph of index.md with a link to the directory, and keep their row in the how-to table of docs/dev/README.md - which is now two tables, pages and repository notes. The actual work was the nine relative links that pointed into the five: a link to an excluded document fails the strict build, so the four in buildFromSource.md and the five in the developer index now point to GitHub, as revision2026 step R7.1.2 did for the same files. revision2026b step RG3.2.

    • date resolved: 2026-09-22 10:05, date raised: 2026-09-22

  • 1.12.3 DOCU HIGH MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the user manual has a broken section structure (#2584)

    • description: The conversion of revision2026 step R7.1.5 left the toctree of docs/manual/introduction.md BELOW its last section, so Exudyn Basics, Advanced topics and C++ Code appear in the documentation as sub-pages of “Mapping between local and global coordinate indices”. Wanted (maintainer, 2026-09-22): Installation and Getting Started before Overview on Exudyn; Exudyn Basics and Advanced topics at the same level as Overview on Exudyn; “Mapping between local and global coordinate indices” as the last sub-section of “Items: Nodes, Objects, Loads, Markers, Sensors”; and C++ Code reduced to a short pointer in Advanced topics, with its content moved into the developer documentation under a name that says what it is.

    • notes: The toctree left docs/manual/introduction.md, so Installation and Getting Started comes first and Exudyn Basics and Advanced topics stand at the level of Overview on Exudyn instead of below its last section. ‘Mapping between local and global coordinate indices’ is a sub-section of ‘Items: Nodes, Objects, Loads, Markers, Sensors’. The C++ chapter is split and gone: its four principles moved into docs/dev/ARCHITECTURE.md as ‘Why it looks like this’, its two worked cases of adding an item into docs/dev/CODING_STYLE.md section 9 - which said TBD and now says how, with the file names of the current layout - and its style, notation and no-abbreviation sections were dropped because CODING_STYLE already carries them better. The manual keeps a short ‘The C++ core’ section in Advanced topics that points at both.

    • date resolved: 2026-09-22 08:29, date raised: 2026-09-22

  • 1.12.2 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG the revisions chapter does not say where the details are (#2587)

    • description: docs/manual/revisions.md is deliberately short, but it ends there: a reader who wants to know why something changed has no pointer. It should refer to the developer documentation and say that the revision is recorded in full in a plan and a log - and there are two of them now, revision2026 (finished, completed as 1.12) and revision2026b (continuing), each with its own plan and log.

    • notes: The revisions chapter now ends by saying where the full record is: the revision is written down step by step in a plan and a log, there are two of them - revision2026, finished and what 1.12 is, and revision2026b which carries what it did not finish - and both are linked from the developer documentation together with the standing information document. The chapter itself stays short; the published page does not link the plan files directly, because docs/revision/ is excluded from the documentation build.

    • date resolved: 2026-09-22 01:34, date raised: 2026-09-22

  • 1.12.1 TESTING HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG checkExtras passed locally and failed in CI because of an untracked file (#2508)

    • description: tools/checkExtras.py built its set of “local module names” with os.listdir/os.walk over python/; so ANY file present on the development machine made an import look local. python/pytest.py - the gitignored scratch copy of pytestTemplate.py - did exactly that: “import pytest” in test_testModels.py resolved to that file locally and the check reported OK; while the GitLab job of 2026-09-18; which has no such file; reported “UNCOVERED IMPORTS: pytest … needed by [tests]” and failed. A gate that is green locally and red in CI is worse than no gate; and the same trap applies to any untracked helper anyone drops into python/ or TestModels/. Fixed in revision2026 step R5.18.3 by listing TRACKED files only (git ls-files); and by giving pytest a real exemption entry with its reason - it is a dev tool declared in [dependency-groups]; not in any extra.

    • notes: Verified 2026-09-22: tools/checkExtras.py builds its set of local module names from TRACKED files only - LocalModuleNames() calls TrackedFiles() and its docstring names this failure mode - so a file that exists on the development machine but is not in git can no longer make an import look local. The difference between a local run and CI is gone.

    • date resolved: 2026-09-22 01:30, date raised: 2026-09-18

  • 1.12.0 FIX LOW LOW EFF raised by: Claude-JG resolved by: Claude-JG pydoclint reports two violations in exudyn/__init__.py RequireVersion (#2455)

    • description: found 2026-09-16 during revision2026 step R5.13; pre-existing and unrelated to that step: DOC111 (type hints in the docstring arg list while –arg-type-hints-in-docstring is False) and DOC202 (return section without a return statement) in RequireVersion; belongs to revision2026 step R5.5 (ruff and type checking)

    • notes: Verified 2026-09-22 on 1.12.0.dev1: pydoclint with the project configuration reports ‘No violations’ for python/exudyn/__init__.py, and DOC111 does not occur anywhere in the package any more. The two findings were removed by the docstring work of revision2026 steps R5.13 and R4.8; nothing was needed here beyond the check.

    • date resolved: 2026-09-22 01:30, date raised: 2026-09-16

Version 1.11

  • 1.11.240 CHANGE MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the revision plan is finished, and what is open has nowhere to live (#2581)

    • description: The plan of the 2026 revision reached its end: 195 of its 216 steps are done and the twenty that are not are no longer a phase of that revision - a plugin ABI, a rendering revision, a contact-friction difference between platforms and a user-script checker are themes that run in parallel for years, not stages of one march. Keeping them in a finished plan also means the documentation would have to be revised again for each of them. Revision2026b: a second plan, organised by GROUP rather than phase and numbered RG<group>.<step>, because R3.4 existing in two documents with different meanings is unreadable. Eleven groups - release and publication, testing and verification, docs, implementation problems and bugs, performance, graphics and rendering, Python user items, compiled C++ user items, structural core improvements, tooling and process, misc - with the twenty open steps moved into them, their references rewritten, and a mapping table on both sides. The info document stays shared: there is one set of facts about this repository, not two.

    • notes: docs/revision/exudynRevisionPlan2026b.md: eleven groups, the twenty open steps moved into them with their full text, their cross-references rewritten (a reference to a moved step becomes its RG number, one to a finished step becomes ‘revision2026 step R…’), and each step saying where it came from. docs/revision/exudynRevisionLog2026b.md is opened empty; the first log is closed. The finished plan says so in its header and carries the mapping table old number to new; its R9 section left entirely, R10 and R11 keep the steps that are done. The info document is shared by both plans and records the decisions D15 (the revision completes as 1.12; 2.0 is reserved for the work of RG8 and RG9) and D16 (1.12 is internal, 1.13 is the first public release). CLAUDE.md and docs/dev/README.md list both plans, and the numbering rule now says that a plan step is always cited with its prefix.

    • date resolved: 2026-09-22 00:57, date raised: 2026-09-22

  • 1.11.239 DOCU HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the documentation announces the revision as 2.0, and it is 1.12 (#2580)

    • description: The revision of 2026 was planned as v1.11.0 to v2.0 and the documentation says so in five published pages. The maintainer decided on 2026-09-22 that this is wrong for users: the interface changes it brought - star imports exporting only __all__, eleven removed vector helpers, a few renames - are the kind every minor release carried, and they are easy to find. A major number promises more: compiled user items, the fully generic object, exudyn.Parameter, autodiff, the kinematics and inverse-dynamics solvers, all of which are still open. So the revision completes as 1.12 and 2.0 is reserved for that work. The second half of the decision: 1.12 is INTERNAL - no PyPI wheels, no GitHub release, no promotion - because the colleagues’ integration round, the documentation and the macOS wheels still need weeks; the first public release is 1.13, and only then does master move. This issue is the wording pass: the published pages, the landing page, the branch prose, the pre-push hook message, and the rule that a feature is announced by the release that ships it while exact micro versions stay in the changelog and in developer notes.

    • notes: The published documentation names 1.12, never 2.0: the revisions chapter (with a note saying that the individual issues carry 1.11.x numbers because the micro version does not restart, that 1.12.0 marks completion, and that 1.13 is the first release that carries it), the landing page, the FAQ and the exception section. docs/dev/WORKFLOW.md gains the rule - a feature is announced by the release that ships it (since 1.12) while exact micro versions (1.11.238) belong in the changelog and in notes between developers - and states that 1.12 is internal, with 1.13 the first public release. The branch keeps its name v2-dev, which is historical, and the pre-push hook now says that nothing reaches GitHub before 1.13.

    • date resolved: 2026-09-22 00:43, date raised: 2026-09-22

  • 1.11.238 DOCU HIGH MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the revision is not in the documentation (#2579)

    • description: Three months of changes - the repository layout, the build, the tests, the tools, the API - are recorded in the revision plan and log, which are working records and are not published. A reader of the documentation still found paths from before the main/ level was removed, an installation chapter that recommends python setup.py install (which current setuptools does not have), a sentence pointing at a developer-only trackerlog.html for open issues that have been published for weeks, a paragraph explaining how to bump a version by editing two constants that no longer exist, and eight author names written as Zw{"o}lfer. Revision2026 step R7.2 in five parts: close the record, write down what the revision implies for the documentation (docs/revision/documentationImpact2026.md), work that list off in the pages and in the generators, add a revisions chapter for users at the end of the manual, and two lines on the landing page.

    • notes: The revision is in the documentation. R7.2.1 closed the record: 195 of 216 steps are finished and every one of them points at its log entry (11 links added, R8.8 written up, three rows whose state had moved on corrected). R7.2.2 wrote docs/revision/documentationImpact2026.md from three scans over the tree - what a reader runs into, one row per item with file and line. R7.2.3 worked it off: paths from before R3.1 in four documents, the minor-bump paragraph that R8.4 had replaced, four setup.py commands in the installation chapter, the pointer to trackerlog.html, eight LaTeX umlauts and an RST figure directive - and two of the items were generator bugs, so latexToMarkdown.py learned .. image:: and the item definitions carry the character. R7.2.4 added docs/manual/revisions.md, written for somebody upgrading and structured by release so that the next one is a section on top. R7.2.5 put two lines on the landing page. One inventory entry was wrong and the strict Sphinx build caught it: the exception types of R6.3 are documented for users already.

    • date resolved: 2026-09-21 21:22, date raised: 2026-09-21

  • 1.11.237 EXTENSION LOW EFF raised by: Claude-JG resolved by: Claude-JG the release path has no guards, no notes and no tag (#2578)

    • description: exudev release ran build –complete over every Python version and then printed a checklist, which leaves the bracket around a release to memory: whether the issue store and the published pages are consistent, whether the working tree is clean - a wheel built from a dirty tree belongs to no commit and can never be rebuilt - whether the release has a name, and whether this version was already released once. Revision2026 step R8.2 makes that one preflight step that reports everything that is wrong rather than the first thing, writes dist/RELEASE_NOTES.md by cutting the section of CHANGELOG.md that belongs to this release, and creates the annotated tag with –tag. It never bumps the version, which is exudev issue bump and a decision about the product, and it never pushes.

    • notes: exudev release is now the whole path. Before the build, one readiness step reports everything that is wrong at once: the issue store and both published pages consistent, the working tree clean (or –allow-dirty), the release named in releases.json, and the tag v<version> still free. After it, dist/RELEASE_NOTES.md is cut from the section of CHANGELOG.md that belongs to this release - the body of a GitHub release, written nowhere a second time - and –tag creates the annotated tag at HEAD with those notes as its message, without ever pushing. Bumping stays out of the release path: it is a decision about the product and exudev issue bump is one command for it.

    • date resolved: 2026-09-21 18:12, date raised: 2026-09-21

  • 1.11.236 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG no issue templates, and CONTRIBUTING does not state the workflow (#2577)

    • description: GitHub offered a blank text box for a bug report, so a report arrived without the version, without the platform and usually without a script - three rounds of questions before anything could be looked at. And CONTRIBUTING.md said that contributing is only possible by contacting the authors, without saying what a good report contains, what happens to a pull request that arrives unannounced, or which rules a change has to follow if it is agreed. Revision2026 step R8.1: two issue forms that ask for the output of python -m exudyn info and a script that shows the problem, a config with the links to Discussions and the documentation, a pull request template with the four gates as a checklist, and a CONTRIBUTING that states the policy as it is - reports and ideas welcome and read, code agreed before it is written, and why.

    • notes: Two GitHub issue forms - a bug report that requires the output of python -m exudyn info and a script that shows the problem, and a feature request that asks what the person is trying to model rather than which function they want - plus a config pointing questions at Discussions and a pull request template whose checklist is the four gates. CONTRIBUTING.md now states the policy and the reason for it: reports and ideas are welcome and read, code is agreed before it is written, because review capacity is the scarce resource, the C++/Python boundary is narrow and deliberate, and large parts of the tree are generated. .github/* is excluded from the Sphinx build: the templates are read by GitHub and are not documentation.

    • date resolved: 2026-09-21 18:12, date raised: 2026-09-21

  • 1.11.235 DOCU LOW EFF raised by: Claude-JG resolved by: Claude-JG the repository has no CHANGELOG (#2576)

    • description: A user of a released package looks for CHANGELOG.md in the repository root, and Exudyn had none: the only list of what changed was the issue tracker chapter of the documentation, which is the tracker itself - every resolved issue with its description, dates and author, plus the open issues and the known bugs, 119,000 words. Revision2026 step R7.4 renders CHANGELOG.md from the issue store, which step R8.4 made possible by storing in every closed issue the version it produced: the file only has to group and print. The current release is printed with the release note of each issue and the earlier ones as one line per issue, so that the file stays a changelog instead of a second copy of the tracker. tools/checkIssues.py compares both published pages with what the issues render to, which catches a store edited by hand.

    • notes: CHANGELOG.md in the repository root is rendered from the issue store by the tracker, on every write that closes an issue: a table of the releases, then the current release with the release note of each resolved issue and the earlier releases as one line per issue. An issue closed without being resolved, and an IDEA, appear nowhere. tools/checkIssues.py renders both published pages - trackerlog.md and CHANGELOG.md - and compares them with the files, so a store edited by hand no longer leaves the documentation describing issues that do not exist.

    • date resolved: 2026-09-21 17:24, date raised: 2026-09-21

  • 1.11.234 FIX HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG opening an issue in the web page threw appendChild(null) (#2575)

    • description: Clicking an issue in exudev issue serve showed a red banner - TypeError: Failed to execute appendChild on Node: parameter 1 is not of type Node - and half a detail pane. TextBlock() returns null for a field that is not filled, and almost every issue has empty workingRemarks, so the pane threw on nearly every issue. Fixed with one Append(parent, node) helper that ignores a missing block, used by all 15 append sites; the fragment of the URL now also carries an issue (#author=JG&issue=2548), which makes a link to one issue possible and lets the headless browser test render the detail pane without a click. That test fails when the unguarded append is put back.

    • notes: One Append(parent, node) helper ignores a block that is not there, so a field left empty no longer throws in the detail pane; all 15 append sites use it. The URL fragment now carries an issue as well as an author (#author=JG&issue=2548): a link opens that issue, and the headless browser test renders the detail pane for an open and a closed issue and asserts that the page reports no problem. docs/dev/WORKFLOW.md gains a table of exactly which files a tracker write touches and which of them are in git.

    • date resolved: 2026-09-21 16:39, date raised: 2026-09-21

  • 1.11.233 FIX HIGH LOW EFF raised by: Claude-JG resolved by: Claude-JG the issue page did not parse: Python ate a backslash in the JavaScript (#2574)

    • description: exudev issue serve showed its frame and no issues at all, with no error message - the second time this page failed in silence. The cause this time: pageHtml is a Python triple-quoted string, and revision2026 step R8.3.5 put a newline escape into a confirm() text. Python turned it into a REAL newline inside a JavaScript string literal, which is a syntax error, which kills the whole script - including the error handlers added in #2571 to report exactly this kind of failure. The page text is a raw string now, so a backslash in it belongs to the browser; and pytest renders the page in headless Edge or Chrome and asserts that issues appear and that the console reports nothing, which is the only check that sees a page the way a maintainer does.

    • notes: The page text is a raw Python string, so that a backslash in it reaches the browser: an escaped newline in a confirm() text had become a real newline inside a JavaScript string literal, which is a syntax error, which stopped the whole script - the error handlers of #2571 included. pytest now renders the page in headless Edge or Chrome and asserts that the version line, the filter options and the issue rows are there and that the console reports nothing; the test is skipped where no browser exists, and it fails on the broken page.

    • date resolved: 2026-09-21 16:14, date raised: 2026-09-21

  • 1.11.232 FIX HIGH MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the version numbering is derived on every run, so history can move (#2573)

    • description: The micro version is a running count of closed issues, and every version number in the release notes was recomputed on each run from a sort by dateResolved. One corrected date, one status changed by hand or one lost file renumbers versions that have already been published, and nothing in the tree would report it - both sides of any comparison came from the same derivation. Revision2026 step R8.4: the releases and their baselines become data (releases.json), every closed issue stores the version its closing produced (resolvedInVersion, D14), tools/checkIssues.py recomputes and compares, and exudev issue bump starts a new release - MINOR and, for the first time, MAJOR: the major number was written as 1 inside GetMajorMinorMicroVersion, so 2.0 could not be expressed at all (maintainer 2026-09-21).

    • notes: The releases are data: tools/issueTracker/releases.json holds each release, the count of closed issues it began at and its name, and exudev issue bump –minor|–major|–to starts a new one - MAJOR included, which the tracker could not express because the major number was the literal 1 in GetMajorMinorMicroVersion. Every closed issue stores the version its closing produced (resolvedInVersion); 2302 issues were backfilled and the computation reproduces all 2066 versions the archived 1.11.0 documentation published, with trackerlog.md regenerating byte-identical. tools/checkIssues.py compares the stored version with the recomputed one, refuses two issues sharing a version or an open issue carrying one, and checks that the baselines rise.

    • date resolved: 2026-09-21 15:23, date raised: 2026-09-21

  • 1.11.231 CHANGE LOW EFF raised by: Claude-JG resolved by: Claude-JG ABANDONED is one reason, not the status: it becomes CLOSED (#2572)

    • description: R8.3.1 proposed CLOSED, R8.7 built ABANDONED, and both have stood in the documents since. They do not mean the same thing: abandoned is one reason among several - obsolete, won’t fix, duplicate of #n, superseded, no longer applies, not reproducible - while the status says only that the issue is closed and was not resolved. The status is CLOSED from revision2026 step R8.3.4 on, the kind is named in its mandatory reason, and AbandonIssue stays as a one-line alias of CloseIssue. The count of closed issues, which is the micro version, must not move: it did not.

    • notes: The status of an issue that was not resolved is CLOSED (D13): obsolete, won’t fix, duplicate, superseded, no longer applies, not reproducible, abandoned - one status, with the kind in its mandatory reason. CloseIssue replaces AbandonIssue, which stays as an alias; exudev issue close is the verb and abandon its alias; issueStore.knownStatuses is checked by CheckStore. The 15 issues carrying the old spelling were rewritten inside their archive files, and the count of closed issues - the micro version - did not move.

    • date resolved: 2026-09-21 15:23, date raised: 2026-09-21

  • 1.11.230 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG the issue page stays empty: one idle browser socket blocks the server (#2571)

    • description: exudev issue serve (revision2026 step R8.5.1) rendered its page and then showed no issues at all, with no error anywhere. The server was a plain http.server.HTTPServer, which is single-threaded: browsers open speculative preconnect sockets that carry no request, serve_forever accepts one and blocks in readline() until the browser closes it, and every fetch of the page queues behind it. The first request - the page itself - had already been answered, so the shell was there and the data never arrived. Fixed by serving on ThreadingHTTPServer with HTTP/1.1 and a socket timeout, with one lock around the request layer so that writes stay serialized; and by making the page report a failure instead of staying blank.

    • notes: exudev issue serve runs on ThreadingHTTPServer with HTTP/1.1, a socket timeout and one lock around the request layer, so that an idle browser connection cannot block every other request while the store still sees one change at a time. The page also reports what goes wrong instead of staying blank: a fetch that throws, an answer that is not JSON and an error in the page itself become a visible message, and an empty result says so. The test opens an idle socket and then asks a question; on the old single-threaded server it times out.

    • date resolved: 2026-09-21 15:23, date raised: 2026-09-21

  • 1.11.229 FIX LOW EFF raised by: Claude-JG resolved by: Claude-JG changing a field of a closed issue must not be silent (#2570)

    • description: Raising, resolving and closing an issue are ordinary work. Changing a field of an issue that is already CLOSED is not: its text stands in the release notes of a released version, and two of its fields decide the version number. ChangeIssue did it silently, and so did exudev issue modify; the web page of R8.5.1 happened to be narrower only because it did not render the editors for a closed issue. ChangeIssue now refuses a closed issue unless force=True (–force on the command line), refuses status, number, dateRaised and dateResolved always because the tracker writes those, and prints the previous text when a text field is REPLACED rather than extended. The page shows the editors for a closed issue as well, but asks with a confirm dialog before it sends force. Maintainer question 2026-09-21; revision2026 step R8.3.5.

    • notes: ChangeIssue refuses a CLOSED issue unless force=True (–force on the command line): such an issue stands in the release notes of a released version. status, number, dateRaised and dateResolved are refused always - the tracker writes them, and status decides the micro version. Replacing a non-empty text field prints the previous text and says that extend and remark append where modify overwrites. The web page of R8.5.1 shows the editors for a closed issue as well and asks with a confirm dialog before it sends force.

    • date resolved: 2026-09-21 14:32, date raised: 2026-09-21

  • 1.11.228 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG a local web page over the issues, for a backlog pass (#2569)

    • description: The tracker can be read and written from the command line since revision2026 step R8.3, which is right for one issue at a time and wrong for a pass over 270: looking, deciding, writing and looking again is what a page does. exudev issue serve starts a local server (stdlib http.server, one HTML page, no new dependency, loopback interface only) that lists, searches and filters the issues and writes through the same tracker functions as the verbs - so it cannot store a value the command line would refuse. Deleting an issue stays a file operation with a commit behind it. Revision2026 step R8.5.1.

    • notes: exudev issue serve: a local web page over the issue store (tools/issueTracker/issueServer.py). stdlib http.server and one self-contained HTML page - no new dependency and nothing fetched from outside the server. It lists, searches and filters the backlog and writes through the same tracker functions as the command line, so it cannot store a value the CLI would refuse; status, number and dateResolved are not editable there. It binds 127.0.0.1 and checks the Host header, because the store is the version of the package. Deleting an issue stays a file operation. 12 tests, against the socket-free request layer.

    • date resolved: 2026-09-21 14:11, date raised: 2026-09-21

  • 1.11.227 DOCU HIGH raised by: Claude-JG resolved by: Claude-JG generated and hand-written documentation share directories and nothing says which is which (#2548)

    • description: Every .rst in the repository is generated - the ~498 files in docs/RST/ and index.rst and README.rst at the root - and docs/theDoc/ mixes 9 hand-written .tex chapters with 8 emitter-written ones plus the LaTeX build products. No banner, no separate directory and no gitattributes entry marks a generated file: in step R7.1.4 a hand edit to index.rst was silently reverted by the next regenerate run. Decide the target layout before the Markdown conversion of R7.1.5 writes files anywhere: one directory is either generated or hand-written, every generated file carries a banner in its first line, and the index is hand-written. See revision2026 step R7.1.8.

    • notes: One directory is either generated or hand-written and says which. docs/generated/ holds everything the emitters and the issue tracker write, each file saying so in its first line, with a hand-written README.md naming what writes each sub-directory and linguist-generated in .gitattributes; docs/manual/ is the hand-written user manual; index.md and README.rst are hand-written. docs/RST/ and docs/theDoc/ are deleted with the converters (R7.1.7), the figures moved to docs/figures/, and rule 1 of CLAUDE.md is one sentence.

    • date resolved: 2026-09-21 13:09, date raised: 2026-09-19

  • 1.11.226 CHANGE HIGH EFF raised by: Claude-JG resolved by: Claude-JG the issues are one JSON file each (#2568)

    • description: trackerlog.txt was one 723 KB file of comma-separated lines in which a text field could not contain a comma (the tracker escaped it to backslash-semicolon), every change rewrote the whole file, and two people editing two issues produced one merge conflict. The 2,568 issues are now one JSON file per open or recently closed issue in tools/issueTracker/issues/ and one file per year for the older ones, with meta.json holding the date of the last change. Decided with the maintainer on 2026-09-21: the files live beside the tool rather than in docs/dev/, and the field names are camelCase. The micro version is the count of closed issues, so each archive file states its own closedCount and tools/checkIssues.py - new in exudev generate –all-checks - compares the count with the files, the version with the count and version.txt with the version. See revision2026 step R8.5.

    • notes: The 2,568 issues are one JSON file each in tools/issueTracker/issues/ - open/, closed/ since the cutoff of 1 January of the previous year, and one file per year for the rest, written directly by the migration so that the old ones never existed as single files. issueStore.py owns the files, issueTracker.py the rules, and tools/checkIssues.py - new in exudev generate –all-checks - guards the count the micro version is derived from. The migration proved itself three ways: every field of every issue compared before and after, the flat file regenerated from the store and compared column by column, and docs/generated/trackerlog.md regenerating word for word and line for line. trackerlog.txt is deleted with the escaping trap it carried.

    • date resolved: 2026-09-21 12:10, date raised: 2026-09-21

  • 1.11.225 EXTENSION MEDIUM EFF raised by: Claude-JG resolved by: Claude-JG the issue tracker gets a command line, in exudev (#2567)

    • description: The tracker was driven by importing the module from its own directory and calling functions - every issue of this revision was raised with a four-line python -c - because trackerlog.txt was opened relative to the current directory and the version files were written as ‘....\version.txt’ with Windows separators. It now derives its two directories from __file__ and works from anywhere, and the command line lives in exudev (maintainer 2026-09-21): exudev issue raise/extend/remark/resolve/abandon/show/list/modify/mode. Every writing verb is a Step with an action, so exudev -n issue resolve prints what it would do and writes nothing. mode –release/–dev rewrites the one versionDev line of fact 26. See revision2026 step R8.3.

    • notes: issueTracker.py derives trackerDirectory and repositoryRoot from __file__ and works from any directory; the ~20 relative paths and the Windows-separator literals are gone. The command line is exudev issue <verb>: raise, extend, remark, resolve, abandon (alias close), show, list with the filters a triage pass needs, modify, and mode –release/–dev for fact 26, which rewrites the one versionDev line and reruns the update. Every writing verb is a Step with an action, so exudev -n issue resolve prints the note and writes nothing. Eight new tests cover the version arithmetic - the only definition of what version.txt says and untested until now - and the CLI. Two items of the step were void when it ran: the NORMAL-vs-med priority mismatch was settled in R8.5.3, and execWithPythonVersion.bat exists only in the untracked tmp/oldScripts/ since exudev replaced the batch files in R5.18.

    • date resolved: 2026-09-21 11:13, date raised: 2026-09-21

  • 1.11.224 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG the tracker can extend an issue, and open notes are triage (#2566)

    • description: Maintainer request 2026-09-21. (1) EXTEND: the tracker can raise and close an issue and ChangeIssue can overwrite one field, but the thing that actually happens - the first analysis turns up more than the issue says - has nowhere to go except a second issue or a rewritten description. ExtendIssue(number, text, author) appends a dated paragraph and touches nothing else; the CLI verb extend comes with the CLI of R8.3, and in the JSON of R8.5 it becomes one entry of an updates list. (2) TRIAGE NOTES: measured 2026-09-21, 0 of the 270 open issues use the notes field while 614 resolved ones do, so notes is the place to record the way to go while an issue is open - duplicate of #xxxx, marked for deprecation, check whether this is still a problem. For that to work ResolveIssue and AbandonIssue must REPLACE those notes rather than prepend them, because the resolution note is published in the release notes. (3) The effort field that makes the 270 open issues sortable is R8.5.2, with the new format. See revision2026 steps R8.3.3 and R8.5.2.

    • notes: ExtendIssue appends a dated paragraph to the description of an open issue and refuses a closed one; RemarkIssue writes the workingRemarks of an open issue. The field question behind the second half was settled in R8.5.3: notes became releaseNotes (written when the issue closes and published) and workingRemarks (what the work knows meanwhile and cleared when it closes), with effort beside them. The CLI verbs extend and remark came with R8.3.

    • date resolved: 2026-09-21 11:13, date raised: 2026-09-21

  • 1.11.223 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG the documentation emitters write LaTeX and RST (#2565)

    • description: itemDocsEmitter, structureDocsEmitter, utilityDocsEmitter, mainSystemExtensionDocsEmitter and the issue tracker write 8 .tex files (~43000 lines) and the .rst pages beside them, through the PyLatexRST helper that builds both formats in one walk over the model. The PDF does not survive 2.0 (decision D8) and the RST pipeline goes in step R7.1.7, so the emitters emit Markdown into docs/generated/ instead - one emitter at a time, each with its old outputs deleted in the same commit. This is where #2545 (the LaTeX escaping of the emitters) and #2550 (the dropped citations) end. See revision2026 step R7.1.6.

    • notes: All five documentation emitters write Markdown into docs/generated/ and their .tex and .rst outputs are deleted: structures (7 pages), pythonUtilities (31), cInterface (10), items (109) and the issue tracker (trackerlog.md). Gone with them: interfaces.tex, pythonUtilitiesDescription.tex, manual_interfaces.tex, MainSystemExt.tex, MainSystemCreateExt.tex, itemDefinition.tex, trackerlog.tex and about 640 generated .rst files. Each conversion was checked by comparing the words of the deleted RST against the new Markdown, which is the only thing that can see content that silently disappears; it found four real losses - the example references and the class tags of the utility pages, and for the items the figures of the onlyRST branches and 126 example links whose Create* keyword the Markdown writer did not know. The differences that remain are the macro expansion the RST did, RST markup, and the “see theDoc.pdf” note that goes with the PDF (decision D8). PyLatexRST grew a Markdown branch beside its LaTeX and RST ones; those go in revision2026 step R7.1.7. See revision2026 step R7.1.6.

    • date resolved: 2026-09-20 23:05, date raised: 2026-09-20

  • 1.11.222 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG the documentation emitters do not escape LaTeX either (#2545)

    • description: After the tracker was fixed, theDoc.pdf builds with 74 non-fatal LaTeX errors. They are the same class one layer down: an issue number in a docstring writes a bare hash, a table writes a bare caret, and underscores survive in itemDefinition.tex and pythonUtilitiesDescription.tex where the emitter path differs from the one fixed in step R7.1.3. Passages are garbled; the build completes. The honest fix is ONE escaping function applied at every LaTeX text boundary in the docs emitters, rather than chasing call sites. Note before starting it: step R7.1 deletes the LaTeX path entirely, so this is worth doing only if the PDF survives the Markdown migration.

    • notes: Resolved by deleting the LaTeX writers, which is where the 74 escaping errors lived: the emitters write Markdown since revision2026 step R7.1.6 and no generated .tex file is left but abbreviations and buildDate. The requirement moved with the code rather than disappearing: issueTracker.ToMarkdown escapes the backslash first and then ` * _ [ ] < > # | in every free-text field, the same total escaping as ToLatex, and python/testing/test_issueTracker.py proves it - one test per special character, three shapes that actually occur in the tracker, the backslash-first rule, and that ordinary sentences arrive untouched.

    • date resolved: 2026-09-20 23:05, date raised: 2026-09-19

  • 1.11.221 FIX HIGH raised by: Claude-JG resolved by: Claude-JG the regenerate step of “exudev generate –all-checks” cannot fail on tier 1 drift (#2563)

    • description: tools/regenerate.py fails on tier 1 drift - the API surface that must stay byte-identical - only with –check; exudev generate –all-checks runs it WITHOUT –check, because its job there is to regenerate. The drift is printed (“Generated files differ from the commit”) but the exit code is 0, so the step is reported ok and the change sits in the working tree unnoticed. It happened in step R11.4.5: typesEmitter.py looked for the parent header in src/Objects, the folder had been renamed, and ObjectANCFCable2D and ObjectALEANCFCable2D silently lost their item types Body and MultiNoded in python/exudyn/types/items.py - a tier 1 file. Caught by reading an uncommitted diff, not by a gate. Suggestion: after regenerating, run the comparison again in check mode, or let the summary line of that step say TIER 1 DRIFT rather than ok. See revision2026 step R5.18.10.

    • notes: The regenerate step of exudev generate –all-checks now carries a verdict: after regenerating it runs the drift comparison again without the generators (–no-run –check) and the summary line says “ok, TIER 1 DRIFT” with three lines explaining what to do. It deliberately does not pass –check to the step itself: that step regenerates, and regenerating after an intended change produces drift by design, so the gate would be red on every legitimate change - the failure mode of #2551. The run is not stopped, because the drift may be what is about to be committed. One rule was added to the runner for it: a verdict beginning with “ok” is a success that has something to say. Tested both ways with a changed description in definitions/itemDefsObjects.py.

    • date resolved: 2026-09-20 18:59, date raised: 2026-09-20

  • 1.11.220 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG the tikz flow charts and their hand-made PNG twins (#2564)

    • description: introduction.tex, solver.tex and theory.tex carried 13 tikzpicture environments, and each had a hand-made PNG of the same diagram next to it in an onlyRST branch: the HTML documentation never rendered tikz, it showed the picture, and the two were kept in step by hand. Convert the flow charts to mermaid - text, so they diff and review like code, and rendered by sphinxcontrib-mermaid - and delete the PNG twins. Genuinely geometric figures keep a pre-rendered image. See revision2026 step R7.1.9, maintainer decision D9.

    • notes: Twelve flow charts are mermaid in docs/manual/ - seven in solver.md, four in introduction.md and the contact coupling in theoryContact.md, which existed only as tikz and therefore never reached the HTML at all - and the eleven hand-made PNG twins are deleted. theoryRotations.md keeps its images: the homogeneous transformation is geometry, which is the exception D9 makes. The captions go into the :caption: option of the mermaid directive rather than into an italic line, because a {ref} needs a titled target and four cross references broke without it. sphinxcontrib-mermaid is in the docs dependency group and in conf.py; it renders in the browser from a CDN, so a locally opened page without internet shows the diagram source.

    • date resolved: 2026-09-20 18:34, date raised: 2026-09-20

  • 1.11.219 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG five howTo files are .txt renamed to .md (#2547)

    • description: buildFromSource.md, gccVsMsvcTraps.md, matplotlibExamples.md, sphinxDocs.md and visualStudio2022.md were renamed from .txt in step R3.6 and never converted: they have no fenced code blocks, and every line beginning with a hash - a shell comment - renders as a heading. buildFromSource.md is the canonical build reference and the worst affected. They are excluded from the documentation until they are converted, and linked to GitHub from the developer index so that nothing points at a page that does not exist. convertVideosFfmpeg.md was converted as an example of what they need.

    • notes: buildFromSource, gccVsMsvcTraps, matplotlibExamples, sphinxDocs and visualStudio2022 are real Markdown and are in the documentation: out of exclude_patterns, into the toctree, and the developer index links them locally again - all eight docs/howTo pages are documents now. Converting them meant rewriting them, because formatting alone would have produced correct Markdown with wrong instructions: buildFromSource described Anaconda with Python 3.6, a main/ directory that no longer exists and setup.py bdist_wininst; it is written for the repository as it is now and keeps what is nowhere else (the Linux OpenGL/X11 packages, the WSL permission trap, choosing a GCC version, gdb). sphinxDocs names the docs dependency group and the -W gate instead of a pip list, visualStudio2022 the three components that matter. gccVsMsvcTraps and matplotlibExamples are knowledge rather than instructions and needed mainly structure and code fences.

    • date resolved: 2026-09-20 18:04, date raised: 2026-09-19

  • 1.11.218 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG the src/Objects folder holds nodes, markers, loads, sensors and system code (#2556)

    • description: src/Objects/ is named after one of the five item types but holds all of them, plus checkPreAssembleConsistencies.cpp and evaluateUserFunctions.cpp, which are system code, and the UpdateGraphics functions, which are graphics. Split it into ImplObjects, ImplNodes and ImplMarkers (loads and sensors are short and stay in one file each, in System); the Visu files go to Graphics and the two system files to System. Deliberately a small change and not a systematic restructuring of the whole tree. Every moved file is a tracked file and the vcxproj, sources.json and gen_sources follow. See revision2026 step R11.4.5.

    • notes: src/Objects is gone: 53 CObject*.cpp and CObjectANCFCable2DBase.h are in src/ImplObjects, 16 CNode*.cpp in src/ImplNodes, 18 CMarker*.cpp in src/ImplMarkers, and the five checkPreAssembleConsistencies* files and evaluateUserFunctions.cpp in src/System, next to the loads and sensors that were already there. After R11.4.4 there was no Visu*.cpp left to move to Graphics. Both project files, both lists of sources.json (minimal is carried over, not derived, so it was rewritten by hand), definitionValidator.py, the include path of CObjectANCFCable2DBase.h in definitions/itemDefsObjects.py - which carried into the generated headers by regeneration - and the module table of ARCHITECTURE.md follow. gen_sources –check passes, the suite is 116 + 23 and pytest 174.

    • date resolved: 2026-09-20 17:47, date raised: 2026-09-19

  • 1.11.217 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG all UpdateGraphics functions live in a file named after the first item that had one (#2555)

    • description: src/Objects/VisuNodePoint.cpp holds ~79 UpdateGraphics implementations - every node, object, marker, load and sensor - in 4171 lines, under a name that only made sense when VisualizationNodePoint was the first item to have one. Split it the same way as checkPreAssembleConsistencies, into Visu<ItemType>.cpp. To be measured first: whether each UpdateGraphics can instead go into its own CItem*.cpp, which would be the natural place; the question is compilation time, because pybind11 is not included in most of those files today. See revision2026 step R11.4.4.

    • notes: VisuNodePoint.cpp is gone: its 79 UpdateGraphics implementations sit in the file of their own item - 68 existing C<Item>.cpp, the three loads in System/CLoad.cpp, the six sensors in System/CSensor.cpp, and a new CObjectSuperElement.cpp for the item that had no implementation file. The maintainer chose this over five Visu<ItemType>.cpp files. The file-local helpers (the drawNodesMarkersLoadsWithFaces constant and the two templates for the ANCF cables and the 3D beams) are in the new src/Graphics/VisualizationItemHelpers.h. The four EXUDYN_MINIMAL_COMPILATION regions disappear: a minimal build now compiles fewer files instead of excluding four fifths of one file. Verified textually - all 79 bodies are identical to the ones in the deleted file - because no test calls UpdateGraphics at all, which is now its own issue.

    • date resolved: 2026-09-20 14:41, date raised: 2026-09-19

  • 1.11.216 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG checkPreAssembleConsistencies.cpp is one file for five item types (#2554)

    • description: src/Objects/checkPreAssembleConsistencies.cpp holds 62 CheckPreAssembleConsistency implementations for objects, nodes, markers, loads and sensors in 2602 lines. Split it into five files, checkPreAssembleConsistencies<ItemType>.cpp, one per item type - five and not one per item, because each file includes pybind11 and that include dominates the compilation time. See revision2026 step R11.4.3.

    • notes: checkPreAssembleConsistencies.cpp (2602 lines, 49 functions) is now four files: Objects 28, Markers 10, Nodes 5, Sensors 6 - four and not five, because MainLoad has no CheckPreAssembleConsistency. The shared tolerances and the IsInRange template moved to a new checkPreAssembleConsistencies.h. The includes do not follow the kind of the file, which the first build showed: a sensor check dereferences CObjectKinematicTree and a marker check looks at the body it is attached to, so each file gets the headers whose class its own bodies name (35 for the objects, 11/8/8 for the rest, against 55 in the one file). vcxproj, filters and both lists of sources.json follow; gen_sources –check passes, the suite is 116 + 23 and pytest 174.

    • date resolved: 2026-09-20 14:29, date raised: 2026-09-19

  • 1.11.215 FIX HIGH raised by: Claude-JG resolved by: Claude-JG a module deleted from the package is still shipped in the wheel (#2560)

    • description: After exudyn/resultsMonitor.py moved to exudyn/misc/ the old file was still in the installed package. The cause is not pip: setuptools copies the package from build/lib.<platform>/exudyn/, and all five modules that moved were still in that tree, so the built wheel shipped exudyn/resultsMonitor.py - a file that no longer exists in the source. A release built without cleaning ships deleted modules to users. It also masked a real bug: exudyn/__init__.py still did “from .mainSystemExtensions import …” and only worked because of the stale copy; deleting the build trees made it fail at once. exudev build should clear the package tree under build/lib.* before building, and the release step should verify that the wheel module set matches the source. See revision2026 step R5.18.8.

    • notes: exudev build removes build/lib.<platform>/exudyn before every build, not only with –clean: that tree is what setuptools copies the package from, so a module deleted from python/exudyn survived there and went into the wheel. Only the .py copies are removed; the C++ objects in build/temp.* stay, so the one-minute wheel is unaffected. A second step compares the wheel exudyn/*.py against python/exudyn and fails on a difference - tested by planting a ghost module in build/lib.*/exudyn and building a wheel the way pip wheel builds it: the step reported it and returned 1.

    • date resolved: 2026-09-20 14:19, date raised: 2026-09-20

  • 1.11.214 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG the stub check is intermittent: resultsMonitor._ControlPanel.tk fails about one run in three (#2551)

    • description: checkPython.py –stubs –check reports “exudyn.misc.resultsMonitor._ControlPanel.tk is not present at runtime” on some runs and passes on others - measured 2026-09-19: one failure in three consecutive runs with no change in between. _ControlPanel derives from a tkinter widget and the tk attribute exists only once a Tk instance has been created; whether stubtest sees it seems to depend on import order or on a display being available. A gate that fails randomly is worse than no gate: it trains everyone to rerun until green. Either make the probe deterministic or put this name in the curated noise list with the reason. Found while working on revision2026 step R7.1.5; not caused by it.

    • notes: exudyn.misc.resultsMonitor._ControlPanel.* is in tools/ci/stubtestNoise.txt, the curated list, with the reason next to it: a tkinter widget carries the attributes of the Tk instance it belongs to and tk exists only once a root has been created, so whether stubtest sees it depends on import order and on a display. Not in the generated backlog, which is meant to shrink. Five consecutive runs of the gate, all green.

    • date resolved: 2026-09-20 14:19, date raised: 2026-09-19

  • 1.11.213 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG the documentation knows neither the new monitor nor the package command line (#2559)

    • description: docs/theDoc/theDoc.tex still describes the results monitor as “copy resultsLoader.py to your directory and call python resultsMonitor.py file.txt”, and pastes a -h output that no longer exists; the section is hand-written LaTeX in a file that is otherwise the LaTeX skeleton. And “python -m exudyn” is documented nowhere, because it did not exist. Needed: the monitor section rewritten as Markdown in docs/manual/ - the three ways to call it, the file dialog and –last, the control panel, the settings file, and a pointer to “python -m exudyn monitor –help” rather than a pasted option list that goes stale - and a page for the four commands of the package command line, with “info” named in CONTRIBUTING.md as what to paste into a bug report. See revision2026 step R7.7.

    • notes: Two pages in docs/manual/: commandLine.md for python -m exudyn (the four commands, info as what to paste into a bug report, and why there is deliberately no console script yet) and resultsMonitor.md, which carries the old sec:resultsMonitor label so references still resolve. Neither pastes an option list - both end at –help, since a pasted list going stale is what this step repairs: theDoc.tex still described copying resultsLoader.py and printed the options of a script that no longer exists, and those 30 lines are removed. The chapters that are already Markdown got the cross-references a reader needs: gettingStarted (demo and info as the check that needs no file), gettingStartedFAQ (run info before asking) and solver.md at parameter variation and optimization, which write the resultsFile the monitor shows. CONTRIBUTING.md asks for the info block.

    • date resolved: 2026-09-20 14:12, date raised: 2026-09-20

  • 1.11.212 TESTING NORMAL raised by: Claude-JG resolved by: Claude-JG test_exceptions.py relied on another test file importing the MainSystem extensions (#2561)

    • description: The solver-file tests of step R6.8 call mbs.SolveDynamic, which exists only once exudyn.utilities (or exudyn.misc.mainSystemExtensions) has been imported - and test_exceptions.py imported neither. Under pytest -n 8 it passed as long as the worker that ran it had already run a test that does import them; adding one test model changed the distribution and three tests failed with FileNotFoundError, because the AttributeError was swallowed by the except BaseException of the helper. Fixed by importing exudyn.utilities in the test file. The wider question stays open: a test file that depends on an import made elsewhere is a test that passes by luck, and the helper that catches BaseException hides which error it was.

    • notes: test_exceptions.py imports exudyn.utilities now, so the MainSystem extensions it uses are installed by the file that uses them rather than by whichever test file ran before it in the same pytest worker. The three failures appeared when adding resultsMonitorTest.py changed the distribution of pytest -n 8. The wider point is recorded in revision2026 step R6.8.1: a test that depends on an import made elsewhere passes by luck, and the helper that catches BaseException hid which error it was.

    • date resolved: 2026-09-20 09:40, date raised: 2026-09-20

  • 1.11.211 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG command line of the exudyn package (#2558)

    • description: python/exudyn/__main__.py so that “python -m exudyn <command>” gives the small things one wants from a shell without writing a script: monitor (the results monitor), plot (PlotSensor on files), info (version, paths, module, optional packages - what a bug report needs) and demo. The commands sit in a plain dictionary CommandTable() and each is imported when it is called, so that revision2026 R9.6 can add plugin commands through entry points. Deliberately no console script in pyproject.toml: nothing goes on PATH until the command set has settled. See revision2026 step R8.8.

    • notes: python/exudyn/__main__.py: python -m exudyn monitor|plot|info|demo, commands in a plain CommandTable() dictionary, each imported when it is called, so R9.6 can add plugin commands through entry points. No console script in pyproject.toml for now. Note for the test suite: importing a __main__ RUNS it, so __main__.py had to enter the excludeModules list of allExudynModulesTest.py.

    • date resolved: 2026-09-20 09:34, date raised: 2026-09-20

  • 1.11.210 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG resultsMonitor rewrite (#2557)

    • description: python/exudyn/resultsMonitor.py was a 2021 script inside the package: it read sys.argv and called plt.ion() at import time, its __all__ listed 34 script locals, it was excluded from allExudynModulesTest.py and carried a ruff E402 and a stubtest baseline entry. It becomes exudyn/misc/resultsMonitor.py: the library function MonitorResults(…), an argparse CLI behind it, file selection by dialog or –last, a tkinter control panel (stdlib only), a settings file in ~/.exudyn/, incremental reading instead of re-parsing the whole file on every tick, and –once so that a run without windows draws once and cannot hang - which is what makes resultsMonitorTest.py possible. See revision2026 step R6.9.

    • notes: Written in a parallel session and integrated here: exudyn/misc/resultsMonitor.py with MonitorResults(…), an argparse CLI, file selection by dialog or –last, a tkinter control panel, a settings file in ~/.exudyn/, incremental reading and –once - which is what makes python/TestModels/resultsMonitorTest.py possible (1.2 s; four file types, the incremental reader including a torn last line, the buffer reset after an overwrite, eight command-line return codes). The integration meant the reference-solution entry, the excludeModules list of allExudynModulesTest.py, two processing.py docstrings and one example header. The ruff E402 entry and the allExudynModulesTest exclusion are gone.

    • date resolved: 2026-09-20 09:34, date raised: 2026-09-20

  • 1.11.209 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG five modules belong in exudyn/misc rather than in the package root (#2552)

    • description: docmeta.py, GUI.py, resultsMonitor.py, extensionRegistry.py and mainSystemExtensions.py sit next to the modelling modules in python/exudyn/ although none of them is one: docmeta and extensionRegistry are machinery, GUI and resultsMonitor are tools, mainSystemExtensions is the extension mechanism. Move them into python/exudyn/misc/ and leave their content alone - resultsMonitor is being revised in another session at the same time, so this step is a pure relocation and the references to it are fixed when those changes are integrated. See revision2026 step R11.4.1.

    • notes: docmeta.py, GUI.py, resultsMonitor.py, extensionRegistry.py and mainSystemExtensions.py are in python/exudyn/misc/ with an __init__.py that says what the subpackage is for; their content is untouched. Followed the move: 23 files referencing exudyn.<module> - among them src/Main/rendererPythonInterface.cpp with 9 occurrences, because the renderer builds its dialogs from Python source held in C++ strings - setup.py, where the shipped packages are enumerated, the module list of tools/generators/utilityDocsModel.py, three re-pathed entries of the ruff baseline and the __all__ check. Tested by building into venvP312 rather than venvExuP313, which holds a build from the parallel session: all five modules ship and import, and the full test suite passes there.

    • date resolved: 2026-09-19 23:27, date raised: 2026-09-19

  • 1.11.208 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG the comment “only import if it does not conflict” reads as advice not to import (#2553)

    • description: 458 tracked files carry “import exudyn.graphics as graphics #only import if it does not conflict”. The comment was meant to warn that the name graphics can collide with another package or a local variable, but it reads as a condition on the import itself, and it has been copied into every example and test model. Remove the comment; the import stays. The copies under docs/RST/Examples and docs/RST/TestModels are generated from the .py files and follow by regeneration. See revision2026 step R11.4.2.

    • notes: Removed from 240 tracked files (253 occurrences): the examples, the test models, the utility modules, the performance models and the converted manual; the copies under docs/RST followed by regeneration. The import itself is unchanged. Two occurrences were written with a space after the hash, so the removal was a regular expression rather than a literal search. The warning behind the comment is real - the name graphics can be shadowed - and belongs in the documentation of exudyn.graphics once, not in every model.

    • date resolved: 2026-09-19 23:20, date raised: 2026-09-19

  • 1.11.207 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG the hand-written documentation chapters are LaTeX and have to become Markdown (#2549)

    • description: The seven chapters that are still LaTeX - gettingStarted, introduction, tutorial, GUI, notation, theory, solver - are the original sources; the generated .rst does not carry all of their information, so each one is converted by hand-checked machine conversion and then becomes the source itself. tools/tex2md.py is the one-shot converter for it and is deleted again in step R7.1.7. A converted chapter leaves filesParsed in doc2rst.py in the same commit, so that its generated .rst files and their duplicate labels disappear with it. See revision2026 step R7.1.5.

    • notes: All seven hand-written chapters are MyST Markdown in docs/manual/ and split into 22 documents named <chapterStem><Section>.md. The theDoc.tex preamble is not converted: it is the LaTeX skeleton and dies with the LaTeX build. tools/tex2md.py did the conversion and is deleted again in step R7.1.7. Each chapter was checked word by word against the .rst Sphinx rendered before it; the only differences are markup tokens, plus three places where the old path was worse - dropped citations, a Windows path whose backslashes were eaten, and the contact theory (7200 words) which had no .rst at all and reaches the HTML for the first time. The conversion also found that conf.py declared only 118 of the 204 math macros, because the old converter expanded them; all 46 the chapters use are declared now and tools/checkMathMacros.py is the eighth check of exudev generate –all-checks. README.rst became hand-written and a document of the documentation (D11), with its version line stamped by issueTracker.py.

    • date resolved: 2026-09-19 22:54, date raised: 2026-09-19

  • 1.11.206 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG the developer documentation is written as Markdown and published nowhere (#2546)

    • description: docs/dev/ARCHITECTURE.md, CODING_STYLE.md, WORKFLOW.md and README.md, the howTo notes and the README files of definitions/ and the generators are written as documentation and are visible only to someone with a clone. Sphinx reads only RST today. Add myst-parser, give them toctree entries, and they are on readthedocs with everything else - which is also the cheapest possible test of the MyST path that step R7.1 rests on, on real files rather than on a sample.

    • notes: myst-parser is in the docs dependency group and in conf.py, with myst_heading_anchors = 3 so that anchor links between Markdown files work, and eleven Markdown documents are in the toctree: the four docs/dev files, CONTRIBUTING.md, the READMEs of definitions/, the generators and exudev, and the three docs/howTo notes that are really Markdown. The strict build found eleven broken cross-references that were invisible while the files were clone-only, and #2547 - five how-to files that are .txt renamed to .md. convertVideosFfmpeg.md was converted as the example of what those need. The premise of R7.1 holds: the two formats coexist, which is what makes a chapter-by-chapter conversion possible.

    • date resolved: 2026-09-19 19:36, date raised: 2026-09-19

  • 1.11.205 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG the installation documentation is years out of date (#2388)

    • description: docs/theDoc/gettingStarted.tex still instructs users with Python 3.6 and 3.7; 32 bit Anaconda; Spyder 4.1.3 and wheel names like exudyn-1.0.20-cp36-cp36m-win32.whl; and it discusses choosing between 32 and 64 bit installations. None of that has been built for years and after revision2026 step R2.6 the 32 bit build configurations no longer exist at all. The install section needs rewriting against the versions that are actually shipped (cp310-cp314; 64 bit only). Found during revision2026 step R2.6

    • notes: The requirements section is written against what CI publishes - wheels for Python 3.10 to 3.14 on Windows, Linux and MacOS, 64-bit only, with one sentence saying that advice about matching 32-bit and 64-bit installations is out of date. The wheel section explains the naming rule (cp313 means CPython 3.13) and shows one line per operating system instead of three file names from 2020 for Python 3.6 and 3.7. Visual Studio 2022 replaces the VS2017 recommendation. Also removed: a deprecated AVX workaround pointing at the Python 3.6 build, an example traceback with a main-pythonDev path, and two paths dated to Python 3.6. The dated per-machine notes in the platform build sections stay - they read as history and belong to step R7.2.

    • date resolved: 2026-09-19 19:09, date raised: 2026-09-12

  • 1.11.204 BUG HIGH raised by: Claude-JG resolved by: Claude-JG issue text is written into trackerlog.tex without escaping (#2544)

    • description: issueTracker.py writes every issue name, description and resolution note straight into docs/theDoc/trackerlog.tex, which is LaTeX. A caret, an underscore, a hash, an ampersand or a backslash command in an issue is therefore executed or aborts pdflatex. Both already happen: issue 2398 says O(N^2) per step and produces “Missing $ inserted”, and an issue that mentioned a backslash-input command made the build stop with “File not found” 629 pages in. The RST writer has the same question with different characters. Escape at the writer, where the format is known, rather than asking every issue author to think about LaTeX.

    • notes: ToLatex() in issueTracker.py escapes every LaTeX special character now - backslash first, then braces, underscore, hash, ampersand, dollar, percent, caret, tilde. Escaping is total by the maintainer decision of 2026-09-19: the few issues from 2016-2020 that contain deliberate markup render as the characters they are, and in exchange the documentation build cannot be broken by what someone types into the tracker. Found because the issue describing the OTHER PDF causes mentioned a backslash command, which LaTeX then executed 629 pages into the build.

    • date resolved: 2026-09-19 17:24, date raised: 2026-09-19

  • 1.11.203 BUG HIGH raised by: Claude-JG resolved by: Claude-JG theDoc.pdf cannot be built any more (#2543)

    • description: pdflatex on docs/theDoc/theDoc.tex fails, and the plan recorded only that it does. Measured 2026-09-19. (1) fatal: the title page reads version.txt beside itself, and version.txt moved to the repository root in step R3.4. (2) fatal: 19 references to the tree main-pythonDev in five hand-written .tex files, which steps R3.1 and R3.8 dissolved; one of them is a listing input, which aborts the run. (3) non-fatal: theDoc.tex line 334 had one closing brace too many on the version line. (4) THE BIG ONE, found while fixing the others: trackerlog.tex is generated from issue text that is not escaped for LaTeX at all, so a caret, an underscore, a hash or a backslash command in any issue description is executed or aborts the build. This blocks step R7.3, which wants the PDF built in CI instead of committed.

    • notes: Four causes, all restructuring fallout. Fixed: the title page reads ../../version.txt (root since R3.4); 19 main-pythonDev references in five hand-written .tex files rewritten to python/…; the extra closing brace on theDoc.tex line 334; and, the big one, issue text is escaped for LaTeX now (#2544). A complete 8.4 MB PDF is produced where none was before, and the error count went from 158 fatal to 74 non-fatal. The remainder is the same escaping bug in the other documentation emitters, raised separately. This unblocks R7.3.

    • date resolved: 2026-09-19 17:24, date raised: 2026-09-19

  • 1.11.202 BUG HIGH raised by: Claude-JG resolved by: Claude-JG the gate environment can hold a stale exudyn wheel (#2517)

    • description: The commit gates run in venvExuP313, exudev build installs into venvP313. So a C++ change can be built and the gates can still run against a wheel from an earlier version - a green result that means nothing. Seen on 2026-09-18: venvExuP313 held 1.11.173.dev1 while the sources were at 1.11.176.dev1. Either exudev build installs into the generator environment as well, or the checks refuse to run when the installed version differs from version.txt. revision2026 step R5.18.

    • notes: Both halves. exudev build –env <environment> builds and installs into the generator environment (added 2026-09-18), which removes the cause in the normal workflow; and tools/checkPython.py –stubs now REFUSES to run when the installed exudyn version differs from version.txt, naming both versions and the command that fixes it. The refusal is in the tool and not in the exudev driver, because checkPython.py –stubs –check is a command a person or a CI job runs directly. Verified by faking the mismatch: it exits 1 with that message. The other five checks are static and are deliberately not guarded - blocking them between ResolveIssue and the next build would make the gate fight the workflow. The test suite is not guarded either; its log file carries the version, and exudev test legitimately targets other environments.

    • date resolved: 2026-09-19 09:54, date raised: 2026-09-18

  • 1.11.201 BUG HIGH raised by: Claude-JG resolved by: Claude-JG mainSystemExtensionDocsEmitter writes none of its five outputs (#2526)

    • description: The file ends in the middle of main() - no write call and no __main__ block - so the generator runs, exits 0 and produces nothing. Its five declared outputs (MainSystemExt.rst, MainSystemCreateExt.rst, stubAutoBindingsExt.pyi, docs/theDoc/MainSystemExt.tex, MainSystemCreateExt.tex) have been frozen at their committed content since the split of revision2026 step R4.3 part 2e (commit 94710e6). The regeneration gate cannot see this: a generator that writes nothing always agrees with the commit. The writing half is in git at 94710e6^:src/pythonGenerator/utilitiesDocuGenerator.py lines 1050-1119. Found while fixing #2525, whose new link prefix could not reach those five files.

    • notes: The writing half was recovered from 94710e6^ and the loop body completed; the emitter writes its five outputs again and has a __main__ block. Five days of freezing came to ~1000 changed lines, most of it GitHub links still pointing at main/pythonDev - what step R7.6 could not repair - plus downstream changes in __init__.pyi and docs/RST/cInterface/MainSystem.rst. Not restored: the original also overwrote python/exudyn/mainSystemExtensions.py, a hand-written module this generator parses, which is not a declared output of the stage. And generate.py now FAILS a stage that exits 0 without producing any declared output - verified by commenting the writes out again and seeing it fire. Two generators that write only on change declare writesOnlyWhenChanged=True.

    • date resolved: 2026-09-19 08:12, date raised: 2026-09-18

  • 1.11.200 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG the exception types are decided but not documented for users (#2542)

    • description: Step R6.3 built nine exception classes and decided what each one means; nothing tells a USER about them. The only places that describe the taxonomy are docs/dev/CODING_STYLE.md section 10, which is written for someone adding a check in C++, and the revision log, which is a record. A user needs the other direction: which type to catch, what it says about whose mistake it was, and what to do about it - including the one case with a concrete action behind it, catching a solver failure to retry with smaller steps or to score a failed run in a parameter variation.

    • notes: Written as a subsection of Exudyn Basics in docs/theDoc/introduction.tex, before “Removing convergence problems and solver failures”: the nine types with the built-in each also derives from and what each says about whose mistake it was; catching a solver failure to retry with smaller steps or to score a failed run in a parameter variation; an error inside a user function arriving as ModelError with the original as __cause__; where the message is written (console once, every open log file); deprecation warnings and the switches. In LaTeX because that is the user documentation today - R7.1 will convert it with the rest. exudev docs (sphinx-build -W) passes.

    • date resolved: 2026-09-19 07:51, date raised: 2026-09-19

  • 1.11.199 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG the binary selection in __init__.py is a nest of try/except blocks (#2540)

    • description: Four nested try/except blocks choose between exudynCPPfast and exudynCPP and between the installed-package and the Visual Studio layout. Nothing records which one was taken, the decisions are printed unconditionally or not at all, and a total failure raises one sentence about 32/64 bit versions that names neither the candidates nor the reason each failed - and 32-bit builds were dropped long ago. Make it one function that returns its log, print the log under an env var, and raise a single ImportError listing every attempt. Hard prerequisite for phase R9, where a plugin is bound to the module it was built against and which one was loaded has to be answerable.

    • notes: _ImportCompiledModule(useExudynFast) returns (name, module, attempts) and raises one ImportError listing every candidate and why it was skipped or failed; EXUDYN_IMPORT_VERBOSE=1 prints the log; a fast module that was asked for and not loaded says so unconditionally, with the reason. The star import became globals().update(…) because the module name is a variable. The lexicographic numpy version compare the issue named no longer exists - it went with the AVX2 rewrite of R2.10 - so no packaging dependency was added for it. New python/testing/test_import.py covers the log and the failure message.

    • date resolved: 2026-09-19 07:44, date raised: 2026-09-19

  • 1.11.198 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG a bare except in the shipped package swallows Ctrl-C (#2539)

    • description: 52 bare except: remain in python/exudyn/ across 16 files. A bare except catches KeyboardInterrupt and SystemExit as well - so Ctrl-C is swallowed wherever one wraps something long: the inverse-kinematics SolveSystem in robotics/roboticsCore.py, the ffmpeg run in interactive.py, the multiprocessing pool in FEM.py. The larger group - 23 of them - guards an optional import and therefore reports a broken installation of scipy or roboticstoolbox as “the package is missing”. Name what is caught: ImportError for a dependency probe, the specific error for a feature probe, and except Exception for something that must survive an external tool or a users own code - which still lets KeyboardInterrupt through. The 16 E722 entries of tools/ci/ruffBaseline.txt are the inventory and must disappear with the step.

    • notes: All 52 named, plus one inside a docstring example. Four rules did it: 23 ImportError for a dependency probe, 16 specific errors for a feature probe (AttributeError, IndexError, KeyError, tk.TclError, np.linalg.LinAlgError, exudyn.ExudynError), 13 except Exception where catching everything is genuinely meant - which still lets KeyboardInterrupt through. The ruff baseline lost its 16 E722 entries and went from 205 tolerated findings to 151, so a new bare except in the package now fails the gate; no pytest was added, because that gate already is the regression test. Correction to the issue as first written: the seven handlers in processing.py are not around the parameter-variation loop - parameterFunction(…) is not wrapped at all and a user model that raises has always propagated.

    • date resolved: 2026-09-18 23:51, date raised: 2026-09-18

  • 1.11.197 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG an error raised by a macro never reaches the solver file (#2538)

    • description: PyError, SysError and PyWarning take an std::ofstream and write the message to it; CHECKandTHROW and CHECKandTHROWstring write nothing - and after step R6.3.6 those are more than 1100 call sites carrying a real type. So the message that ends a solver run can be missing from exactly the file someone opens afterwards to find out why it ended. Catch it where the file is known: CSolverBase::SolveSystem is the only place that holds file.solverFile and it wraps all three solver phases. Write the same block there that the pout log file gets and re-raise. With that in place the twelve PyError/SysError calls that pass file.solverFile would write twice - so the two ofstream overloads go and the argument is dropped at those sites: one writer, one rule. PyWarning keeps its ofstream overload because a warning throws nothing and the outer catch can never see it.

    • notes: CSolverBase::SolveSystem wraps its three phases in a try and writes whatever escapes to file.solverFile with ErrorMessageBlock - the same block the pout log file gets - then re-raises. That covers every helper, including the 1100+ CHECKandTHROW sites that could never pass a file. The twelve PyError/SysError calls that passed file.solverFile would then have written twice, so the two ofstream overloads are removed and the argument dropped: one writer, one rule. PyWarning keeps its overload because a warning throws nothing and that catch can never see it. The rule for all three channels is written into CODING_STYLE section 10.7; VerboseWrite already honoured verboseMode and verboseModeFile independently, so the error row was the only broken one. Tested: test_aMacroErrorReachesTheSolverFile uses a forceUserFunction returning the wrong size - a plain CHECKandTHROW inside CObjectGenericODE2 - and finds the message in the solver file.

    • date resolved: 2026-09-18 23:41, date raised: 2026-09-18

  • 1.11.196 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG an Exudyn exception stringifies the error that caused it instead of chaining it (#2537)

    • description: A user function that raises ZeroDivisionError reaches Python as a ModelError whose MESSAGE contains the words ZeroDivisionError: float division by zero. The original object is gone: e.__cause__ is None and the traceback that pointed into the user function survives only as printed text. py::raise_from (pytypes.h:818) sets __cause__ and __context__ and keeps the traceback - it needs the registered Python class as a PyObject* and the original exception as an object. Carry the original from the handler that caught it to the pybind boundary and chain it in one exception translator. Split off from step R6.3.5 on 2026-09-18 and confirmed by the maintainer after reading the model in Spyder.

    • notes: The three handlers that catch error_already_set now store the original with SetPendingExceptionCause(ex.value().ptr()) - a thread_local PyObject* with explicit incref, not a py::object whose destructor would need the GIL at thread exit - and ONE exception translator in PybindModule.cpp, registered after the eight register_exception calls so that it is tried first, restores it as the current error with its traceback and calls py::raise_from. Control flow is unchanged: the same C++ types are thrown as before, which is why this was not done by calling raise_from in the handler - that would throw py::error_already_set and every intermediate catch(EXUexception) would stop matching. A user function that divides by zero now arrives as ModelError with __cause__ = the ZeroDivisionError and its traceback pointing at the users own line; an error with no Python behind it keeps __cause__ is None; parameterConversionTestReference.txt did not move.

    • date resolved: 2026-09-18 23:13, date raised: 2026-09-18

  • 1.11.195 BUG HIGH raised by: Claude-JG resolved by: Claude-JG a typed exception from the solver no longer stops the renderer (#2531)

    • description: globalPyRuntimeErrorFlag is set in exactly two places: PyError and SysError (Stdoutput.cpp). The CHECKandTHROW* macros never set it. Until #2524 a bare EXUexception escaping a solver step fell into SolverExceptionHandling catch(EXUexception) and became SysError - which set the flag and stopped the renderer. That handler now has catch(const ExudynError&){throw;} in front of it (needed so the type is not flattened) so every site typed by step R6.3.6 passes through and the flag stays false. The renderer then keeps running and keeps calling Python while Python is in an error state (GlfwClient.cpp reads the flag in five places). The behaviour now depends on how far R6.3.6 has got which is an accident. Set the flag where SOLVER errors are caught - not in ThrowPyErrorType which would make every typed exception anywhere shut the renderer down.

    • notes: The flag is raised at the solver boundary, in the two pass-through catches of SolverExceptionHandling before the throw - where the maintainer placed it, because the renderer stalls anyway once an exception reaches the solver. Not in ThrowPyErrorType, which would stop the renderer for an error raised while a model is being built and for each of the ~38000 probe errors of parameterConversionTest. The rule itself (honour deactivateGlobalPyRuntimeErrorFlag) now lives once, in StopRendererOnError(), called from PyError, SysError and the solver boundary. No automated test is possible: the flag is not exposed to Python and rule 11 forbids opening a renderer here - the suites only show that raising it does not poison a later run.

    • date resolved: 2026-09-18 23:02, date raised: 2026-09-18

  • 1.11.194 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG the explicit dynamic solver returns False instead of raising (#2536)

    • description: In SolveDynamic the implicit branch prints SolverErrorMessage and raises when the solver fails; the explicit branch (ExplicitEuler, RK44, DOPRI5, VelocityVerlet, …) has no try and no check at all and simply returns False. The same call therefore aborts loudly or continues silently depending on solverType, and a user who does not test the return value keeps computing with the state of a failed run - exactly the case the maintainer named for parameter variations. Make the explicit branch behave like the implicit one.

    • notes: The explicit branch of SolveDynamic now prints SolverErrorMessage and raises like the implicit one, instead of returning False in silence. Also raise ValueError(solver type not implemented) became exudyn.NotImplementedFeatureError.

    • date resolved: 2026-09-18 22:32, date raised: 2026-09-18

  • 1.11.193 BUG HIGH raised by: Claude-JG resolved by: Claude-JG a failed SolveDynamic leaves simulationSettings overridden (#2535)

    • description: SolveDynamic with DynamicSolverType.TrapezoidalIndex2 overrides timeIntegration.generalizedAlpha.useNewmark and useIndex2Constraints and restores them at the end of the finally block. The “raise ValueError(SolveDynamic terminated)” sits in the same finally block ABOVE those lines, so on failure the restore never runs: the user simulationSettings keep useNewmark=True and useIndex2Constraints=True and the NEXT solve in the same script silently uses a different integrator. Wrong results without any message. Found while reading the raise sites for the exception work.

    • notes: The restore of useNewmark and useIndex2Constraints moved into its own finally block, which runs on every path. It used to sit below the raise in the same finally block, so a failed TrapezoidalIndex2 solve left the users simulationSettings overridden and the next solve in the same script silently used a different integrator.

    • date resolved: 2026-09-18 22:32, date raised: 2026-09-18

  • 1.11.192 FIX HIGH raised by: Claude-JG resolved by: Claude-JG SolveStatic and SolveDynamic throw the real exception away (#2534)

    • description: solver.py has “try: success = solver.SolveSystem(…) / except: pass / finally: if not success: … raise ValueError(…)”. The except swallows the exception that actually explains the failure - since step R6.3.6 that is an ExudynModelError, an ExudynSolverError for a singular matrix, or the user own ZeroDivisionError from a user function - and replaces it with a fixed sentence and a lost traceback. Re-raise it instead. Only the other failure mode needs a manufactured exception: SolveSystem returning False without throwing (no Newton convergence, step size below minimum), and there exudyn.SolverError is the honest answer. NOTE the raise must move out of the finally block at the same time: a raise in finally REPLACES an exception that is still propagating, so removing the except alone would lose the original error by a different route.

    • notes: except: pass is gone from SolveStatic and SolveDynamic (both branches). A solve that threw now re-raises the original exception with its traceback after printing SolverErrorMessage; a solve that returned False without throwing raises exudyn.SolverError. Model exceptionTypesTest.py case 9 now reads SolverError: CSolverBase::Newton: System Jacobian seems to be singular instead of ValueError: SolveStatic terminated due to errors; case 10 reads ModelError with the user function that divided by zero. except ValueError around a solve still catches the common case because ModelError and ExudynValueError derive from ValueError.

    • date resolved: 2026-09-18 22:32, date raised: 2026-09-18

  • 1.11.191 CHANGE HIGH raised by: Claude-JG resolved by: Claude-JG map the user-facing error sites onto the exception classes (#2528)

    • description: The classes exist (#2516), the helpers can carry them (#2521) and the triage says which site is for whom (#2520) - but 1082 user-facing call sites still raise whatever they always raised. Map them area by area, starting with src/Pymodules, the layer closest to the user. revision2026 step R6.3.6.

    • notes: Seven commits, one area at a time: src/Pymodules (54 sites typed), src/Main (185), src/Objects (190), src/Solver+Graphics+System (107), src/Autogenerated (241 from four lines of generator), plus 32 PyError sites no area sweep had covered. Closed with the last move: the untyped CHECKandTHROW and CHECKandTHROWstring default turned from EXUexception into ExudynInternalError, which types ~1100 remaining macro sites from two lines and makes the untyped form MEAN an Exudyn invariant. Nothing in Exudyn raises a bare RuntimeError any more except the ten Add* wrappers, which restate an exception whose type they do not know. Three findings recorded in the log: a hand-written site table stops being reviewable at about 100 sites; a pattern over the message cannot see SysError(s) with the message built above the call - and those three sites were the ones deserving SolverError; and counting PyError calls without a type at the end found 42 that reading area by area had missed.

    • date resolved: 2026-09-18 22:06, date raised: 2026-09-18

  • 1.11.190 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG thirteen tracked text files are not UTF-8 (#2533)

    • description: Eleven C++ sources and one example are cp1252 (a degree sign, a micro sign, an en dash, German umlauts), and docs/theDoc/trackerlog.tex is written by issueTracker.py through an open() with no encoding argument - so it takes the Windows code page. Step R0.6 made the GENERATORS explicit about utf-8; the sources themselves were never converted. A tool that assumes UTF-8 either crashes on them or rewrites them wholesale. Convert them, fix the writer, and add a check so it cannot come back. Note the coupling: docs/theDoc/theDoc.tex declares the latin1 option of inputenc while four other .tex files already contain UTF-8 bytes - that declaration is already wrong for them.

    • notes: Thirteen files converted to UTF-8, LICENSE.txt among them - it credits Camilla Loewy of GLFW and every UTF-8 reader showed that name as mojibake. issueTracker.py:678 (and three version writers) got encoding=utf-8, which was what produced the only non-UTF-8 generated file. docs/theDoc/theDoc.tex now declares the utf8 option of inputenc instead of latin1 - four other .tex files in that directory already held UTF-8 bytes, so the old declaration was already wrong for them; the PDF was NOT built to verify this. New tool tools/checkEncoding.py runs in exudev generate –all-checks and takes –write to convert; it reads git ls-files and exempts python/TestModels/testData/rotorAnsys.rst by name, an ANSYS result file that happens to end in .rst.

    • date resolved: 2026-09-18 21:35, date raised: 2026-09-18

  • 1.11.189 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG eight user-facing not-implemented messages call themselves SYSTEM ERROR (#2532)

    • description: GetOutputVariableConnector and GetAccessFunctionBody of several objects report “not implemented” with SysError - which prints a SYSTEM ERROR block and means “please report this” - although the user reaches them directly with mbs.GetObjectOutput(…) or by attaching a marker to an object that does not support that access type. Step R6.3.6 gave them PyErrorType::notImplementedError which is the honest Python type; the helper is still the wrong one. Change the eight calls to PyError and keep the explicit type (PyError defaults to runtimeError).

    • notes: The eight calls are PyError now, keeping the PyErrorType::notImplementedError that step R6.3.6 gave them (PyError defaults to runtimeError, so the type has to stay written out). The printed block says User ERROR instead of SYSTEM ERROR; the Python type was already right.

    • date resolved: 2026-09-18 21:35, date raised: 2026-09-18

  • 1.11.188 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG the error block is printed to the console although the exception already says it (#2530)

    • description: Since revision2026 step R6.3.5 the exception carries the message and the location; the 5-line ==== block printed by PyError and SysError repeats it on the console. Worse: a caught exception still prints the block, so a GUI or a parameter variation that handles errors floods the terminal with SYSTEM ERROR text for something it handled. Print the block to the pout LOG FILE only (never to the console) - on a long unattended run the file is the only record, and the console has the traceback. Requires a file-only write on OutputBuffer, because pout cannot separate the two channels. Also make the ofstream overloads write the identical block: they currently append Exudyn: parsing of Python file terminated … which is the fixed sentence that R6.3.5 already removed from the exception.

    • notes: The ==== block is written to the pout log file only (new OutputBuffer::WriteToFileOnly) and never to the console: the exception carries the same message and location since #2527, and a caught exception used to print it anyway. Both file channels now write the identical text from the new ErrorMessageBlock(); the file-only sentence Exudyn: parsing of Python file terminated … is gone. PyWarning is unchanged - a warning throws nothing, so the console is its only channel.

    • date resolved: 2026-09-18 20:35, date raised: 2026-09-18

  • 1.11.187 DOCU NORMAL raised by: Claude-JG resolved by: Claude-JG the rules for reporting an error from C++ have no home a human can find (#2529)

    • description: The nine exception classes, the seven helpers and the rules for choosing between them exist only in code comments (ReleaseAssert.h, Stdoutput.h) and in the revision log, which is a record and not a reference. Someone about to write a new check has nowhere to look. Write the rules once, in docs/dev/CODING_STYLE.md, and point CONTRIBUTING.md, docs/dev/README.md and CLAUDE.md at that one place.

    • notes: Written as docs/dev/CODING_STYLE.md section 10 (revision2026 step R6.3.9): which helper, which of the nine types, when to write no type at all, the two traps (catch order; a class not registered in PybindModule.cpp compiles and arrives as RuntimeError), deprecation via PyDeprecated, how to write the message, and tools/errorTriage.py. CONTRIBUTING.md, docs/dev/README.md and CLAUDE.md point at that one place; the section is marked as NOT a transcription of introduction.tex.

    • date resolved: 2026-09-18 20:04, date raised: 2026-09-18

  • 1.11.186 CHANGE HIGH raised by: Claude-JG resolved by: Claude-JG str(exception) carries no information (#2527)

    • description: PyError prints the explanation and then throws the fixed sentence Exudyn: parsing of Python file terminated due to Python (user) error - identical for a bad item number, a string written into a number and a missing marker. The model of revision2026 step R6.3.7 shows six of ten user errors arriving that way. An except block that logs the message logs nothing, and the detail is gone. SysError does the same. revision2026 step R6.3.5.

    • notes: PyError and SysError throw the actual message plus the Python location instead of a fixed sentence, six of the ten cases of the model of #2523 now say what went wrong. PyGetCurrentFileInformation walks out of the exudyn package, so the location is the users own frame and not exudyn/solver.py. revision2026 step R6.3.5.

    • date resolved: 2026-09-18 18:39, date raised: 2026-09-18

  • 1.11.185 FIX HIGH raised by: Claude-JG resolved by: Claude-JG a user function error is reported as a SYSTEM ERROR (#2524)

    • description: An exception raised inside a Python user function is printed once as a User ERROR with the correct traceback and then AGAIN by SolverExceptionHandling as SYSTEM ERROR: EXUDYN raised internal error in CSolverBase::SolveSteps. The user mistake is thereby labelled an Exudyn bug, and since revision2026 step R6.3.3 the C++ class is ExudynInternalError - please report this - although nothing is wrong with Exudyn. Also the file/line header of both blocks names exudyn/solver.py rather than the users own file, while the At: block right below it has the correct line. Found by the model of revision2026 step R6.3.7, belongs to step R6.3.5.

    • notes: the user function handler raises PyErrorType::modelError - a user function is part of the model - and SolverExceptionHandling passes an already-typed exception through instead of re-reporting it as EXUDYN raised internal error. A bare EXUexception still becomes a SysError. The header of the printed block now names the users own file and line. revision2026 step R6.3.5.

    • date resolved: 2026-09-18 18:39, date raised: 2026-09-18

  • 1.11.184 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG every generated GitHub weblink points at the old pythonDev tree (#2525)

    • description: The docs generators build URLs as https://github.com/jgerstmayr/EXUDYN/blob/master/main/pythonDev/<folder>/<file> (autoGenerateHelper.py:1783 and utilityDocsModel.py:528). That path no longer exists: the tree became python/ in revision2026 steps R3.1, R3.8 and R3.9, so every Relevant Examples and TestModels link in the item documentation and every source link of the utility documentation is dead. proposed as a new revision2026 step in phase R7; awaiting approval (found while adding the model of step R6.3.7).

    • notes: the prefix lives in generatorPaths.githubSourceURL and the four generators that built it by hand read it: autoGenerateHelper.py, utilityDocsModel.py and doc2rst.py twice. 368 generated documentation files repaired. The URLs name master and the new layout, so they are right once this work reaches master - one string to change at the release instead of four generators. Five files kept the old links because their generator writes nothing at all, raised as #2526. revision2026 step R7.6.

    • date resolved: 2026-09-18 18:27, date raised: 2026-09-18

  • 1.11.183 TESTING NORMAL raised by: Claude-JG resolved by: Claude-JG no model shows what an Exudyn error looks like from Python (#2523)

    • description: Nothing in the test suite provokes the errors a user actually meets, so there is no record of which exception class and which message reach Python, and no way to look at an Exudyn error the way Spyder or VS Code shows it. Maintainer request 2026-09-18. revision2026 step R6.3.7.

    • notes: python/TestModels/exceptionTypesTest.py provokes ten user errors - bad item number, wrong parameter type and value, wrong size, a feature an item does not have, a missing marker, a system the static solver cannot solve, and a division by zero inside a load user function - catches each and reports the class and the message. Six of ten carry the same sentence about parsing terminated, which is the evidence for step R6.3.5. catchErrors=False with singleCase=N lets one case fly so an IDE shows it. Classes and messages are printed and never asserted, so later steps need not edit the model, testResult is the number of cases that raised nothing. revision2026 step R6.3.7.

    • date resolved: 2026-09-18 18:13, date raised: 2026-09-18

  • 1.11.182 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG deprecation notices are printed lines and not Python warnings (#2522)

    • description: The 199 deprecation notices go through PyWarning; which prints to the console. A user cannot filter them; cannot promote them to errors; and sees the same line on every single call - a deprecated setting read in a loop prints thousands of times. Python has a mechanism for exactly this: DeprecationWarning through PyErr_WarnEx; which is filterable; promotable with -W error::DeprecationWarning and reported once per source location. revision2026 step R6.3.4.

    • notes: PyDeprecated raises a real DeprecationWarning through PyErr_WarnEx: filterable, promotable with -W error::DeprecationWarning, reported once per source location and pointing at the users own file and line. 184 generated sites changed in structureHeaderEmitter.py and 15 hand-written ones converted. It does not call PyGetCurrentFileInformation at all, so 199 sites also stop paying for the inspect.getframeinfo scan of #2423. exudyn.config.suppressWarnings is still honoured. revision2026 step R6.3.4.

    • date resolved: 2026-09-18 18:05, date raised: 2026-09-18

  • 1.11.181 EXTENSION HIGH raised by: Claude-JG resolved by: Claude-JG the error helpers cannot name an exception class (#2521)

    • description: CHECKandTHROW, CHECKandTHROWstring and SysError can only throw EXUexception, so a check cannot say what kind of error it states - and the measurement of #2520 shows no helper is one kind (CHECKandTHROW is 27 percent user-facing, SysError has 10 user sites). The type has to be choosable at the CALL SITE. revision2026 step R6.3.3.

    • notes: CHECKandTHROW and CHECKandTHROWstring take an optional last argument naming the exception class, PyErrorType carries nine kinds and ThrowPyErrorType is the one place that turns one into a throw, SysError defaults to internalError. The MSVC traditional preprocessor needs the selection AND the call expanded together. Six SysError sites in PyMatrixVector.h whose message says check your Python code opt out - they were six of the ten user-facing SysError sites the triage of #2520 had named. revision2026 step R6.3.3.

    • date resolved: 2026-09-18 17:33, date raised: 2026-09-18

  • 1.11.180 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG no way to tell a user error from an Exudyn bug in the C++ sources (#2520)

    • description: The five error helpers all end in RuntimeError and the helper a check is written with says nothing about what the check means - the same macro states a user index mistake in one place and an Exudyn invariant in the next. Before any type can be assigned the 2064 call sites have to be sorted by WHO the message is for. revision2026 step R6.3.2.

    • notes: tools/errorTriage.py sorts the 2064 live call sites by audience (1082 user, 793 internal, 189 to be read) and by kind. Three findings: the inventory of fact 30 counted 188 commented-out lines, not implemented is 94 sites and earns its own class, and src/Objects is 43 percent user-facing, which the step had assumed internal. No helper is one thing - CHECKandTHROW is 27 percent user-facing and SysError has 10 user sites - so the type belongs at the call site, not on the helper. revision2026 step R6.3.2.

    • date resolved: 2026-09-18 15:47, date raised: 2026-09-18

  • 1.11.179 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG issue types and statuses are three lists that disagree (#2519)

    • description: trackerlog.txt and issueTracker.py each carry a comment listing the issue types and statuses, neither matches the other and neither matches what is in the file: 39 distinct type spellings in 2519 issues, 20 of them typos or singletons, NEW FEATURE and EXTENSION for the same thing, NEW TEST written as TESTING. The statuses WORK and TESTING were never used once, ABANDONED is missing. Nothing validates the value on RaiseIssue. revision2026 step R8.7.

    • notes: issueTypes and issueStatuses in issueTracker.py are now the only list, the trackerlog.txt header is written from them and RaiseIssue rejects an unknown type. 39 spellings became 10 types (IMPROVEMENT is new, NEW FEATURE merged into EXTENSION, DISCUSSION into IDEA), 277 type changes. WORK and TESTING left the status list (never used once), ABANDONED joined it with AbandonIssue() and a mandatory reason, 15 issues migrated. Both the version counter and the release-note version index count CLOSED issues, so version.txt stayed at 1.11.178 and no historical version line changed. revision2026 step R8.7.

    • date resolved: 2026-09-18 15:40, date raised: 2026-09-18

  • 1.11.178 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG exudev build refuses –env (#2518)

    • description: exudev build –env NAME exits with an error because the wheel to install is selected by its cp3xx tag and the environment NAME does not say which Python it has. The environment itself does say: ask its interpreter. Maintainer request 2026-09-18: venvExuP313 should be usable for building. revision2026 step R5.18.6.

    • notes: runner.PythonTagOfEnvironment asks the environment interpreter for sys.version_info and caches it, build accepts –env. Under –dry-run the question is not asked either, so the tag is resolved at run time. revision2026 step R5.18.6.

    • date resolved: 2026-09-18 15:27, date raised: 2026-09-18

  • 1.11.177 CHANGE HIGH raised by: Claude-JG resolved by: Claude-JG add Exudyn exception classes to the Python module (#2516)

    • description: Exudyn raises RuntimeError for everything from C++, a user cannot tell a solver divergence from an illegal setting from an Exudyn bug without matching on message text. Add ExudynError and its subclasses, each derives additionally from the built-in that fits. revision2026 step R6.3.1.

    • notes: nine exception classes registered on the exudyn module, each derives from ExudynError and from the built-in that fits (tuple base). One call site converted to prove that a C++ throw keeps its type - which found a third instance of the flattening trap of #2432, pass-through added in all six places. Tested by python/testing/test_exceptions.py. revision2026 step R6.3.1.

    • date resolved: 2026-09-18 15:03, date raised: 2026-09-18

  • 1.11.176 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG stub gate fails on a wheel without the fast module (#2515)

    • description: checkPython.py –stubs –check reports ‘unused allowlist entry exudyn.exudynCPPfast’ as an error when the installed wheel was built without the fast module (the default of exudev build; revision2026 step R5.18). Nothing is wrong with the stubs. revision2026 step R5.5.7.

    • notes: stubtest no longer judges unused allowlist entries; the generated backlog is compared against a –generate-allowlist run instead - a new entry fails the gate, a stale one is reported. revision2026 step R5.5.7.

    • date resolved: 2026-09-18 14:49, date raised: 2026-09-18

  • 1.11.175 CHANGE raised by: Claude-JG resolved by: Claude-JG parameter conversion errors raise inconsistent exception types (#2432)

    • description: Recorded by parameterConversionTest.py: a wrong value for an item or structure parameter raises RuntimeError (PyError after a C++ check or a pybind11 cast_error) - TypeError (pybind11 signature mismatch) or ValueError (Python checks) depending on the path; 34c4/34c5 moved most paths to RuntimeError. Maintainer decision 2026-09-15: exception types shall be corrected throughout the revision at an appropriate step - e.g. TypeError for a wrong type (str - list - None - item index into a scalar) and ValueError for a range violation or a wrong size - raised from PyConversion.h and PyError variants; reference update of parameterConversionTest.py. revision2026 step R6.7.

    • notes: A parameter error now raises TypeError when the object cannot be that parameter at all (None; a string for a number; a list for a scalar; an item index of the wrong kind) and ValueError when the kind is right and the value is not (out of range; wrong size; a must-be-given placeholder). Three mechanisms had to change: PyError takes a PyErrorType and throws py::type_error or py::value_error (default unchanged; so the other 577 call sites are untouched); all 20 PyError sites in PyConversion.h name their type (12/8); and the casts that see user input go through Conversion::CastOrRaise; which turns a pybind11 cast_error - the third path this issue names - into a TypeError naming the parameter. Two layers flattened the type back to RuntimeError and had to be found: EXUexception is a define for std::runtime_error (ReleaseAssert.h:30) and py::builtin_exception derives from it; so catch(EXUexception) in the five AddX wrappers and in GenericExceptionHandling caught the new types first - a pass-through now comes before it. Two defects surfaced: three messages built their text with py::cast<std::string>(value); which throws for exactly the values that reach that line; and a 0-d numpy array (what an itemInterface class makes of a scalar in a vector parameter) fails the cast as a Python error; not a cast_error - which is why the class and dict paths disagreed. Recorded in parameterConversionTestReference.txt: of 966 rows every changed outcome is RuntimeError to TypeError (6898) or to ValueError (785); nothing moved the other way and no successful conversion changed. The MESSAGE is deliberately unchanged and belongs to revision2026 step R6.3.

    • date resolved: 2026-09-18 12:50, date raised: 2026-09-15

  • 1.11.174 BUG HIGH raised by: Claude-JG resolved by: Claude-JG checkExtras does not know python/testing (#2514)

    • description: After revision2026 step R3.9 the runners live in python/testing/ and are no longer siblings of the models. checkExtras.LocalModuleNames() only knows the shipped packages and the siblings of the scanned directory; so modelUnitTests and testRunnerTools were reported as UNCOVERED IMPORTS needed by [tests] - although they are project files and not packages at all. revision2026 step R3.9.1.

    • notes: LocalModuleNames() also counts the tracked .py of python/testing/ as local names for every scanned directory; because every runner puts that directory on sys.path before it executes a model (testRunnerTools.WorkInModelsDirectory). Verified: checkExtras –check green again; the four UNCOVERED IMPORTS were modelUnitTests and testRunnerTools; imported by name from TestModels/; PerformanceModels/ and MiniExamples/.

    • date resolved: 2026-09-18 12:47, date raised: 2026-09-18

  • 1.11.173 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG TestModels holds models only (#2513)

    • description: The runners and helpers move to python/testing/; the performance models to python/PerformanceModels/ and the generated MiniExamples to python/MiniExamples/; so that python/TestModels/ holds test models only. This removes NotTestModels() - the hard-coded list of non-test files the coverage check of revision2026 step R5.9 needed - and gives the performance suite its own coverage check. The dual-use model generalContactSpheresTest.py is split into two copies without isPerformanceTest switching. revision2026 step R3.9.

    • notes: python/TestModels/ now holds 127 test models and testData/ only; the 8 runners are in python/testing/; the 7 performance models in python/PerformanceModels/ and the 24 generated mini examples in python/MiniExamples/. NotTestModels() is deleted and CheckTestCoverage() lost its notTestModels parameter; the performance suite gained the same coverage check over its own directory; folded into its exit code. No model changed for path reasons: each runner changes into the directory of the models it drives (testRunnerTools.WorkInModelsDirectory); the pattern test_testModels.py already used; so relative paths inside the models resolve as before and the caller working directory no longer matters. The two worker bootstraps now put python/testing/ on sys.path and RunModelInProcess strips a leading ../ from the output directory name. generalContactSpheresTest.py was split into a test copy and PerformanceModels/generalContactSpheresPerf.py with isPerformanceTest removed everywhere; no reference value moved; which is the check that the split was correct. perfObjectFFRFreducedOrder.py reads the shared rotor mesh as ../TestModels/testData/rotorDiscTest rather than a copy. Verified: full suite; performance suite 7 files / 13 single runs; 171 examples; pytest 137 passed; all generator and static checks; sphinx under -W.

    • date resolved: 2026-09-18 11:00, date raised: 2026-09-18

  • 1.11.172 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG logs consolidated into python/logs/ (#2512)

    • description: The four log directories python/TestSuiteLogs/; python/TestExamplesLogs/; python/PerformanceLogs/ and python/logsTmp/ are consolidated into python/logs/ with one subdirectory per kind (testmodels; examples; performance) and a shared tmp/. revision2026 step R3.8.

    • notes: The four log directories became python/logs/{testmodels; examples; performance; tmp}. 62 tracked logs moved with git mv so history follows them; decision D7 unchanged - they stay tracked. Four logFileName expressions and testRunnerTools.tmpLogDir updated. The -local CI copy still goes to the working directory python/TestModels/; so both artifact globs stayed correct and no workflow file was touched. Verified: ResolveLogFile found the existing performance log under ../logs/performance/ and diverted to ../logs/tmp/.

    • date resolved: 2026-09-18 11:00, date raised: 2026-09-18

  • 1.11.171 DOCU LOW raised by: Claude-JG resolved by: Claude-JG a test model page is in no toctree (#2505)

    • description: The sphinx build prints “docs/RST/TestModels/sphereTriangleTest.rst: WARNING: document is not included in any toctree”. The page is generated but unreachable from the documentation; a reader can only find it by searching. Noticed 2026-09-18 while running the documentation through the new exudev driver (revision2026 step R5.18); the build itself is not run with -W; so this does not fail anything today. Belongs to revision2026 phase R7.

    • notes: Fixed in revision2026 step R7.1.2: docs/RST/TestModels/sphereTriangleTest.rst was a STALE generated file; not a missing index entry. TestModelsIndex.rst is generated from the keys of TestExamplesReferenceSolution(); and sphereTriangleTest.py moved into DeliberatelyNotRun() (unstable explicit integrator; phase R10); so the generator stopped listing it and stopped writing its page - the old page stayed behind. Verified by deleting it and re-running the generators: it is not recreated. sphinx-build -W –keep-going now succeeds; and exudev docs is strict by default so the local build applies the same gate as the GitLab docs job.

    • date resolved: 2026-09-18 09:13, date raised: 2026-09-18

  • 1.11.170 TESTING NORMAL raised by: Claude-JG resolved by: Claude-JG data files referenced by examples and test models are not in the repository (#2510)

    • description: Inventory taken 2026-09-18 (revision2026 step R5.18.2). (1) docs/verification/ does not exist and was NEVER committed - git log shows no commit touching it - although four test models read from it: sliderCrank3Dtest.py and sliderCrank3Dbenchmark.py want Slidercrank3DiftommBenchmark/ (the Masarati; Masoudi; Chaojie; KarthikBushan; PingZhou and Gonzalez comparison solutions) and heavyTop.py and explicitLieGroupIntegratorPythonTest.py want HeavyTopSolution/HeavyTop_TimeEulerParameter_RK4.txt and HeavyTopSolution/HeavyTop_TimeBodyAngularVelocity_RK4.txt. Those reads sit inside “if useGraphics” blocks; so the suite passes without them and only the comparison plots are lost - which is why nobody noticed. (2) python/Examples/testData/objImportTest.obj is missing; it is the only thing stopping pymeshlabFileImport.py. (3) python/TestModels/testData/gyro.stl is missing; needed by netgenSTLtest.py. NOT missing and NOT to be restored: humanRobotInteraction.py and the ROS and URDF examples read files the repository never contained by design (GrabCAD download; a ROS installation). The maintainer has the files in the old repository.

    • notes: Resolved in revision2026 step R5.18.4: the maintainer copied the old folders back and this step kept what is referenced. docs/verification: 8 of 19 files are referenced and are now tracked (the six IFTOMM slider-crank comparison solutions and the two heavy-top RK4 solutions); the other 11 went to the gitignored tmp/verification/ rather than being deleted; because two of them are the Matlab generators of the kept reference solutions and that is provenance. gyro.stl is tracked and netgenSTLtest.py now asks for ../Examples/testData/gyro.stl; which resolves from the example directory AND from the runner working directory. The five ROS supplementary files are tracked in python/Examples/testData/ROS/ and the example headers point there instead of at the vanished Examples/supplementary. Verified by running sliderCrank3Dbenchmark.py and heavyTop.py with useGraphics on: both read their comparison data and finish. Successor for the ROS state: #2511.

    • date resolved: 2026-09-18 08:33, date raised: 2026-09-18

  • 1.11.169 TESTING HIGH raised by: Claude-JG resolved by: Claude-JG symbolicModuleTest compares scalars with exact equality (#2509)

    • description: Successor of #2501; which fixed the VECTOR/matrix comparison. The SCALAR loop a few hundred lines above still used “if res[0] != res[1]” - exact equality between two independent implementations of a transcendental function; the symbolic module’s and Python’s. That holds only by luck; and the luck ran out with numpy 2.5.3: acosh(2) comes out 1 ulp apart (1.3169578969248166 against …68); counted twice; so the model returned 2.948 against a reference of 0.948 and the suite failed with error 2.0 - exactly the symptom of #2501 in a different branch of the same file. Found 2026-09-18 by a Linux run in WSL under numpy 2.5.3; which is also what the GitLab manylinux job uses. Fixed in revision2026 step R5.9.3 with the same relative tolerance.

    • notes: Fixed in revision2026 step R5.9.3: the SCALAR comparison of symbolicModuleTest.py now uses the same relative tolerance as the vector one; instead of exact equality between two independent implementations of a transcendental function. Found by running the suite on Linux in WSL before restarting the GitLab pipeline - numpy 2.5.3 is what the manylinux job uses; and acosh(2) differs by one ulp there. Verified under numpy 2.2.4; 2.4.6 and 2.5.3: all three return the committed reference 0.9484129575069745 exactly; and a mutation of 1e-12 relative still flags 498 of the about 796 comparisons.

    • date resolved: 2026-09-18 08:15, date raised: 2026-09-18

  • 1.11.168 TESTING NORMAL raised by: Claude-JG resolved by: Claude-JG three examples FAIL for a missing optional package instead of being skipped (#2507)

    • description: ExampleSkipReason() in testRunnerTools.py skips an example that cannot run - it already does so for stable-baselines3; rospy and a MATLAB TCPIP peer. Three examples are not covered and are reported as FAILURES instead: humanRobotInteraction.py and stlFileImport.py need numpy-stl (“No module named ,stl,”) and pymeshlabFileImport.py needs pymeshlab. Measured 2026-09-18; they are 3 of the 5 entries now in KnownExampleFailures() (revision2026 step R5.18.1). The decision this needs is not obvious and is why it is an issue rather than three lines: a machine that HAS the package should run them - so the right fix is probably to TRY the import rather than to list file names; and then numpy-stl and pymeshlab belong in the [all] extra of pyproject.toml so that a developer environment has them. The other two entries of the list are unrelated: NGsolveGeometry.py fails inside the geometry construction under exec(…) and rendererNOGLFWexample.py expects the renderer to be absent in a way the runner does not produce.

    • notes: Fixed in revision2026 step R5.18.2 as the maintainer asked: testRunnerTools probes the optional packages once with importlib.util.find_spec - which does not execute them - and reads each example’s imports from its SYNTAX TREE; so an example is skipped where a package it needs is missing and RUNS where it is installed; instead of being decided by a list of file names. Deciding by availability corrected the diagnoses: pymeshlabFileImport.py was not a pymeshlab failure but a missing data file (objImportTest.obj; supplied by the maintainer the same day); it now runs and passes where pymeshlab exists - through indirectPackageNeeds; because exudyn imports pymeshlab lazily inside graphics.FromPyMeshlabFile() and the example never names it. humanRobotInteraction.py reads STL files from an absolute path on the author machine and says itself they come from GrabCAD; stlFileImport.py reads a file it only writes when its if-False branch is switched on. KnownExampleFailures() is down from five entries to two. Measured with a current venvP312: 171 examples; 27 skipped; 2 known failures; exit code 0.

    • date resolved: 2026-09-18 08:15, date raised: 2026-09-18

  • 1.11.167 BUG raised by: Claude-JG resolved by: Claude-JG the two GitHub workflows pin different action versions (#2463)

    • description: .github/workflows/wheels.yml uses actions/setup-python@v6, while documentation.yaml still uses actions/checkout@v3 and actions/setup-python@v4. Found in revision2026 step R5.14; assigned to sub-step R5.14.1, which needs maintainer approval because it touches .github/workflows.

    • notes: Fixed in revision2026 step R5.14.1; approved by the maintainer 2026-09-18: documentation.yaml now uses actions/checkout@v6 and actions/setup-python@v6; the same majors as wheels.yml; and the file states why the actions are pinned at all (an unpinned action follows its default branch) and why the MAJOR is what matters (GitHub deprecates whole majors with their Node runtime; so one that falls behind stops running altogether). JamesIves/github-pages-deploy-action@v4 is left as is - third-party and already its current major - and runs-on stays ubuntu-latest here while wheels.yml pins its images; both with the reason written in the file. Not verifiable during the freeze: GitHub Actions only fire on pushes to master and on pull requests; both files were checked to parse and the first real run comes when GitHub is live again.

    • date resolved: 2026-09-18 07:58, date raised: 2026-09-16

  • 1.11.166 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG CompositionRuleForRotationVectors returns 2pi instead of 0 for opposite half-turns (#2494)

    • description: Composing the rotation vector pi*n with itself gives a vector of norm 2*pi instead of the zero vector. Both describe the identity rotation - ExpSO3 of the result IS the identity - but 2*pi is outside the principal range and is exactly where the tangent operator is singular: TExpSO3Inv at that vector returns entries of order 1e15. A time integration that composes into that point therefore continues with a meaningless T matrix. Found by TEST 2 of TestModels/LieGroupIntegrationUnitTests.py; which compares against Matlab results that give 0; the other nine tests of that file pass. revision2026 step R5.12.1

    • notes: Settled in revision2026 step R5.12.1 by the maintainer’s decision: the composition rule does NOT map into the principal range; the result may have a norm up to 2*pi; and that is accepted rather than changed. It always describes the correct rotation - ExpSO3 of it is the intended matrix - so the formulas take such noise and pass it on instead of snapping to a boundary; which keeps every existing result unchanged; and a caller needing the principal range maps it (for w > pi use 2*pi - w about the negated axis). The C++ EXUlie::CompositionRotationVector was checked as asked and is the SAME formula returning the same 2*pi; so this was never a port that drifted. Both the Python docstring and the C++ comment now state it and name each other. One real defect was found and fixed on the way: the Python lacked the fabs() guard the C++ has; so it RAISED ValueError: math domain error for exactly this case. LieGroupIntegrationUnitTests.py now passes 10 of 10; TEST 2 checks that the composition is the identity rotation instead of comparing against the Matlab principal-range value.

    • date resolved: 2026-09-18 07:54, date raised: 2026-09-17

  • 1.11.165 TESTING HIGH raised by: Claude-JG resolved by: Claude-JG sliderCrank3Dbenchmark result depends on the numpy version (#2502)

    • description: Measured 2026-09-18: with the SAME exudyn binary (exudynCPP.cp313-win_amd64.pyd md5 identical in both environments); the same source; the same machine and the same Python 3.13.15; the model returns 7.256859912845965 under numpy 2.4.6 - exactly the committed reference - and 7.256859914829453 under numpy 2.2.4; relative 2.7e-10. The suite tolerance is 5e-14; so the test FAILS wherever numpy is older; which is what the maintainer sees in venvP313. numpy enters through the model setup only; so a last-bit difference in the input data is amplified by the solver to 2.7e-10. The same model is already listed in UnresolvedOnLinux() with rel. 2.0e-10; which now looks like the same effect rather than a platform difference. Open questions: which numpy operation in the setup differs; whether other entries of UnresolvedOnLinux() are really numpy-version effects; and whether the suite should pin a minimum numpy for reference comparison or mark the model sensitive. revision2026 phase R10.

    • notes: Fixed in revision2026 step R5.9.2 by the maintainer’s option 1: the 22 products in the Create*Joint helpers of mainSystemExtensions.py now go through two private written-out helpers _MatVec3 and _MatMul3x3; whose summation order is fixed by the source instead of by whichever kernel numpy picks. Root cause was NOT the model or the solver: the whole assembled system was bit-identical under numpy 2.2.4 and 2.4.6; only two marker localPosition values differed; and those come from A0.T @ (pJoint - p0). numpy 2.4.6 returns -2.9e-19 where 2.2.4 and an explicit sum return exactly 0.0; proved by running the model on ONE interpreter with the other numpy on PYTHONPATH. After the fix the marker positions and the model result are bit-identical under both numpy versions (7.256859914829453); exactly one reference value moved plus its AVX2 counterpart (7.256859912756364); and venvP313 - which failed two models - now passes the whole suite with both the regular and the fast module. The pattern remains in about eighty other places where nothing measured makes it matter; recorded as fact 28.

    • date resolved: 2026-09-18 07:50, date raised: 2026-09-18

  • 1.11.164 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG runTestExamples and runPerformanceTests have no –exit-code (#2504)

    • description: runTestSuite.py exits non-zero with –exit-code (and 0 without it); the other two runners have no such flag and ALWAYS return 0; however many examples or performance tests failed. Anything calling them - the exudev driver of revision2026 step R5.18; a CI job; a shell script - therefore cannot see a failure from the exit code and has to read the summary line out of the log instead; which is what tools/exudev/results.py does today. That scan cannot distinguish a run that died before writing its summary from a log it did not find; so it reports “unknown”. Give both runners the same –exit-code flag runTestSuite.py has (about 10 lines each; the pattern already exists); then delete tools/exudev/results.py and let every step of the driver be judged by its exit code. revision2026 step R5.18.1

    • notes: Fixed in revision2026 step R5.18.1: runTestExamples.py and runPerformanceTests.py both take –exit-code and return non-zero on a failure; tools/exudev/results.py - the log scan that existed only because they could not - is deleted; and the exudev driver passes the flag always. The examples needed an exclusion list first; testRunnerTools.KnownExampleFailures(); or the exit code would have been red on every run; it also reports dead exclusions so the list shrinks. Successor for the three entries that are really missing optional packages: #2507.

    • date resolved: 2026-09-18 07:10, date raised: 2026-09-18

  • 1.11.163 TESTING HIGH raised by: Claude-JG resolved by: Claude-JG symbolicModuleTest counts 2 wrong results with numpy 2.2 (#2501)

    • description: The vector/matrix section compares the symbolic result against the numpy result with an ABSOLUTE tolerance: np.linalg.norm(res[0]-res[1]) > 1e-15. One of the compared values has magnitude 9.7476; where 1 ulp is 1.8e-15; so the tolerance is below the representable resolution. Measured 2026-09-18 on one machine with the SAME exudyn binary (md5 identical in both environments) and the same source: numpy 2.4.6 gives 9.7476 on both sides and the test passes; numpy 2.2.4 gives 9.747600000000002 on the numpy side; a difference of 1.78e-15; counted once per recording mode. cntWrong is added to the test result since #2479; so the model reports 2.948412957506974 against a reference of 0.9484129575069745 and the suite FAILS with error 2.0. The comparison needs a relative tolerance.

    • notes: Fixed in revision2026 step R5.9.1: the vector/matrix comparison in symbolicModuleTest.py is now RELATIVE to the magnitude being compared - scale = max(norm(sym); norm(py); 1.) and a tolerance of 1e-14*scale - instead of an absolute 1e-15 on a value of magnitude 9.7476; where one ulp is 1.8e-15. Verified: the model returns exactly the committed reference 0.9484129575069745 in both venvP313 (numpy 2.2.4) and venvExuP313 (numpy 2.4.6); and a mutation making one symbolic result wrong by 1e-12 relative is still caught twice; so the test is not weakened in any way that matters.

    • date resolved: 2026-09-18 07:10, date raised: 2026-09-18

  • 1.11.162 BUG HIGH raised by: Claude-JG resolved by: Claude-JG RaytracingSettings::maxNThreads has no definition (#2506)

    • description: src/Graphics/Raytracing.h:136 declares “static const Index maxNThreads = 256;” with an in-class initializer but no out-of-class definition. Raytracing.cpp:913 passes it to EXUstd::Clamp(const T& x; const T& lower; const T& upper); binding a reference to it - which is an odr-use; so a definition IS required. At -O3 the compiler folds the constant and nothing is referenced; so every release build links and loads. At -O1 it does not fold; the symbol stays undefined and importing the module fails outright with “undefined symbol: _ZN18RaytracingSettings11maxNThreadsE”. Found 2026-09-18 on the FIRST build of revision2026 step R5.6 (sanitizers; which use -O1); before a single sanitizer check had run. The neighbouring materialOffset is already “static constexpr”; which in C++17 is implicitly inline and needs no definition; RTcolorDepth on the next line has the same latent pattern. Fix: make them constexpr.

    • notes: Fixed in revision2026 step R5.6: src/Graphics/Raytracing.h:136 - maxNThreads and its neighbour RTcolorDepth are now “static constexpr”; which in C++17 is implicitly inline and therefore needs no out-of-class definition; matching materialOffset two lines above. Verified: before the change the -O1 sanitizer build produced a module that failed to import with “undefined symbol: _ZN18RaytracingSettings11maxNThreadsE”; after it the same build imports and the whole test suite runs. The MSVC release build was rebuilt and the test suite passed in venvExuP313 with unchanged values; so nothing about the behaviour moved - at -O3 the constant was folded all along; which is why no Windows or manylinux release ever showed this.

    • date resolved: 2026-09-18 02:47, date raised: 2026-09-18

  • 1.11.161 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG the build and test scripts are 18 batch files without help (#2503)

    • description: tools/buildAndGenerate/ holds 18 files; 5 of which exist only to find conda and to loop over the Python versions. A .bat file cannot print a –help; cannot validate an option and cannot pass an unknown option on: every new runner option has to be threaded through by hand - which is how –fast-module stayed unreachable from runTestSuite.bat until #2500. The scripts are also the place where the maintainer looks up HOW the build works; so they carry a documentation duty that comment headers serve badly. Replace them with one Python driver with subcommands; a –help per subcommand and a –dry-run that prints the commands instead of running them; keeping only the scripts that must stay shell (manylinuxBuild.sh runs inside the docker image). revision2026 step R5.18

    • notes: Resolved by revision2026 step R5.18: tools/exudev/ - a dependency-free Python driver run as “python tools/exudev” or “exudev” from the repository root - replaces the 16 batch files of tools/buildAndGenerate/; which is retired (manylinuxBuild.sh moved to tools/ci/ next to the buildManylinux.sh it calls; the rest moved to the gitignored tmp/oldScripts/). Ten commands with a –help each; quiet by default with -v/–verbose; -n/–dry-run prints the real command lines and is faithful by construction because commands.py only builds Step objects and runner.RunSteps is the only executor. Environment dispatch through “conda run -n <env> –no-capture-output”. –fast is opt-in and the driver therefore switches the pyproject default off; it warns about the two gates in setup.py that would silently drop the fast module. Successor for the two runners without an exit code: #2504.

    • date resolved: 2026-09-18 01:53, date raised: 2026-09-18

  • 1.11.160 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG the suite log is split in two when EXUDYN_OUTPUTDIRECTORY is set (#2500)

    • description: runTestSuite.py opens its log with exu.SetWriteToFile; which the C++ side resolves against exudyn.config.outputDirectory (#2418); so with EXUDYN_OUTPUTDIRECTORY set the log is written outside the working tree - as intended. But after the models the suite resets outputDirectory to the empty string and RE-OPENS the same log by name for the summary; which then lands at the UNREDIRECTED path: the body of the log goes to the output directory and the summary to python/TestSuiteLogs. Measured 2026-09-17: 80 KB outside and a 17 KB summary-only file inside. The -local copy reads the unredirected name as well. The reset should restore the directory the run STARTED with; not the empty string. revision2026 step R5.13.5

    • notes: runTestSuite.py remembers the output directory the run started with and puts it BACK after the models instead of clearing it; so both opens of the log resolve to the same file; the -local copy reads through the same resolution; and the directory is cleared only after the file is closed - which is what the original reset was for. Verified 2026-09-17 with EXUDYN_OUTPUTDIRECTORY set: nothing is written into python/TestSuiteLogs (43 files before and after) and the one log outside the tree is complete including the summary; a run without the variable behaves exactly as before. revision2026 step R5.13.5

    • date resolved: 2026-09-17 23:49, date raised: 2026-09-17

  • 1.11.159 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG the platform string does not name the architecture (#2499)

    • description: exudyn.config.Version(addDetails=True) reported -Windows-; -MacOS- or -MacOS(ARM)-; so an Intel Mac and an Apple silicon Mac were indistinguishable and 32 vs 64 bit was visible on Windows only; as -(32bit)-. The string is written into the header of every solution file; sensor file; parameter variation and optimization results file; so it is what a user sends with a bug report. It now names the architecture the way the wheel tags and the compilers do: Windows x86_64; MacOS arm64; MacOS x86_64; Linux x86_64; Linux arm64 - and x86 or arm for the 32 bit cases. Also documents why macOS builds no fast module. revision2026 step R2.10.5

    • notes: GetPlatformString() now appends the architecture as the wheel tags and the compilers name it: Windows x86_64; MacOS arm64; MacOS x86_64; Linux x86_64; Linux arm64; and x86 or arm for the 32 bit cases - which also replaces the Windows-only (32bit) marker; since x86_64 and arm64 already say 64 bit. An architecture matching none of them stays unnamed rather than mislabelled. Decided per compile; so each slice of a macOS universal2 binary reports its own. Verified without building Exudyn: the branch selection with the real preprocessor for seven architectures; and the function itself extracted; compiled and run. The change takes effect at the next C++ build. The header text of solution; sensor; parameter variation and optimization files changes with it; the two documented sample headers were updated. Nothing parses the string except the AVX2 and [FAST] checks of the test runner. revision2026 step R2.10.5

    • date resolved: 2026-09-17 23:28, date raised: 2026-09-17

  • 1.11.158 BUG raised by: Claude-JG resolved by: Claude-JG ObjectANCFThinPlate added with its defaults fails inside C++ with an index error (#2430)

    • description: Found in revision2026 step R4.4.3.4e: mbs.AddObject(ObjectANCFThinPlate()) raises ResizableArray<T>::operator[] i < 0 from C++ even with exudyn.special.exceptions.parameterRangeChecks = False; its default nodeNumbers (four InvalidIndex) are used while the object is added. Every other item class either adds with its defaults or names the parameter that must be given. Expected: a message that names ObjectANCFThinPlate.nodeNumbers - or CheckPreAssembleConsistency catching it - and no index access with invalid node numbers during Add. revision2026 step R10.4.

    • notes: Verified 2026-09-17 on 1.11.135.dev1: mbs.AddObject(ObjectANCFThinPlate()) no longer raises from C++; it adds with its defaults exactly as ObjectMassPoint and ObjectANCFCable2D do; which is the “expected” behaviour this issue names. Fixed on the way by the item-interface work of revision2026 step R4.4.3.

    • date resolved: 2026-09-17 22:43, date raised: 2026-09-15

  • 1.11.157 DOCU raised by: Claude-JG resolved by: Claude-JG Google style docstrings are mandatory project wide (#2412)

    • description: The convention is nowhere stated; the revision plan even said NumPy style. Decision: Google style docstrings MUST be used throughout for consistency. The rule has to be written into docs/dev/CODING_STYLE.md; CONTRIBUTING.md and CLAUDE.md; and mentioned early in the user documentation so contributors meet it before writing code. griffe and pydoclint both parse Google style; so the planned docstring toolchain (revision2026 steps R4.6-R4.9) is unaffected apart from a parser argument.

    • notes: Resolved by revision2026 step R4.6: docs/dev/CODING_STYLE.md states Google style as the convention for python/exudyn - summary; then Args:; Returns:; Note:; Example: - and pydoclint checks it in CI against tools/ci/pydoclintBaseline.txt. The #** doc-comment convention it replaced is marked as removed in the same table.

    • date resolved: 2026-09-17 22:43, date raised: 2026-09-13

  • 1.11.156 EXTENSION resolved by: Claude-JG itemInterface (#2344)

    • description: add automated test for all items and parameters with dummy class type which always fails. Use objectDefinition database to independently check if all parameters raise exceptions with according strings in it

    • notes: Resolved by revision2026 step R4.4.3.1: parameterConversionTest.py walks the definitions database and writes a fixed set of probe values into every parameter of every item and of the simulation and visualization settings; through each access path; recording the exception type or the type; shape and value that reads back. That is the independent check this issue asked for; it currently pins 89 rejected-input outcomes.

    • date resolved: 2026-09-17 22:43, date raised: 2026-04-17

  • 1.11.155 EXTENSION resolved by: Claude-JG itemInterface (#2343)

    • description: add safe parameter conversion for all data types in item initialization; add parameter checks like UReal, PInt, etc. into C++ code; exception shall always return causing ItemClass name and parameter name

    • notes: Largely resolved by revision2026 step R4.4.3 and its sub-steps: the item interface converts and checks parameters of every type; a rejected value names the item class and the parameter - for instance “ObjectGenericODE2: invalid node number detected” - and the whole behaviour is recorded by parameterConversionTest.py against a committed reference. What is NOT uniform yet is the exception TYPE per kind of error; which is #2432 and revision2026 step R6.7.

    • date resolved: 2026-09-17 22:43, date raised: 2026-04-17

  • 1.11.154 CHECK resolved by: Claude-JG itemInterface (#2333)

    • description: consider advanced checks, in particular for int / float-convertable types in checks like CheckForValidUReal

    • notes: Same as #2332: the int/float-convertible cases of CheckForValidUReal and its siblings are probed by parameterConversionTest.py (revision2026 step R4.4.3.1) and their outcome is recorded; the open decision about which exception type each path should raise is #2432 and revision2026 step R6.7.

    • date resolved: 2026-09-17 22:43, date raised: 2026-04-02

  • 1.11.153 CHECK resolved by: Claude-JG SetNumpyMatrixSafely (#2332)

    • description: SetNumpyMatrixSafely and SetNumpyVectorSafely: add type checks and check exceptions printed when initialized with wrong types; consider more advanced checks for standard types in itemInterface

    • notes: The behaviour asked about is now pinned rather than guessed: parameterConversionTest.py (revision2026 step R4.4.3.1) writes wrong types into every parameter through every access path - the SetNumpyMatrixSafely and SetNumpyVectorSafely paths included - and compares the exception type or the value that reads back against a committed reference; so a change in these checks cannot pass unnoticed. What to do about the inconsistent exception TYPES is #2432.

    • date resolved: 2026-09-17 22:43, date raised: 2026-04-02

  • 1.11.152 TESTING resolved by: Claude-JG testing checklist (#2298)

    • description: Add testing checklist and guidelines

    • notes: Resolved by revision2026 phase R5 and docs/dev/WORKFLOW.md: the commit tiers and the four gates of section 4 are the checklist this issue asked for - build; regeneration clean; the full test suite; docs and plan updated - together with which tests run when; the pytest collector; the parallel run; and the difference between reproducible and sensitive tests.

    • date resolved: 2026-09-17 22:43, date raised: 2026-02-14

  • 1.11.151 CHANGE resolved by: Claude-JG systemStructures.py (#2240)

    • description: add functions for type conversions C++ - Python (Vector3D, etc.)

    • notes: Resolved by revision2026 step R4.3: the type conversions asked for here are tools/generators/typeModel.py; which renders one type declaration into its C++; stub; documentation and Python forms from a single definition; instead of each emitter spelling out Vector3D and friends for itself.

    • date resolved: 2026-09-17 22:43, date raised: 2026-01-31

  • 1.11.150 CHANGE resolved by: Claude-JG systemStructures.py (#2239)

    • description: transfor into more suitable Python native format

    • notes: Resolved by revision2026 step R4.3: src/pythonGenerator/systemStructures.py is gone; the structures are defined in definitions/structureDefs*.py as plain Python data and the emitters in tools/generators/ produce the C++; the stubs and the documentation from them.

    • date resolved: 2026-09-17 22:43, date raised: 2026-01-31

  • 1.11.149 EXTENSION resolved by: Claude-JG build wheels (#2227)

    • description: add flag to setupPyConfig.json to turn on/off AVX2 and AVX512 compile in windows and linux builds

    • notes: Resolved by revision2026 steps R2.14 and R2.10: the build switches live in [tool.exudyn] of pyproject.toml - useAVX2 and useAVX512 among them - read by setup.py with an environment and a command-line override. setupPyConfig.json; which this issue named; no longer exists: it was tracked AND mutable; so a CI build rewrote it with sed and a failed build left the tree dirty.

    • date resolved: 2026-09-17 22:43, date raised: 2026-01-16

  • 1.11.148 CHANGE resolved by: Claude-JG MainSystemExtensions (#1996)

    • description: expose MainSystem as MainSystemBase into python; derive Python class MainSystem from MainSystemBase in MainSystemExtensions; this should increase visibility of Python code!

    • notes: Resolved differently and the goal is met: instead of exposing MainSystemBase and deriving a Python MainSystem from it; a function is marked where it is defined with @extends(exudyn.MainSystem) and exudyn.extensionRegistry.install() attaches it to the C++ class (revision2026 phase R4). Python-side MainSystem code is therefore visible in the class; in the stub file and in the documentation; without a second class in the hierarchy.

    • date resolved: 2026-09-17 22:43, date raised: 2025-05-06

  • 1.11.146 EXTENSION resolved by: Claude-JG exceptions and ValueError (#1861)

    • description: check all ValueError exceptions and change to appropriate error handling, like importerror, runtime error or value error!

    • notes: Superseded by #2432; which records the same problem with measurements: parameterConversionTest.py shows that a wrong parameter raises RuntimeError; TypeError or ValueError depending on which path rejected it. The taxonomy itself is revision2026 steps R6.3; R6.4 and R6.7. Individual cases found on the way were fixed with the right type - for instance ValueError for an unknown solver in lieGroupIntegration.py and ImportError for a missing roboticstoolbox (#2488; #2489).

    • date resolved: 2026-09-17 22:43, date raised: 2024-09-19

  • 1.11.145 EXTENSION resolved by: Claude-JG item functions checker (#1142)

    • description: add automatic tests for all necessary functions in items, such as nodes, objects, etc.; run tests similar to LEST test suite

    • notes: Partially resolved and the remainder is #2498: the parameters of every item are now probed systematically by parameterConversionTest.py (revision2026 step R4.4.3.1) and the linear algebra classes by the lest unit tests of src/Tests/ (step R5.4); what is still untested per item type is its member FUNCTIONS. See the successor issue.

    • date resolved: 2026-09-17 22:43, date raised: 2022-06-12

  • 1.11.144 BUG HIGH resolved by: Claude-JG GeneralContact (#1085)

    • description: generalContactFrictionTests.py gives considerably different results after t=0.05 seconds between Windows and linux compiled version; may be caused by some initialization problems (bugs…); needs further tests

    • notes: Superseded by the measurement and the machinery of revision2026 steps R2.10.3 and R5.9: the Windows/Linux differences of the contact and friction models are now recorded per model in UnresolvedOnLinux() and SensitiveTests() in runTestSuiteRefSol.py rather than being an open suspicion; and a failure there no longer sets the exit code at random. The remaining question - WHY these models differ - is revision2026 step R10.1; which is the open work.

    • date resolved: 2026-09-17 22:43, date raised: 2022-05-11

  • 1.11.143 EXTENSION resolved by: Claude-JG Vector alignment (#862)

    • description: add 32 or 64 byte memory + length alignment to allocation of vectors in order to be able to always use AVX and/or loop unrolling for copying or manipulating vectors; use _mm_malloc / _mm_free and separate flags to turn on/off memory and length alignment, memory alignment turned off in case that AVX is not available

    • notes: Resolved: src/Linalg/Vector.h allocates through _aligned_malloc on Windows and posix_memalign elsewhere; so vector data is aligned for the AVX paths; and AlignedFree in src/Utilities/BasicDefinitions.h frees it. Revision2026 step R2.10 settled which module carries the vector extensions (only exudynCPPfast) and step R2.10.3 recorded what they change.

    • date resolved: 2026-09-17 22:43, date raised: 2022-01-13

  • 1.11.142 EXTENSION resolved by: Claude-JG AVX objects (#452)

    • description: test AVX objects

    • notes: Same coverage as #451: the AVX code paths are tested by src/Tests/AVXVectorUnitTests.h and their numerical effect is pinned by the second reference set of revision2026 step R2.10.3. A micro-benchmark of the real linear algebra operations is planned as revision2026 step R11.2.

    • date resolved: 2026-09-17 22:43, date raised: 2020-09-16

  • 1.11.141 EXTENSION resolved by: Claude-JG AVX integration (#451)

    • description: test AVX in vector.cpp and dense solver

    • notes: Resolved by src/Tests/AVXVectorUnitTests.h (7 cases covering the AVX paths of the vector classes) together with the measurements of revision2026 steps R2.16 and R2.10.3: the effect of the vector extensions on results is now recorded model by model in AVX2ReferenceSolutionUpdate(); and tools/benchmarks/avx2Benchmark.py measures the solver-level effect.

    • date resolved: 2026-09-17 22:43, date raised: 2020-09-16

  • 1.11.140 BUG resolved by: Claude-JG ObjectGenericODE2 bug (#448)

    • description: ObjectGenericODE2 crashes without message when initialized with invalid node numbers

    • notes: Verified 2026-09-17 to be fixed by the later item-interface work: mbs.AddObject(ObjectGenericODE2(nodeNumbers=[-1,-2])) now prints “ObjectGenericODE2: invalid node number detected; all nodes used in ObjectGenericODE2 must already exist” and raises; instead of crashing without a message. The message names the item class; which is what the issue asked for.

    • date resolved: 2026-09-17 22:43, date raised: 2020-09-09

  • 1.11.139 CHECK resolved by: Claude-JG invalid index test (#323)

    • description: add test which checks that invalidIndex in python (-1) converts to invalidIndex in exudyn (use simple object with node number and check node number after setting object

    • notes: Resolved by revision2026 step R4.4.3.1: parameterConversionTest.py writes a fixed set of probe values - which includes -1 - into every parameter of every item through each access path and compares type; shape and value that read back against a committed reference; index parameters included. The InvalidIndex cases are called out explicitly in that file (#2426).

    • date resolved: 2026-09-17 22:43, date raised: 2020-01-24

  • 1.11.138 CHECK resolved by: Claude-JG Linalg tests (#126)

    • description: Add unit tests for new ConstSizeMatrix and ResizableMatrix

    • notes: Resolved by revision2026 step R5.4.1: src/Tests/AllMatrixVariantsUnitTests.h tests ConstSizeMatrix and ResizableMatrix - the two classes this issue named - including the SparseTripletMatrix constructor fixed in step R5.4.6 (#2476).

    • date resolved: 2026-09-17 22:43, date raised: 2019-05-13

  • 1.11.137 EXTENSION LOW resolved by: Claude-JG finish (#5)

    • description: finish tests for all matrix classes

    • notes: Resolved by the later unit-test work of revision2026 step R5.4: src/Tests/AllMatrixUnitTests.h and AllMatrixVariantsUnitTests.h cover Matrix; ResizableMatrix; ConstSizeMatrix and the linked-data variants; step R5.4.1 completed the variants that had none.

    • date resolved: 2026-09-17 22:43, date raised: 2019-04-01

  • 1.11.136 EXTENSION LOW resolved by: Claude-JG finish (#2)

    • description: finish tests for all vector classes

    • notes: Resolved by the later unit-test work of revision2026 step R5.4: src/Tests/AllVectorUnitTests.h; TemplatedVectorArrayUnitTests.h; AllBasicLinalgUnitTests.h and AVXVectorUnitTests.h cover Vector; ResizableVector; SlimVector; ConstSizeVector and LinkedDataVector; run by exu.special.RunCppUnitTests() in every build with EXUDYN_PERFORM_UNIT_TESTS and by the test suite.

    • date resolved: 2026-09-17 22:43, date raised: 2019-04-01

  • 1.11.135 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG –fast-module would reject a fast module built without AVX2 (#2496)

    • description: The guard and the log marker added for revision2026 step R5.11 asked ModuleUsesAVX2(); but that is a different question from -is this the fast module-. setup.py always compiles exudynCPPfast with __FAST_EXUDYN_LINALG and adds the vector extensions only when useAVX2 is set AND the platform is not macOS - so on macOS; and in any –no-avx2 build; the fast module is perfectly good and reports no AVX2. The run would then abort with the message that the wrong module was loaded; and its log would have no _fast marker. Both now ask ModuleIsRegular(); the AVX2 reference set keeps asking ModuleUsesAVX2(); which is right because that drift comes from the vector extensions and not from the missing range checks. revision2026 step R5.11.2

    • notes: The guard and the log marker now ask ModuleIsRegular() - is this the fast module - instead of ModuleUsesAVX2() - does it have vector extensions. setup.py always compiles exudynCPPfast with __FAST_EXUDYN_LINALG but adds the vector extensions only when useAVX2 is set AND the platform is not macOS; so on macOS and in any –no-avx2 build the fast module reports no AVX2 and the run would have aborted; with its log written under the regular name. Verified by simulating that build: with ModuleUsesAVX2 forced False the guard accepts the fast module. The AVX2 reference set keeps asking ModuleUsesAVX2(); which is the right question there. revision2026 step R5.11.2

    • date resolved: 2026-09-17 22:38, date raised: 2026-09-17

  • 1.11.134 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG the fast module is never exercised by the test suite (#2495)

    • description: Windows release builds ship exudynCPP and exudynCPPfast; but the suite only ever runs whichever one __init__.py selects - the default - so exudynCPPfast ships essentially untested although it is the module used for long simulations and the one whose missing range checks turn a user error into undefined behaviour. The machinery to JUDGE a fast run already exists (ModuleUsesAVX2 and AVX2ReferenceSolutionUpdate from R2.10.3); what is missing is the switch that loads it. revision2026 step R5.11

    • notes: EXUDYN_MODULE=fast is read by __init__.py before the C++ module is imported; and runTestSuite.py and runPerformanceTests.py take –fast-module; which sets it. An environment variable and not a flag because child processes inherit it: –parallel and pytest -n run every model in its own interpreter. The suite then applies the existing AVX2 reference set automatically and writes its log with a _fast suffix; a declined fast request stops the run instead of producing a log that claims the wrong module. Two adaptations were needed and are the value of the step: symbolicModuleTest checked two range-check error paths that exudynCPPfast deliberately does not have; and ANCFbeltDrive needed its AVX2 reference value. runPerformanceTests lost its heuristic of using the fast module iff Python is 3.10. Measured: suite PASSED on both modules (the first fast pass); –parallel –fast-module PASSED; performance 42.13s regular against 33.54s fast. The -noavx part of the step is dropped: step R2.10 removed that module. revision2026 steps R5.11 and R5.11.1

    • date resolved: 2026-09-17 22:19, date raised: 2026-09-17

  • 1.11.133 BUG LOW raised by: Claude-JG resolved by: Claude-JG three imports refer to modules that exist nowhere (#2377)

    • description: found by tools/checkExtras.py (revision2026 step R2.12). Examples/FurtherExamples/spotReinforcementLearning.py does “import RL_Spot” and no such file is in the repository; TestModels/LieGroupIntegrationUnitTests.py does “from timeIntegrationOfRotationVectorFormulas import *” and no such file is in the repository; Examples/ROSMassPoint.py imports rosInterface by bare name although the module is exudyn/robotics/rosInterface.py; so it only works if that directory happens to be on sys.path. All three are currently listed in knownMissingLocalModules in checkExtras.py so the checker reports them as broken imports rather than as packaging gaps

    • notes: rosInterface: ROSMassPoint.py and ROSTurtle.py imported it by bare name; both now import exudyn.robotics.rosInterface as their sibling ROSMobileManipulator.py already did. timeIntegrationOfRotationVectorFormulas: the module was never committed; but both functions it provided exist in the package today - ComposeRotationVectors is now CompositionRuleForRotationVectors; plus Skew; TSO3Inv (TExpSO3Inv) and the two RK step functions; LieGroupIntegrationUnitTests.py imports them and 9 of its 10 tests pass (TEST 2 fails on the separate #2494). Both entries are gone from knownMissingLocalModules in tools/checkExtras.py; which now exits 0. RL_Spot remains: the module was never committed and the decision - delete the example or add the module - is the maintainers. revision2026 step R5.12

    • date resolved: 2026-09-17 21:26, date raised: 2026-09-11

  • 1.11.132 BUG raised by: Claude-JG resolved by: Claude-JG ANCFbeltDrive result contradicts its own recorded reference (#2368)

    • description: Run headless the model yields 0.0 while the reference in the file comment is -0.4842656133238705 (2021-05-07). The model was retuned to a 10s dynamic run (tEnd = 10 ; h = 0.5e-3) and the reference was not updated. Found while triaging the unlisted TestModels for revision2026 step R5.9. Not added to the test suite: adding the measured value would enshrine whatever changed.

    • notes: The maintainer retuned the model on 2026-09-17 (16 elements per section; faster drive; tEnd=0.1 instead of 10) and took the result from the sensor instead of an ODE2 coordinate; measuring a new value in the model file. Finalized here: the model ran with parallel.numberOfThreads=4 and was therefore NOT reproducible - three headless runs spread over 5.4e-14; past the 5e-14 suite tolerance - so it now runs single-threaded; which is bit-identical across runs and at this size also faster (0.36s vs 0.69s). The reference was re-measured single-threaded in the model file and in runTestSuiteRefSol.py; the model left DeliberatelyNotRun and runs in the suite with error 0.0 in 0.35s (it was 28s).

    • date resolved: 2026-09-17 21:26, date raised: 2026-09-11

  • 1.11.131 BUG LOW raised by: Claude-JG resolved by: Claude-JG every Exudyn writer should create its output directory itself (#2493)

    • description: SaveDictToHDF5 fails with FileNotFoundError if the directory does not exist; while FEMinterface.SaveToFile; PlotSensor; PlotImage and the parameter variation results file each carry their own copy of the same try/except os.makedirs block - five copies of four lines. One function CreateDirectoryForFile in basicUtilities replaces them; and SaveDictToHDF5 gets the behaviour it was missing. revision2026 step R5.13.4

    • notes: basicUtilities.CreateDirectoryForFile(fileName) creates the directory of a file that is about to be written and returns the name unchanged; failure is ignored on purpose - creating a directory can fail for reasons that do not stop the write; and the write reports the real problem better. SaveDictToHDF5 now calls it - the behaviour it was missing - and the five hand-written copies in FEM.py (2); plot.py (2) and processing.py now call it instead. Verified: testHDF5loadSave.py writes into a solution/ directory that does not exist yet; without any makedirs in the example. The two examples that needed an os.makedirs line one commit ago no longer do. revision2026 step R5.13.4

    • date resolved: 2026-09-17 20:42, date raised: 2026-09-17

  • 1.11.130 BUG LOW raised by: Claude-JG resolved by: Claude-JG test models write solution files that nothing reads (#2492)

    • description: Fifteen test models set solutionSettings.writeSolutionToFile=True unconditionally; the coordinates solution file is then written on every suite run although it is read back only under useGraphics by the SolutionViewer - and compareFullModifiedNewton is the designated test of the writing itself. Four models already had the right form (writeSolutionToFile=False; True only if useGraphics). revision2026 step R5.13.1

    • notes: Fifteen test models now write the solution file only when it is read: thirteen use writeSolutionToFile=useGraphics - the form four models already had - and ACFtest and doublePendulum2DControl set False; neither has useGraphics in scope at that point and nothing reads the file. The three remaining sensors that still wrote to a file (ANCFbeltDrive twice; ACFtest once) use storeInternal=True; PlotSensor reads the internal data. Measured over a full suite run with the output directory emptied first: 74 -> 64 coordinates solution files and 11 MB -> 8.0 MB. The sensor half of the plan step was already done by R5.13 and R5.13.2: 74 models use storeInternal and almost every sensor fileName in the test models is commented out. revision2026 step R5.13.1

    • date resolved: 2026-09-17 20:29, date raised: 2026-09-17

  • 1.11.129 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG examples write generated FEM data into the tracked testData/ input directory (#2491)

    • description: Twelve examples save meshes and FEM data under testData/ - the directory that holds the tracked INPUT files - so every run of runTestExamples.py leaves untracked netgenBrick.npz; netgenHinge.npz; netgenFFRF2.npz; FMBStest1.npz; modalAnalysisFEM.npz and test.hdf5 in the working tree; where they are easily committed by accident. Output belongs under solution/; which is ignored; through OutputFilePath as the test models already do. revision2026 step R5.13.1

    • notes: Twelve examples now write their generated FEM data through OutputFilePath into solution/ instead of testData/: ten FEMinterface caches; and the two SaveDictToHDF5 sites which also create the directory themselves because SaveDictToHDF5 - unlike FEMinterface.SaveToFile - does not. Verified by running all 171 examples with the artifacts removed first: the same 5 pre-existing failures; no file left in any testData directory; the meshes land in the per-example output directory. A direct user run without an output directory writes into Examples/solution/; which is ignored. revision2026 step R5.13.3

    • date resolved: 2026-09-17 20:23, date raised: 2026-09-17

  • 1.11.128 BUG raised by: Claude-JG resolved by: Claude-JG FEMinterface NPZ files store a C++ enum and cannot be read by a second module (#2471)

    • description: FEMinterface.SaveToFile(mode=NPZ) writes postProcessingModes as a dict whose outputVariableType is an exudyn.exudynCPP.OutputVariableType - a pybind type. np.load(allow_pickle=True) therefore imports exudyn.exudynCPP when reading it, and in a process that already loaded exudynCPPfast this raises ImportError: generic_type: type “Real” is already registered. Measured 2026-09-17 on testData/netgenTestMesh.npz: every other field (nodes, elements, massMatrix, stiffnessMatrix, surface, modeBasis, eigenValues, metaData) loads under both modules; only this one fails. An NPZ is meant to hold plain arrays: store the enum by name and convert back on load. Until then NGsolveCMStest stays in NotJudgedOutsideRegularModule(). revision2026 step R2.10.4.

    • notes: FEMinterface.SaveToFile now stores postProcessingModes[outputVariableType] by NAME - on a copy; so the object in memory keeps its enum - and SetWithDictionary converts the name back on load; files written before this still carry the enum and are loaded as before. Verified across modules: a file written under the regular module is read under exudynCPPfast in both NPZ and PKL form and the enum comes back; writing the enum object directly still reproduces the original ImportError generic_type: type Real is already registered. NGsolveCMStest cannot leave NotJudgedOutsideRegularModule() yet: its tracked testData/netgenTestMesh.pkl was written in the old form and has to be regenerated first. revision2026 step R2.10.4

    • date resolved: 2026-09-17 20:06, date raised: 2026-09-17

  • 1.11.127 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG the stubs miss the deprecated module functions and GetDictionary/SetDictionary (#2490)

    • description: addDocu=False suppressed the .pyi entry as well as the documentation; so all 14 deliberately undocumented module-level functions (StartRenderer; StopRenderer; InfoStat; GetVersionString; SolveStatic; SolveDynamic; …) were missing from python/exudyn/__init__.pyi. GetDictionary and SetDictionary were missing from all 43 settings classes; because structureHeaderEmitter adds them to the pybind class but structureStubEmitter did not mirror them. Both matter as soon as the package ships a PEP 561 py.typed marker: a type checker then reports correct user code as an error. revision2026 steps R5.5.2 and R5.5.4

    • notes: The stub emission no longer depends on addDocu: a function that is deliberately left out of the documentation still exists in the module and is now described in the .pyi (13 functions); StopRenderer was the only declaration without a returnType and got returnType=None (14). structureStubEmitter now mirrors GetDictionary/SetDictionary under the same condition structureHeaderEmitter uses to add them to the pybind class (43 classes). Measured with mypy on a user script that calls StartRenderer; GetDictionary; SetDictionary; SolveDynamic; SetOutputPrecision and StopRenderer: 9 errors with the old stub; none with the new one. py.typed is shipped from now on. revision2026 steps R5.5.2 and R5.5.4

    • date resolved: 2026-09-17 19:52, date raised: 2026-09-17

  • 1.11.126 BUG LOW raised by: Claude-JG resolved by: Claude-JG robotics/future.py uses an undefined name graphics (#2489)

    • description: MakeCorkeRobot-related code in exudyn/robotics/future.py builds graphicsBaseList from graphics.Brick/graphics.Cylinder/graphics.color but nothing imports graphics; the function does four star imports and none of them provides it (verified: exudyn.utilities and exudyn.graphicsDataUtilities have no attribute graphics). The path raises NameError. ruff reports F405 rather than F821 because of the star imports; mypy found it. revision2026 step R5.5.6

    • notes: future.py now imports exudyn.graphics as graphics in its __main__ block; none of the four star imports there provides it (verified). Running the block afterwards showed the same pattern as #2488 one function further: MakeCorkeRobot caught the ImportError of roboticstoolbox; printed and continued; and then returned an undefined robotCorke - it now raises ImportError naming the package to install. revision2026 step R5.5.6

    • date resolved: 2026-09-17 19:52, date raised: 2026-09-17

  • 1.11.125 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG four undefined names raise NameError when their code path is reached (#2488)

    • description: ruff F821 found four names that do not exist where they are used: lieGroupIntegration.py calls exudyn.Print(…) three times although the module imports exudyn as exu; and robotics/roboticsCore.py line 1392 calls SC.renderer.Start() although the class member is self.SC - so InverseKinematicsNumerical with useRenderer=True raises NameError instead of showing the renderer. All four are in error or option paths that no test reaches. revision2026 step R5.5.5

    • notes: lieGroupIntegration.py used exudyn.Print three times although the module imports exudyn as exu; and roboticsCore.py called SC.renderer.Start() where the member is self.SC - so InverseKinematicsNumerical(useRenderer=True) raised NameError instead of showing the renderer. Both fixed. Running the first path afterwards showed a second defect at the same place: after printing the message the function continued and raised UnboundLocalError on ComputeStep; the unknown-solver case now raises ValueError naming the accepted values. revision2026 step R5.5.5

    • date resolved: 2026-09-17 18:43, date raised: 2026-09-17

  • 1.11.124 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG no linter runs over the shipped Python package (#2487)

    • description: python/exudyn is 34000 lines and nothing checks it for undefined names; unused imports or bare except: - the only linter in use is pydoclint; which only judges docstrings. ruff is introduced with an explicitly written rule set (F and E4/E7/E9); the findings present at introduction are tolerated through a baseline and a new finding fails the check. revision2026 step R5.5

    • notes: ruff runs over python/exudyn with the rule set written down in pyproject.toml (F and E4/E7/E9; E701/E702/E703 switched off as house style) and tools/checkPython.py judges it against tools/ci/ruffBaseline.txt: the findings present at introduction are tolerated; a new one fails. 335 findings at introduction; 107 of them fixed outright (52 == None; 11 == True/False; 13 not-in/not-is; 21 unused imports and 3 deliberate re-exports marked noqa; one multi-import line; one empty f-string) leaving 228 in the baseline - bare except:; type() comparisons; star imports and unused variables; each of which needs a judgement rather than a rewrite. revision2026 step R5.5

    • date resolved: 2026-09-17 18:37, date raised: 2026-09-17

  • 1.11.123 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG generated __init__.pyi is not valid Python (#2486)

    • description: The stub file python/exudyn/__init__.pyi does not parse: one documentation line of the OutputVariableType description starts at column 0; createStubFiles.py takes that as the end of the class block and writes the rest of the class body to the top level. All five generated stub fragments parse - only the merged product does not; indenting that line makes the whole file parse. Nothing in the generator checks that the stub it wrote is valid Python. revision2026 step R5.5.1

    • notes: Fixed at the emitter: DocStringGoogleFromPlainText wrote the summary part of a docstring without indentation; a summary ends at the first period-space and therefore may contain line breaks - here the OutputVariableType description. Its continued lines now get the docstring indentation. In addition createStubFiles.py parses both stub files with ast.parse before writing them and refuses to write an invalid stub - verified by mutation: with the emitter fix reverted the generator fails with the file and line. revision2026 step R5.5.1

    • date resolved: 2026-09-17 18:28, date raised: 2026-09-17

  • 1.11.122 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG the C++ usage demo of the symbolic types is a dead function of if(false) blocks (#2485)

    • description: PyTest_unused() at the end of Symbolic.cpp was six if(false)/if(true) blocks in one function, never called, not compiled into anything meaningful and never run. It is the only documentation of how Symbolic::SReal, SymbolicRealVector and SymbolicRealMatrix are used from C++, which is worth keeping (maintainer, 2026-09-17), but not in that shape - and it demonstrates a stack ExpressionNamedReal, which is exactly the heap corruption trap found in step R5.4.2. Reshape into a header that says what it is, with one named function per topic. revision2026 step R5.4.12.

    • notes: PyTest_unused() is removed from Symbolic.cpp and reshaped into src/Linalg/symbolicCppDemo.h: one named function per topic (plain values, named variable, vectors, matrices, Diff, the scalar functions, timing, reference counting) plus SymbolicDemoAll(). The header states in its first lines that it is worked examples to be read, that it is not a test (those are in SymbolicUnitTests.h), and that nothing calls it. It IS included by Symbolic.cpp so that it keeps compiling - inline and unused, so it costs nothing. Two corrections while reshaping: the demo no longer teaches the stack ExpressionNamedReal that causes heap corruption, and it was actually run through a temporary binding - every section produces sensible output, the new/delete counts balance, and the timing section now documents 12 ns per evaluation of a recorded tree against 267 ns when rebuilding it and 2.4 ns without recording. revision2026 step R5.4.12.

    • date resolved: 2026-09-17 17:20, date raised: 2026-09-17

  • 1.11.121 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG document that EigenDense does not detect a singular matrix (#2483)

    • description: CORRECTED 2026-09-17 after maintainer feedback: the behaviour is NOT a defect. The FullPivLU path is entered only with linearSolverSettings.ignoreSingularJacobian=True, which is documented as handling over- and underdetermined systems and resolving redundant constraints (with a warning that it may lead to erroneous results), and the code says so as well: “in this case, we could report errors, but we do not want to”. It also honours pivotThreshold via setThreshold. The PartialPivLU path cannot report invertibility at all - “according to Eigen homepage, there is no possibility to check for invertability” - so it is a property of the library, not a decision of Exudyn. What remains is a documentation gap: LinearSolverType.EigenDense describes partial pivoting as “faster than EXUdense” and mentions full pivot only under ignoreSingularJacobian, but nowhere states that in the DEFAULT EigenDense mode a singular Jacobian is not detected and the solver continues with an undefined result, while EXUdense and EigenSparse do report it. Add one sentence to the enum description. revision2026 step R5.4.10.

    • notes: Documentation only, as corrected by the maintainer: the behaviour is deliberate (FullPivLU is the ignoreSingularJacobian least-squares path; PartialPivLU has no invertibility check in Eigen). The LinearSolverType.EigenDense description in definitions/enumTypes.py now states that in the default partial pivoting mode a singular matrix is NOT detected and the solver continues with an undefined result, and points at EXUdense/EigenSparse if that must be reported or at full pivot if the singular system should be resolved by least squares on purpose. The sentence propagates to EnumTypes.h, the stubs and the documentation. The judging comment in LinearSolverUnitTests.h was corrected as well. revision2026 step R5.4.10.

    • date resolved: 2026-09-17 17:20, date raised: 2026-09-17

  • 1.11.120 BUG raised by: Claude-JG resolved by: Claude-JG the sparse FactorizeNew does not return the causing row it promises (#2482)

    • description: GeneralMatrixEigenSparse::FactorizeNew() takes rv = solver.info() - an Eigen::ComputationInfo, i.e. 0..3 - and then returns rv-1 as if it were a row index (LinearSolver.cpp:528-530), with a comment describing the causing row. In practice a failed factorization gives info()==1 (NumericalIssue), so the caller is told row 0 no matter which row is singular. Either return the real row, or return a documented error code and stop promising a row. The dense EXUdense path does return a real row. revision2026 step R5.4.9.

    • notes: GeneralMatrixEigenSparse::FactorizeNew() now returns NumberOfRows() on failure - the value the caller already treats as “causing row unknown” - instead of solver.info()-1, which was an Eigen ComputationInfo and therefore always 0. The comment that described SuperLU info semantics is replaced by what Eigen actually returns. Measured on a redundantly constrained system with EigenSparse: before, the solver printed “causing system equation number (coordinate number) = 0” and “The causing system equation 0 belongs to a ODE2 coordinate”; after, the singularity is reported with no row claimed. The symmetric branch always behaved this way. The R5.4.3 unit test asserts the exact return value. revision2026 step R5.4.9.

    • date resolved: 2026-09-17 17:20, date raised: 2026-09-17

  • 1.11.119 BUG raised by: Claude-JG resolved by: Claude-JG a symbolic vector product with inconsistent sizes leaks its nodes (#2481)

    • description: Symbolic::operator*(SymbolicRealVector, SymbolicRealVector) allocates the product node and then hands it to SReal(ExpressionBase*), whose constructor evaluates it immediately to cache the value. With inconsistent sizes that evaluation throws - before any SReal owns the node - so the allocation is never freed. Measured from Python: one failed product leaks 1 Real node and 2 Vector nodes (newCount increases, deleteCount does not). Any error path inside Evaluate has the same shape. revision2026 step R5.4.8.

    • notes: SReal(ExpressionBase*) now takes ownership first and evaluates in the constructor body, with a catch(…) that releases the tree exactly as the destructor would (DecreaseReferenceCounter, then Destroy and delete at zero, counting the delete) and rethrows. One place, because every operator returns through it. Measured: a failed vector product used to leak 1 Real and 2 Vector nodes, now new==delete. The R5.4.2 test case requires OpenNodes()==0 instead of documenting the leak, and symbolicModuleTest.py no longer has to save and restore the counters around its error paths; its reference value is unchanged. Mutation check: the eager member-initializer form produces 1 failure. revision2026 step R5.4.8.

    • date resolved: 2026-09-17 16:43, date raised: 2026-09-17

  • 1.11.118 BUG raised by: Claude-JG resolved by: Claude-JG SymbolicVector.h and SymbolicMatrix.h do not include what they use (#2480)

    • description: Both headers use py::list, py::array_t and EPyUtils but include no pybind11 header and not PybindUtilities.h. They compile only because Symbolic.cpp includes pybind11 before them; any other translation unit that includes SymbolicVector.h first fails with a wall of errors about an unknown namespace py (found while writing the R5.4.2 tests, which now have to repeat that include order themselves). Add the includes the headers need. revision2026 step R5.4.7.

    • notes: Symbolic.h now includes BasicLinalg.h, <unordered_map> and <typeinfo>; SymbolicVector.h includes Symbolic.h and PybindUtilities.h; SymbolicMatrix.h includes those plus SymbolicVector.h. PybindUtilities.h brings the pybind headers, the py alias and EPyUtils in one line and includes nothing symbolic, so there is no cycle. The proof is a deletion: the four-line include workaround in SymbolicUnitTests.h is gone and the tests compile with the headers in any order. revision2026 step R5.4.7.

    • date resolved: 2026-09-17 16:43, date raised: 2026-09-17

  • 1.11.117 BUG raised by: Claude-JG resolved by: Claude-JG SparseTripletMatrix(rows, columns, triplets) throws its size arguments away (#2476)

    • description: The three-argument constructor initialises numberOfRows(0) and numberOfColumns(0) and never assigns numberOfRowsInit or numberOfColumnsInit, so a matrix built with it reports 0 x 0 while holding the triplets. Nothing in the code base calls it - it was found while fixing #2474, which makes the size fields load-bearing for MultMatrixVector. Either assign them or delete the constructor. revision2026 step R5.4.6.

    • notes: The three-argument constructor now assigns numberOfRowsInit and numberOfColumnsInit; fixed and kept rather than deleted, on the maintainer decision. It also gets its first caller: a case in AllMatrixVariantsUnitTests.h builds a 2x3 matrix through it and asks a MatrixContainer for a matrix-vector product, which since #2474 sizes its result from exactly those fields. Mutation check: putting the zeros back produces 1 failure. revision2026 step R5.4.6.

    • date resolved: 2026-09-17 16:43, date raised: 2026-09-17

  • 1.11.116 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG pythonTests.cpp is dead manual test code (#2484)

    • description: src/Pymodules/pythonTests.cpp is 849 lines of which 56 are live code, and the body of PyTest() is commented out ENTIRELY - the function does nothing. It is bound as exu.Test only outside a release build. CreateTestSystem is bound only under _MYDEBUG and builds a model by py::exec of a Python string written against the pre-exudyn API (from itemInterface import *, mbs.AddObject with a raw dict); it predates exudyn.demos, which does the same job properly. Both are more misleading than helpful (maintainer, 2026-09-17). Remove the file and its header PybindTests.h, the two bindings in PybindModule.cpp and the project entries. revision2026 step R5.4.11.

    • notes: Removed: src/Pymodules/pythonTests.cpp and src/Pymodules/PybindTests.h, the include and the two m.def bindings in PybindModule.cpp, the ClCompile/ClInclude entries in cppsrc.vcxproj and .filters, and the pythonTests.cpp entry in the hand-maintained minimal list of sources.json. The compile list is now 132 sources, 53 minimal. A comment in tools/benchmarks/avx2Benchmark.py that pointed at the removed sweep was rewritten. Verified: the module builds, exu.Test and exu.CreateTestSystem are gone, gen_sources.py agrees, suite PASSED, pytest passed. revision2026 step R5.4.11.

    • date resolved: 2026-09-17 16:27, date raised: 2026-09-17

  • 1.11.115 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG Symbolic and LinearSolver have no C++ unit tests (#2479)

    • description: src/Tests/ covers the vectors, the arrays, the matrix classes and the geometry group, but neither the symbolic expression system (Symbolic.h, SymbolicVector.h, SymbolicMatrix.h; ~4000 lines) nor LinearSolver.h (the dense and the sparse system matrix behind one GeneralMatrix interface). symbolicModuleTest.py compares the NUMBERS from Python, so the C++ tests aim at the expression TREE - Diff, the value accessors, the non-recording path, the reference counting - and the solver tests solve one system with all four variants and pin down where the variants deliberately differ. revision2026 steps R5.4.2 and R5.4.3.

    • notes: Two new headers, 21 cases. SymbolicUnitTests.h (11) goes at the expression TREE, which symbolicModuleTest.py cannot reach: Diff by pointer identity, the chain rule, what Diff throws for and what it answers with NaN, exact ToString output, the non-recording branch as a second implementation, the value-accessor contracts, SetSRealVector and EvaluateComponent (both unbound in Python), and the reference counting - each case under a guard that restores recordExpressions and the new/delete counters, because symbolicModuleTest.py measures those. LinearSolverUnitTests.h (10) solves one 4x4 system with all four variants and pins down where they differ: only EXUdense reports the causing row, the Eigen dense paths report success for a singular matrix, EXUdense overwrites its matrix with the inverse while factorizing, and SetMatrix does not size the sparse matrix. symbolicModuleTest.py was extended (Diff, VariableSet, recording off, __str__, error paths) with its reference value unchanged at 0.9484129575069745. Mutation-checked: a dropped term in the product rule gives 2 failures, a dense factorization that always claims success gives 1. Found on the way: #2480, #2481, #2482, #2483. revision2026 steps R5.4.2 and R5.4.3.

    • date resolved: 2026-09-17 16:05, date raised: 2026-09-17

  • 1.11.114 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG a model run locally still opens plot windows (#2478)

    • description: Step R5.17 gave exudyn the suppressPlots flag and it reaches every plot the PACKAGE draws (PlotSensor, PlotFFT, ParameterVariationPlot, the Campbell diagram). It cannot reach a script that imports matplotlib itself and calls plt.show(): 36 models and examples do exactly that, so running one of them locally - to check a change or reproduce a bug - still opens a window on the maintainer screen and waits. The runners are not affected, they set the Agg backend in their bootstrap. Needed: a one-line guard in those 36 scripts that switches to the non-interactive backend when exudyn.special.userInterface.suppressPlots is set, plus a rule in CLAUDE.md that a local run of an existing model sets EXUDYN_SUPPRESS_UI_WINDOW_OPEN and EXUDYN_OUTPUTDIRECTORY. revision2026 step R5.17.1.

    • notes: The 36 models and examples that import matplotlib themselves and call plt.show() now carry a two-line guard right after their exudyn import: it switches to the non-interactive Agg backend when exudyn.special.userInterface.suppressPlots is set. Measured both ways - with EXUDYN_SUPPRESS_UI_WINDOW_OPEN=1 the backend is Agg and plt.show() returns at once; without it the backend stays tkagg. CLAUDE.md gained hard rule 11: a local run of a model or example sets EXUDYN_SUPPRESS_UI_WINDOW_OPEN and EXUDYN_OUTPUTDIRECTORY. 171 examples with the same 5 pre-existing failures; suite PASSED; pytest 136 passed. revision2026 step R5.17.1.

    • date resolved: 2026-09-17 15:28, date raised: 2026-09-17

  • 1.11.113 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG Exudyn has no way to say do not open windows (#2477)

    • description: A model or an example run outside the test suite opens the renderer and waits for the human - there is no switch for it. The test runners therefore REWRITE the source before running it (six substitutions in testRunnerTools.PrepareExampleSource neutralise SC.renderer.Start/Stop/DoIdleTasks/IsActive, mbs.SolutionViewer, InteractiveDialog and plt.show), which only works for code the runner controls. Needed: exudyn.special.userInterface with suppressRenderer, suppressSolutionViewer, suppressPlots and suppressDialogs, readable from C++ (the renderer window and idle loop live there) and from the Python helpers, plus the environment variables EXUDYN_SUPPRESS_UI_WINDOW_OPEN and EXUDYN_OUTPUTDIRECTORY for automated runs. revision2026 step R5.17.

    • notes: New group exu.special.userInterface (PySpecialUserInterface next to PySpecialSolver and PySpecialExceptions) with suppressRenderer, suppressSolutionViewer, suppressPlots, suppressDialogs and SuppressAll(). The renderer honours them in C++ (Start returns False, IsActive is False so a while-IsActive loop ends at once, DoIdleTasks returns), the Python helpers through basicUtilities.UIWindowSuppressed, which also prints ONE notice per kind. __init__.py reads EXUDYN_SUPPRESS_UI_WINDOW_OPEN and EXUDYN_OUTPUTDIRECTORY once, each in try/except and each announced; the first also switches matplotlib to Agg, which is the only thing that reaches the 29 examples and 9 models calling plt.show() themselves. Six source substitutions deleted from the test runners. Verified: 171 examples with the same 5 pre-existing failures, suite PASSED, pytest 136 passed. revision2026 step R5.17.

    • date resolved: 2026-09-17 13:01, date raised: 2026-09-17

  • 1.11.112 BUG raised by: Claude-JG resolved by: Claude-JG MatrixContainer::MultMatrixVector has two preconditions depending on its mode (#2474)

    • description: The dense path calls MultMatrixVectorTemplate, which does result.SetNumberOfItems(rows); the sparse path calls SparseTripletMatrix::MultMatrixVector, which only does solution.SetAll(0.) and then indexes solution[triplet.row()]. So the same call with an unsized result vector works for a dense container and, for a sparse one, throws in a checked build and writes OUT OF BOUNDS in exudynCPPfast. One interface must not have two preconditions: size the vector in the sparse path as well. Found by the unit tests of revision2026 step R5.4.1.

    • notes: SparseTripletMatrix::MultMatrixVector sizes the result to NumberOfRows() before zeroing it, as the dense path has always done, and both sparse products now check their sizes. The R5.4.1 container test passes UNSIZED result vectors to both modes; commenting the new SetNumberOfItems out produces exactly one failure. Found on the way: #2476 (step R5.4.6). revision2026 step R5.4.5.

    • date resolved: 2026-09-17 11:15, date raised: 2026-09-17

  • 1.11.111 BUG raised by: Claude-JG resolved by: Claude-JG LinkedDataMatrix: the two constructors taking a matrix do not compile (#2473)

    • description: LinkedDataMatrixBase(const MatrixBase<T>&) and LinkedDataMatrixBase(const MatrixBase<T>&, Index startRows, Index numberOfRowsLinked) read m.numberOfRows/numberOfColumns/data - protected members of another object - which C++ does not allow through a base-class reference (error C2248), and the const-ness of the data pointer does not match either. Neither is used anywhere: the code base links through the pointer constructor (CMarkerSuperElementPosition.cpp, CMarkerSuperElementRigid.cpp), so this has never been noticed. Found by the unit tests of revision2026 step R5.4.1 being their first users. Either fix them to use the public accessors or delete them; a row-range link is useful and the pointer arithmetic is currently up to the caller.

    • notes: LinkedDataMatrixBase(const MatrixBase<T>&) now uses the public accessors NumberOfRows/NumberOfColumns/GetDataPointer instead of the protected members of another object (C2248). The row-range constructor next to it gets its first caller: the R5.4.1 test no longer does the row-major pointer arithmetic by hand. All C++ unit tests pass. revision2026 step R5.4.4.

    • date resolved: 2026-09-17 11:15, date raised: 2026-09-17

  • 1.11.110 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG five examples write sensor output next to themselves, it clutters the working tree (#2475)

    • description: Five examples name their sensor files without the solution/ prefix that every other model and example uses: beltDriveALE and beltDriveReevingSystem write into solutionDelete/, beltDriveReevingSystem also writes its coordinates solution into solution_nosync/, rigidBodyIMUtest into solutionIMU<mode>/, sliderCrank3DwithANCFbeltDrive and sliderCrank3DwithANCFbeltDrive2 into the current directory (Preload_overallS.txt, Pos_Disk0_overallS.txt, Angular_velocity_overallS.txt, angular_velocity_disk0/1.txt, torque.txt, crank_pos.txt) plus a plots/ directory. Only solution/ is in .gitignore, so a direct run of one of these examples leaves untracked and unignored files and directories behind - and the reads (np.loadtxt) do not go through OutputFilePath either, so they ignore exudyn.config.outputDirectory. revision2026 step R5.13.2.

    • notes: All five examples now write through solution/ and read through OutputFilePath: beltDriveALE and beltDriveReevingSystem (solutionDelete/ and solution_nosync/ are gone), rigidBodyIMUtest (solution/IMU<mode>/), and the two sliderCrank3DwithANCFbeltDrive examples (bare names and plots/ -> solution/ and solution/plots/). Verified by running all five from python/Examples with no output directory set: one solution/ directory appears and nothing else. revision2026 step R5.13.2.

    • date resolved: 2026-09-17 11:04, date raised: 2026-09-17

  • 1.11.109 EXTENSION raised by: Claude-JG resolved by: Claude-JG unit tests for the matrix variants and the rigid body / geometry classes (#2472)

    • description: revision2026 step R5.4.1: ResizableMatrix, ConstSizeMatrix, LinkedDataMatrix, MatrixContainer, RigidBodyMath, Geometry, BoundingBox and SearchTree had no unit tests; AllMatrixUnitTests.h covered only the base Matrix class. Two new headers, property-based where possible (rotation round trips, skew as cross product, SearchTree against a brute-force scan).

    • notes: src/Tests/AllMatrixVariantsUnitTests.h (10 cases) and src/Tests/RigidBodyMathUnitTests.h (10 cases), registered in UnitTestBase.cpp and in the VS project. Property-based where a property exists: skew IS the cross product, a rotation matrix is orthonormal with determinant +1, EP and RotXYZ round trip through the matrix, RotationVector2RotationMatrix satisfies trace = 1+2cos(angle) and fixes its own axis, and every SearchTree query is compared against a brute-force scan for 1x1x1, 2x2x2 and 5x5x5 cells. Validated by mutation: a sign flipped in Vector2SkewMatrix gives 4 failures. The second mutation (the sparse product accumulating with = instead of +=) was NOT caught at first - the test matrix had one entry per row - so the test was strengthened to two entries in one row and now catches it. Also pinned down: RotXYZ composes as A(x)*A(y)*A(z), DistanceToPlane is UNSIGNED, and Box3D::Intersect REJECTS touching boxes although its comment claims otherwise. Two defects found and raised rather than fixed: #2473, #2474. revision2026 step R5.4.1.

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

  • 1.11.108 BUG raised by: Claude-JG resolved by: Claude-JG NGsolveCMStest reference value follows an untracked mesh cache (#2469)

    • description: NGsolveCMStest.py loads python/TestModels/testData/netgenTestMesh.pkl - a TRACKED file - and silently OVERWRITES it whenever the load fails. That happened during revision2026 step R2.10 and the result moved by 2.4e-8, far outside the 5e-14 tolerance, back to the value recorded before 2025-05-05; restoring the committed file restored the value. A test must not rewrite its own committed input: either treat the mesh as read-only and fail loudly, or generate it deterministically.

    • notes: NGsolveCMStest.py decided on an EXCEPTION: it saved the mesh whenever LoadFromFile failed, and a load fails for reasons unrelated to the file being absent - under a second C++ module it raises ‘type “Real” is already registered’, a new ngsolve version would do the same. The tracked testData/netgenTestMesh.pkl was then overwritten and the result moved by 2.4e-8, far outside the 5e-14 tolerance, leaving the working tree dirty. It now decides on os.path.isfile: the file is written only when it does not exist, and a file that exists but cannot be loaded raises with the reason and the advice to delete it deliberately. Verified in three states - present (loads, byte-identical afterwards), corrupt (raises, not rewritten), missing (recreated, and the new mesh gives the other value, which is why it must not happen by accident). revision2026 step R2.10.2. ALSO: the tracked mesh was converted from .pkl to .npz (maintainer, 2026-09-17), keeping the mesh and the reference value; .gitignore narrowed so the tracked mesh is not matched. The .npz still cannot be read by a second module - one stored field is a C++ enum - which is #2471.

    • date resolved: 2026-09-17 08:39, date raised: 2026-09-16

  • 1.11.107 EXTENSION raised by: Claude-JG resolved by: Claude-JG a second reference set for the AVX2 module, as an update to the baseline (#2470)

    • description: revision2026 step R2.10.3: since step R2.10 the regular module is baseline ISA and exudynCPPfast carries AVX2, so one set of reference values cannot judge both on Windows. AVX2ReferenceSolutionUpdate() at the end of runTestSuiteRefSol.py holds ONLY the values that move (32 of 136), as an update to the baseline values, and is meant to shrink as the causes are found or the models are re-parameterised to amplify roundoff less.

    • notes: AVX2ReferenceSolutionUpdate() holds the 32 values (31 models + 1 mini example) that move on an AVX2 module, ordered by drift so the worst are the work list; everything else stays single-sourced in the baseline values. testRunnerTools.ModuleUsesAVX2() asks the module (the platform string already reports AVX2/AVX512), so a –no-avx2 fast build is judged by the baseline values. NotJudgedOutsideRegularModule() skips two models under exudynCPPfast: parameterConversionTest (its result counts rejected inputs) and NGsolveCMStest (its pickled FEM data carries the C++ types of one module; loading under a second raises ‘type Real is already registered’ and the model then overwrites its own tracked input, #2469). Both runTestSuite.py and the pytest collector apply this. Verified: both modules pass the suite from one reference file. revision2026 step R2.10.3.

    • date resolved: 2026-09-17 00:32, date raised: 2026-09-17

  • 1.11.106 BUG raised by: Claude-JG resolved by: Claude-JG exudynCPPfast crashes in the test suite (segmentation fault) (#2467)

    • description: Running runTestSuite.py against exudynCPPfast segfaults reproducibly: with AVX2 after TestModel 74 (objectFFRFTest.py), without AVX2 after 75 (objectFFRFTest2.py). Both models pass standalone under the same module, so this is accumulated corruption, and the shifting crash point shows it is __FAST_EXUDYN_LINALG (no range checks), not the vector extensions. Found in revision2026 step R2.10; the fast module was built for one Python version only and the suite had apparently never been run against it.

    • notes: Root cause: MainObjectANCFThinPlate::SetWithDictionary calls ParametersHaveChanged() with whatever the user wrote into the dictionary, BEFORE the object factory validates the item, and CObjectANCFThinPlate::ParametersHaveChanged computes the slope scaling from the nodes - reading cSystemData->GetCNodes()[-1] for a default/invalid node number. In exudynCPP the range check of the array turns that into a Python exception, so it was invisible; in exudynCPPfast the checks are compiled out and the process died. Found with AddressSanitizer (access-violation at 0xffffffffffffffff in CObject::GetCNode). ThinPlate is the only object that dereferences nodes in ParametersHaveChanged. Fixed by computing the scaling only when the node numbers address existing nodes; the factory reports the invalid number right afterwards. The full suite now completes under exudynCPPfast. revision2026 step R2.10.1.

    • date resolved: 2026-09-17 00:11, date raised: 2026-09-16

  • 1.11.105 BUG raised by: Claude-JG resolved by: Claude-JG deleting build/temp is not enough after a compile-flag change (#2468)

    • description: The documented gate (revision2026 step R2.17, #2427) says to delete build/temp.win-amd64-cpython-313 after a header change. That is insufficient for a FLAG change: build/lib.win-amd64-cpython-313 keeps the previously linked .pyd and the wheel is assembled from it, so a rebuild silently ships the old binary. This produced three contradictory measurements in revision2026 step R2.10 before the whole build/ directory was removed. Fix the gate instruction and preferably make setup.py handle it.

    • notes: setup.py writes the effective compiler options of every extension to build/exudynBuildFlags.txt and compares them at the start of the next build; on a difference it removes the object directory AND the linked modules, then recompiles. The stamp sits next to build/temp* and build/lib*, not inside either (MSVC build_temp is build/temp…/Release). Verified: two builds differing only in EXUDYN_EXTRA_COMPILE_ARGS=/arch:AVX2, nothing deleted by hand, give 7380480 and 7400448 byte modules and the expected 0 vs 32 test failures. revision2026 step R2.17.1.

    • date resolved: 2026-09-16 23:47, date raised: 2026-09-16

  • 1.11.104 EXTENSION raised by: Claude-JG resolved by: Claude-JG two shipped C++ modules: exudynCPPnoAVX dropped, AVX2 belongs to exudynCPPfast (#2466)

    • description: revision2026 step R2.10: the default module exudynCPP is compiled for the BASELINE instruction set on every platform and exudynCPPfast carries __FAST_EXUDYN_LINALG and AVX2; the third module exudynCPPnoAVX and the sys.exudynCPUhasAVX2 switch are removed. New build switches useAVX2 (default on; effective only inside the fast module) and useAVX512 (default off; requires useAVX2). All Windows reference values re-measured on the baseline module.

    • notes: setup.py: useAVX2/useAVX512 switches, vector flags moved into exudynCPPfast (with -ffp-contract=off on gcc/clang), exudynCPPnoAVX removed, fast module built for Python 3.13 in a development version. python/exudyn/__init__.py: two candidates and an OS-level AVX2 check replacing the numpy __cpu_features__ read. All 113 Windows reference values re-measured on the baseline module (85 moved, 33 of them past tolerance); sphereTriangleTest.py moved to DeliberatelyNotRun. Suite and pytest green.

    • date resolved: 2026-09-16 23:20, date raised: 2026-09-16

  • 1.11.103 BUG raised by: Claude-JG resolved by: Claude-JG the two AVX vector classes have no unit tests (#2465)

    • description: ResizableVectorParallel and LinkedDataVectorParallel are covered by no lest case; #2394 (a misaligned __m256d load on a LinkedDataVector sub-range) lived there and was found by a sanitizer on a whole test model. A defect in these classes is invisible in the TestModels on Windows and can change results silently. revision2026 step R5.4.

    • notes: revision2026 step R5.4: new src/Tests/AVXVectorUnitTests.h with 7 cases; each over 19 lengths around the AVX packet boundary built from AVXRealSize; LinkedDataVectorParallel at every offset from 0 to AVXRealSize into a padded buffer; results compared against a scalar loop; one length above the multithreading limit. Verified by mutation: a remainder loop started one item late gives 2 failed tests.

    • date resolved: 2026-09-16 20:40, date raised: 2026-09-16

  • 1.11.102 BUG raised by: Claude-JG resolved by: Claude-JG the lest C++ unit tests are compiled nowhere (#2464)

    • description: src/Tests/ is gated on PERFORM_UNIT_TESTS; setup.py added that define for Python 3.7 only, and 3.7 stopped being built long ago (requires-python >=3.10), so the unit tests run in no wheel; no CI job and no local build. The VS Debug configuration does not define it either. revision2026 step R5.3.

    • notes: revision2026 step R5.3: new build switch performUnitTests (command line –unittests; EXUDYN_PERFORM_UNIT_TESTS; [tool.exudyn]); off by default; -DPERFORM_UNIT_TESTS also for unix; PERFORM_UNIT_TESTS in the VS Debug configuration. Verified: the tests compile and all pass.

    • date resolved: 2026-09-16 19:59, date raised: 2026-09-16

  • 1.11.101 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG runTestSuite.py checks hasattr(exu.solver, RunCppUnitTests) instead of exu.special (#2458)

    • description: found 2026-09-16 while preparing revision2026 step R5.3: the C++ unit tests are gated on hasattr(exu.solver, “RunCppUnitTests”), but the function is bound on exu.special (Pybind_manual_classes.cpp, inside #ifdef PERFORM_UNIT_TESTS); exu.solver is the Python module exudyn.solver and never has that attribute, so the check is always False and the tests are reported as skipped even in a build that contains them. Belongs to revision2026 step R5.3

    • notes: revision2026 step R5.3: runTestSuite.py checked hasattr(exu.solver; RunCppUnitTests) while the binding is on exu.special - the C++ unit tests were reported as skipped even in a build that has them; and the summary called len() on the returned count.

    • date resolved: 2026-09-16 19:59, date raised: 2026-09-16

  • 1.11.100 EXTENSION raised by: Claude-JG resolved by: Claude-JG dev tool dependencies are not declared (#2462)

    • description: pytest and pytest-xdist (revision2026 step R5.1) are installed by hand and appear nowhere in the project metadata; the build dependency group does not match build-system.requires (setuptools>=77; tomli) and does not carry the cibuildwheel version the wheels workflow pins. revision2026 step R5.14.

    • notes: revision2026 step R5.14: new test dependency group (pytest; pytest-xdist); build group matched to build-system.requires (setuptools>=77; tomli) and to the pinned cibuildwheel version; condaEnvironments.md group table updated.

    • date resolved: 2026-09-16 19:54, date raised: 2026-09-16

  • 1.11.99 EXTENSION raised by: Claude-JG resolved by: Claude-JG the examples run serially and take six minutes (#2461)

    • description: runTestExamples.py execs 171 examples one after the other into a single interpreter; 360 seconds on Windows. The examples are an API check - an example has done its job once it has built its model and reached the solver. revision2026 step R5.16: run them in separate interpreters in parallel; give every example its own output directory; and count a timeout as a pass once the solver was reached.

    • notes: revision2026 step R5.16: testRunnerTools.RunExampleInProcess/RunExamplesInParallel run every example in its own interpreter and its own output directory; a timeout after the solver was reached counts as a pass; PrepareExampleSource and ExampleSkipReason moved into testRunnerTools; 43 examples wrap a read of their own output in OutputFilePath; chainDriveExample imports sin/cos/arcsin; minimizeExample and dispyParameterVariationExample are skipped as not self-contained. 360 s -> 49 s.

    • date resolved: 2026-09-16 18:57, date raised: 2026-09-16

  • 1.11.98 EXTENSION raised by: Claude-JG resolved by: Claude-JG performance suite reports only one wall-clock time per model (#2460)

    • description: runPerformanceTests.py wraps each model in time.time() and prints one number per file; that number contains model build; assembly and Python overhead; and every model covers exactly one problem size and one thread count. revision2026 step R5.15: record the solver time of every single simulation run in exudynTestGlobals.timings and report them; vary the size of perfLargeMassSpringChain and the thread count of generalContactSpheresTest; make perfLargeMassSpringChain a rigid body chain so that it measures the object computation.

    • notes: revision2026 step R5.15: testRunnerTools.AddTiming records solver.timer.total; the result and a run name per simulation in exudynTestGlobals.timings; runPerformanceTests.py prints and judges the 13 single runs; perfLargeMassSpringChain is a rigid body chain over 1000/5000/20000 bodies (explicit and implicit; computeMassMatrixInversePerBody on); generalContactSpheresTest runs with 1/4/8 threads in the performance path only; new reference values for the reworked models and for perf3DRigidBodies and perfSpringDamperExplicit.

    • date resolved: 2026-09-16 17:51, date raised: 2026-09-16

  • 1.11.97 EXTENSION LOW raised by: Claude-JG resolved by: Claude-JG no way to run a fast subset of the test models (#2459)

    • description: revision2026 step R5.2: every runner was all-or-nothing, so a pull-request run had to include the models that take longest and those needing optional packages (ngsolve, stable-baselines3). Added SlowTests() and OptionalPackageTests() as data in runTestSuiteRefSol.py, runTestSuite.py –fast and pytest markers slow/optionalPackage/sensitive/unresolvedOnLinux reading the same data

    • notes: revision2026 step R5.2: SlowTests/OptionalPackageTests as data; runTestSuite.py –fast (12 s) and pytest markers; nightly unchanged

    • date resolved: 2026-09-16 17:09, date raised: 2026-09-16

  • 1.11.96 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG test models are not available as pytest cases (#2457)

    • description: revision2026 step R5.1: runTestSuite.py was the only way to run the test models, so there was no selection by name, no IDE or CI reporting and no standard parallel runner; added python/TestModels/test_testModels.py with one parametrized case per model and mini example, sharing reference values and tolerances with the suite

    • notes: revision2026 step R5.1: test_testModels.py, 137 cases, shared reference values and tolerances (testRunnerTools.BaseTolerance); found and fixed a masked defect in plotSensorTest.py

    • date resolved: 2026-09-16 15:04, date raised: 2026-09-16

  • 1.11.95 CHANGE LOW raised by: Claude-JG resolved by: Claude-JG runTestSuite.py runs the models serially (#2456)

    • description: revision2026 step R5.8: the 114 test models ran one after the other in a single interpreter (about 22 seconds); with each model writing into its own output directory since step R5.13 they can run in separate processes. Added –parallel[=N]; the models are reported in the order of the reference list; serial stays the default for the commit gate because multithreaded solvers and ARPACK shift the last digits under load

    • notes: revision2026 step R5.8: –parallel[=N] runs each model in its own interpreter (22 s -> 11 s with 8 workers); results reported in reference-list order; serial remains the default

    • date resolved: 2026-09-16 14:24, date raised: 2026-09-16

  • 1.11.94 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG exudyn.config.outputDirectory: global output directory for solver written files (#2454)

    • description: revision2026 step R5.13: solver written files (coordinates solution; solver information; sensor files; exported images) are prefixed with exudyn.config.outputDirectory when it is set. An absolute file name together with a non-empty outputDirectory raises an error when the file is opened. The setting is global and lives as long as the module is loaded; it is meant for test runners and batch scripts; users should put the folder into the file names. Needed so that the test suite can give every model its own output directory (#2418) - the prerequisite for running the suite in parallel

    • notes: revision2026 step R5.13: ResolveOutputFileName() in Stdoutput.cpp, applied to solution, solver information, sensor and image files; absolute names raise on open

    • date resolved: 2026-09-16 10:16, date raised: 2026-09-16

  • 1.11.93 TESTING raised by: Claude-JG resolved by: Claude-JG test suite models write output files into TestModels instead of solution/ (#2418)

    • description: models write solution and sensor files next to themselves (coordinatesSolution.txt and others) so TestModels/ fills with output and runs collide on the same file names - which blocks running the suite in parallel (revision2026 step R5.8). In the test suite all output goes to solution/ with unique per-model names; file writes are avoided widely (sensors storeInternal and writeSolutionToFile False) and done only sparsely so writing stays tested - those tests re-read the written files and check them. TestExamples stay serial: they only check that examples still run against the current API. revision2026 step R5.13.

    • notes: revision2026 step R5.13: exudyn.config.outputDirectory plus one output directory per model in runTestSuite.py; compareFullModifiedNewton is the designated writing test

    • date resolved: 2026-09-16 10:16, date raised: 2026-09-14

  • 1.11.92 CHECK NORMAL raised by: Claude-JG resolved by: Claude-JG the only benchmark that resolves AVX2 is commented out inside exu.Test() (#2397)

    • description: measured 2026-09-12: runPerformanceTests.py gives 20.118 s without AVX2 and 20.137 s with -mavx2 -mfma in the same container - 0.1 percent; with per test differences in both directions. Four of the six performance tests are tiny systems run for about 1e6 steps; so the vectors are 3 to 20 elements long and per step overhead dominates; AVX2 only pays on long vectors. A sweep that does resolve it exists in PyTest() in src/Pymodules/pythonTests.cpp (exposed as exu.Test()); with recorded results in comments (speedup 3.1 for n=502; 3.5 for n=1002; plus an AVX/multithreaded/serial table for sizes 16 to 200002) - but it is entirely inside comment blocks and if (0); so exu.Test() runs none of it and the numbers cannot be reproduced. revision2026 step R2.10 cannot judge whether the fast variant earns its place in the wheel until there is a maintained benchmark over vector length

    • notes: revision2026 step R2.16: tools/benchmarks/avx2Benchmark.py with solver sub timers replaces the dead sweep in PyTest(); an in-Exudyn micro-benchmark is step R11.2

    • date resolved: 2026-09-16 08:54, date raised: 2026-09-12

  • 1.11.91 CHECK NORMAL raised by: Claude-JG resolved by: Claude-JG enabling AVX2 on Linux shifts results by 1e-9..1e-6 through FMA contraction (#2396)

    • description: measured 2026-09-12 once the alignment defect was fixed: a manylinux cp313 build with -mavx2 -mfma runs the whole suite; but four tests that pass without AVX2 then fail against the 3e-11 tolerance - ANCFcontactCircleTest (-2.185e-08); ANCFslidingAndALEjointTest (2.236e-06); connectorGravityTest (-1.956e-07) and raytracerNOGLFWtest (-1.368e-06). All are rounding scale: a fused multiply-add rounds once where a separate multiply and add round twice. The same build WITHOUT -mavx2 reproduces the previous results bit for bit; so this is a property of AVX2; not of the alignment fix. Relevant to revision2026 step R2.10 (two shipped variants) and to the tolerance discussion in fact 24: either the reference values are variant dependent; or the tolerance has to admit FMA level differences

    • notes: revision2026 step R2.16: caused by FMA contraction; -ffp-contract=off removes it; AVX2 stays off for the default Linux wheel; a fast variant must use the flag

    • date resolved: 2026-09-16 08:54, date raised: 2026-09-12

  • 1.11.90 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG 20 ClInclude entries in cppsrc.vcxproj have the wrong case; 5 entries do not exist (#2387)

    • description: the vcxproj lists headers as src/utilities/…; src/linalg/…; src/system/…; src/tests/… and src/autogenerated/SimulationSettings.h while the tracked directories are Utilities; Linalg; System; Tests and Autogenerated - 20 entries in total. It also lists two headers that do not exist (src/Autogenerated/VisuObjectBeamGeometricallyExact3D.h and src/System/MainObjectFactory.h) and three missing ClassDiagram .cd files. These are IDE browsing entries; the compiler finds headers through the include path; so nothing is broken today - but the same class of defect in a ClCompile entry was a real Linux hazard (see issue 2382) and these would trip any move or flattening step. tools/gen_sources.py –check should be extended to cover ClInclude and None entries. Found during revision2026 step R2.6

    • notes: revision2026 step R2.15: case corrected and missing entries removed in vcxproj and filters; gen_sources.py –check covers all entries

    • date resolved: 2026-09-16 01:00, date raised: 2026-09-12

  • 1.11.89 CHECK LOW raised by: Claude-JG resolved by: Claude-JG quietCompile does not actually quieten the compiler on Linux (#2380)

    • description: the quiet path redirects sys.stdout; but on Linux _compile spawns the compiler as a subprocess that writes to file descriptor 1 directly; so the compiler output bypasses the redirection and setuppy.output.txt stays empty (measured: 0 bytes after a full 133 file build). Suppressing it would need the subprocess stdout to be captured; not sys.stdout rebinding. Pre-existing; found while fixing the thread-safety defects of revision2026 step R2.3

    • notes: revision2026 step R2.15: file descriptors 1 and 2 redirected around the compile pool; verified in WSL

    • date resolved: 2026-09-16 01:00, date raised: 2026-09-11

  • 1.11.88 CHECK LOW raised by: Claude-JG resolved by: Claude-JG project.license TOML table deprecated (#2372)

    • description: setuptools deprecates license = { text = … } with deadline 2027-Feb-18; the replacement is an SPDX expression. There is no honest one: LICENSE.txt is the custom EXUDYN General License; not an OSI-approved BSD - which is also why the License :: OSI Approved :: BSD License classifier was dropped. Needs a decision on what the licence identifier should be

    • notes: revision2026 step R2.15: license = LicenseRef-EXUDYN-General-License with license-files; setuptools>=77

    • date resolved: 2026-09-16 01:00, date raised: 2026-09-11

  • 1.11.87 DOCU raised by: Claude-JG resolved by: Claude-JG Restructure and renumber the 2026 revision documents (#2453)

    • description: Maintainer request 2026-09-15: the plan mixed general sections with the steps and numbered steps in discovery order; the log followed neither. Now three documents (exudynRevisionInfo2026.md with rules/facts/decisions/material for the user documentation/transition table; the plan by phases R0-R11; the log in plan order with closing commit and time); permanent numbers R<phase>.<step> (sub-steps R4.10.3); all references in tracked files renumbered including this tracker; code comments shall cite issues instead of plan steps.

    • notes: three revision documents; R numbering; transition table in exudynRevisionInfo2026.md section 15

    • date resolved: 2026-09-16 00:02, date raised: 2026-09-16

  • 1.11.86 EXTENSION raised by: Claude-JG resolved by: Claude-JG expose item type and shape information to Python (#2411)

    • description: Structures have a generated GetDictionaryWithTypeInfo() (pythonAutoGenerateSystemStructures.py:531) that feeds the settings dialog (GUI.py:323). Items have no equivalent; the items dialog therefore shows no types. Proposal: a generated exudyn/types/ subpackage carrying per parameter the type; shape and range; plus nodeType; requestedNodeType and requestedMarkerType (95 / 34 / 36 C-destination members today; none visible from Python). It must not go into itemInterface.py: that module is 390 KB and sits on the exudyn.utilities import path. setup.py:530 already uses find_namespace_packages; so packaging needs no change. Second part: requestedNodeType and requestedMarkerType are written as C++ in the definition today and should become declared type lists from which the accessor is generated. The additive case is the common one; the known hard case is ObjectContactSphereSphere; where the requested marker type is a base list plus one conditional term governed by one parameter (dynamicFriction != 0) - see src/Autogenerated/CObjectContactSphereSphere.h:184. Survey first whether any case needs more than one condition.

    • notes: revision2026 step R4.10.4: generated exudyn/types/items.py and query functions; typeInformationTest agrees with Assemble

    • date resolved: 2026-09-15 23:01, date raised: 2026-09-13

  • 1.11.85 CHANGE raised by: Claude-JG resolved by: Claude-JG Declared item types and access function types (#2452)

    • description: revision2026 step R4.10.3: GetType of nodes and markers and GetAccessFunctionTypes of objects (bodies in 19 cpp files) become declared lists with generated bodies; basis of the Python type information and compatibility queries (83d).

    • notes: revision2026 step R4.10.3: ItemTypes in 34 nodes/markers; ItemAccessFunctionTypes in 19 objects; cpp bodies removed

    • date resolved: 2026-09-15 22:50, date raised: 2026-09-15

  • 1.11.84 CHANGE raised by: Claude-JG resolved by: Claude-JG Marker::Type is not in the enum registrator (#2451)

    • description: Marker::Type is hand-written in src/Main/OutputVariable.h with a comment to keep it synchronized with AccessFunctionType; NodeType and the others are generated from definitions/enumTypes.py (revision2026 step R4.3). ItemRequestedTypes (revision2026 step R4.10.1) can therefore validate node type names but not marker type names; and revision2026 step R4.10.2 needs the marker type names in Python.

    • notes: revision2026 step R4.10.2: Marker::Type and AccessFunctionType generated from enumTypes.py and bound to Python

    • date resolved: 2026-09-15 22:36, date raised: 2026-09-15

  • 1.11.83 CHANGE raised by: Claude-JG resolved by: Claude-JG Declared requested node and marker types (#2450)

    • description: revision2026 step R4.10.1: GetRequestedNodeType / GetRequestedMarkerType are written as C++ inside 70 item definitions. Replace them by ItemRequestedTypes(kind; types; conditional) with a generated body; survey: the only conditional is Orientation if dynamicFriction != 0 (ObjectContactSphereSphere; ObjectContactSphereTriangle).

    • notes: revision2026 step R4.10.1: ItemRequestedTypes in 70 definitions; generated bodies; 12 headers change in spelling

    • date resolved: 2026-09-15 22:01, date raised: 2026-09-15

  • 1.11.82 CHANGE raised by: Claude-JG resolved by: Claude-JG Group src/Autogenerated by item type (#2449)

    • description: revision2026 step R4.14: item headers move into nodes/ objects/ markers/ loads/ sensors/; generator; includes and vcxproj follow. Maintainer approval for the move 2026-09-15.

    • notes: revision2026 step R4.14: 291 item headers in nodes/objects/markers/loads/sensors; generator; 103 sources and vcxproj includes

    • date resolved: 2026-09-15 20:55, date raised: 2026-09-15

  • 1.11.81 BUG raised by: Claude-JG resolved by: Claude-JG Super element Vshow is False when left out of the dict (#2447)

    • description: ObjectFFRF; ObjectFFRFreducedOrder; ObjectGenericODE2 and ObjectKinematicTree: AddObject without Vshow gives Vshow=False; although definitions/ and itemInterface.py give True and the generated Visu constructor sets show=true. Found by the omit probe of parameterConversionTest.py (revision2026 step R4.13). Likely the parent VisualizationObjectSuperElement constructor or a shadowed member.

    • notes: revision2026 step R4.26: duplicate bool show in VisualizationObjectSuperElement hid the base member; removed

    • date resolved: 2026-09-15 20:45, date raised: 2026-09-15

  • 1.11.80 BUG raised by: Claude-JG resolved by: Claude-JG the wheel build reuses stale object files after a header-only change (#2427)

    • description: setuptools recompiles a .cpp only when the .cpp is newer than its .obj; it does not track included headers. Found in revision2026 step R4.4.3.2: after rewriting src/Pymodules/PybindUtilities.h (included by 35 files) pip wheel . -w dist finished and produced an exudynCPP .pyd with the same md5 as the previous build in build/lib.win-amd64-cpython-313 - nothing was compiled; the test suite then passed against the old binary. Only deleting build/temp.win-amd64-cpython-313 forced the full compile (49 s). So the build gate proves nothing for header-only changes. Fix options: pass depends= (all headers or the include graph) to the Extension so setuptools compares them; or have the gate remove build/temp first. revision2026 step R2.17.

    • notes: revision2026 step R2.17: setup.py passes all src headers as depends= to the extensions

    • date resolved: 2026-09-15 20:37, date raised: 2026-09-14

  • 1.11.79 BUG raised by: Claude-JG resolved by: Claude-JG Wheel gate skips header-only changes (#2448)

    • description: pip wheel . reuses build/ (setuptools compares .cpp against .obj and the .pyd against its sources; headers are not dependencies): after changing only src/Autogenerated/*.h the wheel was built in 4 s with the old binary and the suite ran against it. Found in revision2026 step R4.13; a clean build (build/ removed) takes 50 s. The documented gate must build from a clean build/ directory or the build must track header dependencies. Earlier steps that changed only headers were possibly tested against stale binaries.

    • notes: duplicate of #2427 (revision2026 step R2.17)

    • date resolved: 2026-09-15 20:35, date raised: 2026-09-15

  • 1.11.78 CHANGE raised by: Claude-JG resolved by: Claude-JG Remove CFOptional: every item parameter may be left out of a dict (#2446)

    • description: CFOptional wrapped 448 of the dictionary writes in DictItemExists; the others raised KeyError when left out. revision2026 step R4.13 (#2417 is the original); this issue records the implementation choice: all parameters optional; must-be-given (CFMustBeGiven) ones left out raise if their value is still the placeholder.

    • notes: duplicate of #2417 (raised by mistake for revision2026 step R4.13)

    • date resolved: 2026-09-15 20:15, date raised: 2026-09-15

  • 1.11.77 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG remove the CFOptional flag once phase 3 is done (#2417)

    • description: CFOptional marks 448 of 985 item parameters and generates if (EPyUtils::DictItemExists(d; “x”)) around the dictionary read; so a parameter that is absent keeps its C++ default. It still catches today - the test suite creates items from raw dicts; e.g. modelUnitTests.py:184 calls mbs.AddObject with objectType Ground and referencePosition only; and ObjectGround has four optional parameters that the call omits. Maintainer decision 2026-09-13: remove it after phase 3 anyway. The reasoning: there are practically no tests for this behaviour; so the flag is worthless as a guarantee; and the dict path works if every parameter is optional. Where a parameter really cannot be omitted; the failing default value is the right place to say so - a construction that cannot produce a usable object should fail on its default; not on a hand-written flag that nothing checks. Do this AFTER phase 3; and add tests for the raw-dict creation path at the same time; since that is what the flag silently protects today.

    • notes: revision2026 step R4.13: CFOptional removed; every dictionary write guarded; must-be-given parameters raise when left out; omit probe in parameterConversionTest

    • date resolved: 2026-09-15 20:15, date raised: 2026-09-13

  • 1.11.76 CHANGE raised by: Claude-JG resolved by: Claude-JG Structure members: SFPybind on almost every member; invert to SFNoPybind (#2445)

    • description: SFPybind (P) is set on 845 of 883 structure members; the 38 without it are solver internals (matrix links; temporary data; file streams; cSolver links and their accessors). Maintainer request 2026-09-15: invert the flag so only the exceptions are marked. Measured first by forcing P on all members: 9 generated files change (pybind; stubs; dictionaries; public/protected in CSolverStructures.h; docs); so the flag has an effect for both parameters and functions and must stay as the inverted flag.

    • notes: revision2026 step R4.25: SFNoPybind on 38 members replaces SFPybind on 845; effective flags identical; regeneration no-op

    • date resolved: 2026-09-15 19:59, date raised: 2026-09-15

  • 1.11.75 EXTENSION raised by: Claude-JG resolved by: Claude-JG the constrained parameter types PReal UReal PInt UInt are lost at the C++ boundary (#2409)

    • description: PReal, UReal, PInt and UInt exist so that a bad parameter fails where the item is created - in itemInterface, through the generated CheckForValid* guards - instead of surfacing later as a division by zero or a bad size deep in the solver. But typeConversion in pythonAutoGenerateObjects.py:1801 maps all of them onto plain Real resp. Index, so in the C++ core the intent is gone and a reader of the header cannot tell a positive-only quantity from any other Real. Proposal: add typedefs (PReal -> Real, UReal -> Real, PInt -> Index, UInt -> Index) and emit the constrained name into the generated C++, so the documentation value survives into the core. Purely additive; no behaviour change. Raised on maintainer request during revision2026 step R4.1.2.

    • notes: revision2026 step R4.12: constrained types stated as must be > 0 / >= 0 in generated header member comments; no typedefs because PReal is the AVX macro

    • date resolved: 2026-09-15 19:36, date raised: 2026-09-13

  • 1.11.74 BUG raised by: Claude-JG resolved by: Claude-JG a changed class description never reaches the generated headers (#2415)

    • description: pythonAutoGenerateObjects.py:2029 sets nLinesHeader = 7 and compares the new file text with the existing one only AFTER cutting those 7 lines (CutLinesFromString; autoGenerateHelper.py:155). The intent is to ignore the two volatile @date lines (6 and 7); but lines 2 and 3 are @class and @brief; and @brief carries the class description. So a change confined to the class description is invisible to the write decision and the C/Main/Visu header is never rewritten - the change silently never propagates; and tools/regenerate.py –check cannot see it either; because the gate only observes what the generator actually writes. Proven case: src/Autogenerated/VisuObjectConnectorHydraulicActuatorSimple.h carried a 2024 @brief without the texttt markup that objectDefinition.py has had for some time; it corrected itself only when an unrelated default value in the same class changed and forced a rewrite. A crude scan flags 112 of 291 generated item headers as candidates for the same staleness; each needs confirmation. Fix: compare with IsEqualIgnoringDateStrings (which skips only the date lines) instead of cutting a fixed number of lines; then regenerate once and review the resulting diff.

    • notes: revision2026 step R4.11: item headers compared with IsEqualIgnoringDateStrings instead of cutting 7 lines

    • date resolved: 2026-09-15 19:14, date raised: 2026-09-13

  • 1.11.73 DOCU raised by: Claude-JG resolved by: Claude-JG AngularVelocityLocal output variable description says velocity not angular velocity (#2414)

    • description: Four items describe the AngularVelocityLocal output variable as “local (body-fixed) 3D velocity vector of node”; which describes a translational velocity. The word angular is missing. Found while converting outputVariables into data (revision2026 step R4.1.4). Fixing it moves published reference tables; so it is a separate documentation fix rather than part of that step. Worth checking the neighbouring AngularVelocity descriptions at the same time.

    • notes: revision2026 step R4.11: angular velocity output variable texts fixed (body local; ANCFBeam VelocityLocal)

    • date resolved: 2026-09-15 19:14, date raised: 2026-09-13

  • 1.11.72 FIX raised by: Claude-JG resolved by: Claude-JG itemInterface.py: generated docstrings do not match the signatures (#2440)

    • description: pydoclint reports 387 findings in the generated itemInterface.py: the visualization argument is not documented and the arguments carry type hints in the docstring; fix in itemInterfaceEmitter.py and then include the file in the pydoclint check (revision2026 step R4.23)

    • notes: revision2026 step R4.23: itemInterfaceEmitter docstrings without arg types; visualization documented; read-only members omitted; pydoclint exclude removed

    • date resolved: 2026-09-15 19:08, date raised: 2026-09-15

  • 1.11.71 CHANGE raised by: Claude-JG resolved by: Claude-JG python modules: __all__ in every module; star imports no longer export helper imports (#2444)

    • description: revision2026 step R4.22.3: __all__ in 35 modules (itemInterface by its emitter) from the rule in tools/generators/publicApi.py; tools/checkAll.py –check/–write and GitLab job check_all; utilities.py composes the lists; Examples/TestModels that used np sin cos sqrt copy exudyn from star imports import them explicitly (50 files)

    • date resolved: 2026-09-15 18:58, date raised: 2026-09-15

  • 1.11.70 CHANGE raised by: Claude-JG resolved by: Claude-JG utility modules: star imports export helper names (#2438)

    • description: from exudyn.utilities import * also exports imported helpers (extends; docmeta; module imports); define __all__ or restructure so only the public API is exported; check what examples and test models rely on first (revision2026 step R4.22)

    • date resolved: 2026-09-15 18:58, date raised: 2026-09-15

  • 1.11.69 CHANGE raised by: Claude-JG resolved by: Claude-JG utilities.py: deprecated GraphicsData aliases removed; functions moved to basicUtilities/advancedUtilities/mainSystemExtensions (#2443)

    • description: revision2026 step R4.22.2: 23 GraphicsData… aliases removed (uses switched to exudyn.graphics); @extends functions to mainSystemExtensions; TCP/IP to advancedUtilities; all other functions to basicUtilities (now imports exudyn); utilities.py only re-exports

    • date resolved: 2026-09-15 18:47, date raised: 2026-09-15

  • 1.11.68 CHANGE raised by: Claude-JG resolved by: Claude-JG basicUtilities: numpy-era vector helpers removed (#2442)

    • description: revision2026 step R4.22.1: NormL2 VSum VAdd VSub VMult ScalarMult Vec2Tilde Tilde2Vec DiagonalMatrix eye2D eye3D removed; uses in package/TestModels/Examples replaced by numpy (np.linalg.norm; np.sum; array arithmetic; np.dot; Skew); Normalize kept (zero vector allowed) and implemented with numpy; basicUtilities imports numpy

    • date resolved: 2026-09-15 18:02, date raised: 2026-09-15

  • 1.11.67 CHANGE raised by: Claude-JG resolved by: Claude-JG development environments: dependency groups instead of hand-written package lists (#2441)

    • description: revision2026 step R4.24: [dependency-groups] docs/lint/build/ide/dev in pyproject.toml; docs/requirements.txt removed; CI and readthedocs install groups; condaEnvironments.md recipe uses pip install –group dev

    • date resolved: 2026-09-15 17:14, date raised: 2026-09-15

  • 1.11.66 CHANGE raised by: Claude-JG resolved by: Claude-JG build: install-time docstring converter removed; pydoclint check in CI (#2439)

    • description: revision2026 steps R4.9 and R4.8: autoGenerateDocstrings.py deleted (its text helpers and docstring renderer kept as tools/generators/docstringText.py); setup.py uses the plain build_py; [tool.pydoclint] in pyproject.toml with a baseline in tools/ci; GitLab job check_docstrings

    • date resolved: 2026-09-15 17:02, date raised: 2026-09-15

  • 1.11.65 CHANGE raised by: Claude-JG resolved by: Claude-JG utility modules: docstring text becomes Markdown (#2437)

    • description: revision2026 step R4.6.4: LaTeX macros in docstrings and @docmeta replaced by Markdown (backquoted code; [Key] citations; [text](#label) references and abbreviations; bold/italics; umlauts); utilityDocsModel.Markdown2Latex feeds the existing emitters

    • date resolved: 2026-09-15 16:40, date raised: 2026-09-15

  • 1.11.64 CHANGE raised by: Claude-JG resolved by: Claude-JG utility modules: Google-style docstrings and @docmeta instead of #** comments (#2436)

    • description: revision2026 step R4.6.2/R4.6.3 and R4.7: all utility modules converted; utilityDocsModel reads docstrings and decorators with ast; the #** parser is deleted; generated docs unchanged apart from listed whitespace and recovered text

    • date resolved: 2026-09-15 13:46, date raised: 2026-09-15

  • 1.11.63 FIX raised by: Claude-JG resolved by: Claude-JG utility modules: malformed #** tags silently dropped from the documentation (#2435)

    • description: revision2026 step R4.6.1: #**note (9) #**nodes (3) #**examples #**compute #**outputinput and two #** continuation lines were not recognised; five #**function lacked the colon; HT2T66Inverse had input and output swapped

    • date resolved: 2026-09-15 13:25, date raised: 2026-09-15

  • 1.11.62 CHANGE raised by: Claude-JG resolved by: Claude-JG MainSystem extensions: registry decorator instead of copy-and-append (#2434)

    • description: revision2026 step R4.5: mainSystemExtensions.py becomes ordinary package source; functions bind to MainSystem via @extends(exudyn.MainSystem) and install() which raises on a collision with a C++ method; mainSystemExtensionsEmitter.py and mainSystemExtensionsHeader.py are deleted; the docs parsers read the decorator instead of #**belongsTo

    • date resolved: 2026-09-15 12:22, date raised: 2026-09-15

  • 1.11.61 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG generated item headers carry wrong and stray comments (#2433)

    • description: Reported by the maintainer 2026-09-15: MainLoadCoordinate.h and all other Main headers write /* AUTO: read out dictionary and cast to C++ type*/ inside SetParameter and label every SetParameter line get parameter; GetParameter of user functions ends with ;; ; the visualization pointer is commented as computational object; CNodeGeneric{AE-ODE1-ODE2} return …;; from their definitions; lines carry trailing whitespace. revision2026 step R4.21.

    • notes: itemHeaderEmitter.py: write statements carry no comment (SetWithDictionary lines plain - SetParameter lines end with //! AUTO: set parameter); no ;; in GetParameter; BodyGraphicsData and SetInternal statements without /*! */ comments; else {PyError without double space; visualization pointer comment corrected; trailing whitespace removed from C/Main/Visu headers (the 7 header lines kept by the file comparison are unchanged); ;; removed from the three CNodeGeneric definitions. 291 generated headers changed; parameterConversionTest 0 differences; suite passed.

    • date resolved: 2026-09-15 11:15, date raised: 2026-09-15

  • 1.11.60 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG src/Autogenerated/StructuralElementsDataStructures.h has no generator and no user (#2431)

    • description: Found in revision2026 step R4.4.3.5a: the tracked generated header src/Autogenerated/StructuralElementsDataStructures.h is not rewritten by tools/regenerate.py (unchanged since the step-25 move) and no file includes it; all includes use the hand-written src/Main/StructuralElementsDataStructures.h. It still contains the old EXUstd::GetSafely setters. Same kind of leftover as #2428. Deleting a tracked file needs the maintainer; the check of revision2026 step R4.18 covers item headers only. revision2026 step R4.20.

    • notes: src/Autogenerated/StructuralElementsDataStructures.h deleted (maintainer approval 2026-09-15); nothing included it.

    • date resolved: 2026-09-15 11:15, date raised: 2026-09-15

  • 1.11.59 CHANGE raised by: Claude-JG resolved by: Claude-JG one Python/C++ conversion layer for item and structure parameters (#2421)

    • description: The generated Main headers convert every item parameter twice (SetWithDictionary and SetParameter) through about 40 differently named PybindUtilities helpers (Get<Kind>IndexSafely - Set<Type>Safely - dict and value overloads); the generators pick the helper name from hand-written typeCasts/convertToDict tables. Item range checks exist only in itemInterface.py (165 CheckForValid calls) - so mbs.SetObjectParameter and mbs.AddObject with a raw dict bypass them - while structures check in C++ (EXUstd::GetSafelyUReal). revision2026 step R4.4.3: behaviour test first; new header src/Pymodules/PyConversion.h (FromPython/ToPython) kept separate from PybindUtilities.h; one destination-based type model in the generators; items and structures switch to it; range checks move to C++ with current behaviour kept (also in the fast build); return shapes kept (Real vectors numpy - Float4 and index arrays lists).

    • notes: revision2026 steps R4.4.3.1-R4.4.3.6: parameterConversionTest.py records the behaviour; src/Pymodules/PyConversion.h (FromPython/ToPython/ItemIndexFromPython/ItemIndexToPython/MemberGetter/MemberSetter) is the one conversion layer for generated item headers - structure members and the hand-written callers (MainSystem.cpp - MainSystemContainer.cpp - PyGeneralContact.h - solvers - symbolic); range checks in C++ with exudyn.special.exceptions.parameterRangeChecks; typeModel.py renders all type spellings; PybindUtilities.h 1104 -> 344 lines (forwarding block and 30 unused helpers deleted; kept: dict and type tests - GetSTDfunction - SetMatrixSafely - SetListOfArraysSafely - SetSlimArraySafely - reference numpy views).

    • date resolved: 2026-09-15 10:52, date raised: 2026-09-14

  • 1.11.58 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG unify the item/structure type exceptions of typeModel.py (#2429)

    • description: tools/generators/typeModel.py holds 36 spellings the rules do not produce (revision2026 step R4.4.3.3) - the same definition type is spelled differently for items and structures: Int is int for items and Index for structures; Float3/Float4 are exchanged as std::vector<float> for items and std::array<float n> for structures; NumpyVector/NumpyMatrix are stored as Vector/Matrix in items and py::array_t<Real> in structures; Vector2DList vs Vector3DList wrappers; Matrix2D reads Matrix2D in docs while the other fixed matrices read array_like; stub and dictType special names. Unify as far as possible - one spelling per type and destination - keeping each unification only if the full test suite and parameterConversionTest.py (apart from intended reference changes) do not fail; what must remain gets a comment with the reason. revision2026 step R4.19.

    • notes: typeModel.py exceptions reduced from 36 to 4: spellings that are the same for items and structures moved to a context-free names table (Int->Index; Py wrapper lists; dict type and stub vocabularies); KeyPressUserFunction joined definitionTypes.userFunctionSignatures; cppExchange has one rule for both contexts (variable sizes std::vector - fixed sizes std::array); item Float3/Float4 - ArrayIndex and Vector parameters convert through the same FromPython overloads as structure members (tuples accepted as before). Remaining: NumpyVector/NumpyMatrix storage (items store Vector/Matrix - structures only return py::array_t from solver functions). parameterConversionTest 0 differences; suite passed.

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

  • 1.11.57 CHANGE raised by: Claude-JG resolved by: Claude-JG item classes reject their own default values (#2426)

    • description: Recorded by parameterConversionTest.py (revision2026 step R4.4.3.1): 17 itemInterface classes raise ValueError when created with their defaults - e.g. MarkerNodeCoordinate(): coordinate=InvalidIndex() fails CheckForValidUInt; ObjectANCFThinPlate cannot be created with defaults in C++ either. The defaults carry two meanings: an index set later (closing a loop; valid only at CheckPreAssembleConsistency) and a value that must be given at creation (MarkerNodeCoordinate.coordinate; a default 0 would be dangerous). Suggestion: constructors never range-check an InvalidIndex() default; a new member flag in definitions/ marks must-be-given parameters and Add<Kind> raises for them in C++ naming item and parameter (same statement as the user line); set-later indices stay with CheckPreAssembleConsistency. revision2026 step R4.17.

    • notes: item classes construct with their defaults (since 34c4 b). New item flag CFMustBeGiven (Q) on the 25 parameters whose default lies outside their range form; definitionValidator rule 6 requires the flag exactly there. Add/SetWithDictionary raises: parameter MarkerNodeCoordinate.coordinate must be given; the default -1 is only a placeholder. The same switch as range checks turns it off. Docs mark these parameters. Set-later item indices are not range checked and stay with CheckPreAssembleConsistency.

    • date resolved: 2026-09-15 00:35, date raised: 2026-09-14

  • 1.11.56 BUG raised by: Claude-JG resolved by: Claude-JG item indices are accepted by float and bool parameters (#2425)

    • description: Recorded by parameterConversionTest.py (revision2026 step R4.4.3.1): float parameters (e.g. LoadCoordinate.load - SimulationSettings.solutionSettings.sensorsWritePeriod) accept a NodeIndex or ObjectIndex and store its number; bool parameters accept them as well. Maintainer decision 2026-09-14: reject them where this is simple. Applied with the unified conversion (34c4/34c5) as its own reference change. revision2026 step R4.16.

    • notes: Real - float and bool item parameters reject NodeIndex/ObjectIndex/MarkerIndex/LoadIndex/SensorIndex with a message naming item and parameter; Index parameters keep accepting them. parameterConversionTest: 618 intended changes (bool already rejected them). Structures follow in 34c5.

    • date resolved: 2026-09-15 00:35, date raised: 2026-09-14

  • 1.11.55 BUG raised by: Claude-JG resolved by: Claude-JG None is silently converted when written into item and structure parameters (#2424)

    • description: Recorded by parameterConversionTest.py (revision2026 step R4.4.3.1): every bool parameter accepts None and reads back False; index arrays - Vector3DList - Matrix3DList and PyMatrixContainer parameters accept None and read back empty. Maintainer decision 2026-09-14: None shall raise instead of converting unexpectedly; the test suite shows whether any model relies on it. Applied with the unified conversion (34c4/34c5) as its own reference change. revision2026 step R4.15.

    • notes: bool - Real - float and Index item parameters raise for None on every write path (message names item and parameter); index arrays raise instead of becoming empty. Vector3DList - Matrix3DList and PyMatrixContainer still accept None as empty because None is their default in itemInterface.py. parameterConversionTest: 672 intended changes (537 bool - 135 index list). Structures follow in 34c5.

    • date resolved: 2026-09-15 00:35, date raised: 2026-09-14

  • 1.11.54 EXTENSION raised by: Claude-JG resolved by: Claude-JG switch to disable parameter range checks at runtime (#2422)

    • description: Range checks on item and structure parameters (UReal - PReal - UInt - PInt) raise in both the normal and the fast build. A release can carry a wrong range limit that is hard to test for; a flag in exudyn.special could let a user switch the checks off manually. Needs the checks in one place first (revision2026 step R4.4.3). revision2026 step R6.5.

    • notes: exudyn.special.exceptions.parameterRangeChecks (default True) switches off the range checks of item parameters (all write paths; revision2026 step R4.4.3.4b) and of simulation/visualization settings (EXUstd::GetSafely…); the Python checks in itemInterface.py are gone

    • date resolved: 2026-09-15 00:00, date raised: 2026-09-14

  • 1.11.53 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG four generated item headers in src/Autogenerated have no generator and no user (#2428)

    • description: MainMarkerBody.h - MainMarkerGenericBodyPosition.h - MainObjectContactFrictionCircleCable2DOld.h - MainObjectJointSliding2DNew.h are tracked but no longer written by itemHeaderEmitter.py (their items are not in definitions/) and no .h or .cpp includes them; MainMarkerBody.h still calls HPyUtils::SetStringSafely. Found in revision2026 step R4.4.3.4 when counting the helper calls left in the generated headers. Deleting tracked files needs the maintainer; the drift gate should also report generated files that no generator writes. revision2026 step R4.18.

    • notes: the twelve C/Main/Visu headers of MarkerBody - MarkerGenericBodyPosition - ObjectContactFrictionCircleCable2DOld - ObjectJointSliding2DNew deleted; itemHeaderEmitter.py now raises for any item header in src/Autogenerated whose item has no definition

    • date resolved: 2026-09-14 23:53, date raised: 2026-09-14

  • 1.11.52 BUG raised by: Claude-JG resolved by: Claude-JG hand-written enum string functions had drifted from their enums (#2420)

    • description: Joint::GetTypeString tested consecutive values as bits (RevoluteZ=3 gave RevoluteXRevoluteY; PrismaticX=4 gave RevoluteZ) and named Marker in its error; Node::GetTypeString omitted GenericODE1 and GenericAE; operator<< for ItemType printed nothing for an invalid value; the Python enum lists carried keep-synchronized comments. Now generated from definitions/enumTypes.py (revision2026 step R4.3 part 2d)

    • notes: C++ enums and string functions generated into src/Autogenerated/EnumTypes.h from definitions/enumTypes.py; Python enums read the same table

    • date resolved: 2026-09-14 14:39, date raised: 2026-09-14

  • 1.11.51 BUG raised by: Claude-JG resolved by: Claude-JG pybind declarations: argTypes shorter than argList and a duplicated symbolic.max (#2419)

    • description: definitionValidator (revision2026 step R4.3 part 2d) finds: MainSystem.DeleteNode / DeleteSensor and MatrixContainer.SetWithDenseMatrix list fewer argTypes than arguments - so their stubs lose all type hints; symbolic.max is declared twice (twice in symbolic.pyi and the docs); exu.Print has argTypes without argList (unused)

    • notes: definitionValidator checks the pybind declarations; argTypes completed for DeleteNode / DeleteSensor / SetWithDenseMatrix; duplicate symbolic.max and unused Print argTypes removed

    • date resolved: 2026-09-14 14:29, date raised: 2026-09-14

  • 1.11.50 CHECK raised by: Claude-JG resolved by: Claude-JG VSettingsNodes.showNodalSlopes is a boolean flag declared as UInt (#2416)

    • description: The parameter is declared UInt and initialised with false; its description is “draw nodal slope vectors; e.g. in ANCF beam finite elements” and every neighbouring show… flag is a bool. Generated as Index showNodalSlopes = false; (src/Autogenerated/VisualizationSettings.h:525 and :544); with a GetSafelyUInt range check on assignment; so Python accepts any non-negative integer where only 0 and 1 mean anything; and the settings dialog offers an integer field instead of a checkbox. Found while converting default values into real Python values (revision2026 step R4.1.7): it is the only boolean default in the whole definition set that does not sit on a bool type - 370 of 371 do. Changing the type changes the generated C++; the Python type hint and the dialog; so it is a separate decision rather than part of that step.

    • notes: copy-paste error confirmed by the maintainer; the type is now bool. Generated as bool showNodalSlopes; the PySet wrapper with its GetSafelyUInt range check is gone and the stub says bool instead of int. All four C++ uses (VisuNodePoint.cpp:677-802) were already boolean tests. Full rebuild and runTestSuite.py PASSED.

    • date resolved: 2026-09-13 21:48, date raised: 2026-09-13

  • 1.11.49 BUG raised by: Claude-JG resolved by: Claude-JG GetOutputVariableTypeString has no case for CoordinatesTotal (#2408)

    • description: OutputVariableType::CoordinatesTotal (bit 14) is in the C++ enum; it is exposed to Python via AddEnumValue and it is used by 7 item definitions. But GetOutputVariableTypeString() in src/Main/OutputVariable.h has no case for it; it falls through to default: which raises SysError(“invalid variable type”) and returns “Invalid”. Reachable from user-facing paths: CSolverBase.cpp:1960 writes “#OutputVariableType = Invalid” into the sensor solution file header; VisualizationSettings.h:486 prints it in the settings dump. Found while measuring the four hand-synced OutputVariableType lists for revision2026 step R4.1; the planned registrator step makes this class of drift impossible. Also noted: KineticEnergy and PotentialEnergy exist in the enum and in GetOutputVariableTypeString but are NOT exposed via AddEnumValue - a question for the maintainer rather than a defect.

    • notes: fixed by the OutputVariableType registrator (revision2026 step R4.1.4): the enum, GetOutputVariableTypeString(); IsOutputVariableTypeForReferenceConfiguration() and the Python enum are now all generated from definitions/outputVariableTypes.py; so a value can no longer exist without a string. Verified: a sensor on CoordinatesTotal writes OutputVariableType = CoordinatesTotal into its solution file header instead of Invalid.

    • date resolved: 2026-09-13 18:28, date raised: 2026-09-13

  • 1.11.48 FIX raised by: Claude-JG resolved by: Claude-JG NodeRigidBodyRotVecLG documents size 3 for three Vector6D parameters (#2410)

    • description: referenceCoordinates, initialCoordinates and initialVelocities of NodeRigidBodyRotVecLG are declared with type Vector6D but size 3, so the generated reference tables publish “type = Vector6D, size = 3”. Everything else says 6: the class description (“3 displacement coordinates and three rotation coordinates”), GetNumberOfODE2Coordinates returns 6, the default value has six entries, and the LaTeX symbol lists six components. The size column is simply wrong in the published documentation. Note that size is currently used for documentation only and is validated nowhere - see the generator note “future: also add size check …” at pythonAutoGenerateObjects.py:904 - which is why this could go unnoticed. Found during revision2026 step R4.1.2, where shape becomes part of the type and the two can no longer disagree.

    • notes: corrected at the source: objectDefinition.py lines 397-399 declared size 3 for three Vector6D members of NodeRigidBodyRotVecLG; the sibling NodeRigidBodyEP block correctly says 6. Regenerated; only the documentation tables changed (tier 1 API surface byte-identical).

    • date resolved: 2026-09-13 16:38, date raised: 2026-09-13

  • 1.11.47 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG setupPyConfig.json was tracked and mutable: CI rewrote it mid-build and an sdist build used different switches (#2407)

    • description: the six build switches had three sources with no written precedence: defaults in setup.py; the committed JSON; and CLI flags. Three consequences. tools/ci/buildManylinux.sh had to rewrite the tracked file with sed and restore it from a trap; so a failed build left the working tree dirty - and revision2026 step R2.4 shipped the maintainers local toggles inside the sdist. The defaults disagreed with the committed file (compileParallel and quietCompile were False in setup.py and True in the JSON); so a build WITHOUT the file - an sdist build; legitimately - silently took a slower and louder path than the maintainer runs. And the CLI could only turn switches ON; with quietCompile committed as True there was no way to ask for a verbose build. revision2026 step R2.14

    • notes: the file is deleted. Defaults now live in [tool.exudyn] in pyproject.toml as real booleans - the True-as-a-string schema of revision2026 step R2.8 went with the JSON that needed it - and resolution is four explicit layers: command line > environment > [tool.exudyn] > built-in default. buildManylinux.sh exports EXUDYN_COMPILE_EXUDYN_FAST=0 instead of sed plus trap; nothing is written to disk during a build. Every flag now has both forms (–quiet/–no-quiet etc.); the historical –noglfw and –nofast spellings are kept. tomli is in build-system.requires with a python_version < 3.11 marker because CI builds cp310 and tomllib is stdlib only from 3.11; a missing TOML parser raises an ImportError naming the install command rather than falling back to different defaults. All four layers were proven separately; the working-tree fingerprint is byte-identical before and after a build with the CI override; and the sdist now carries the maintainers switches instead of the old silent fallback

    • date resolved: 2026-09-12 22:52, date raised: 2026-09-12

  • 1.11.46 FIX LOW raised by: Claude-JG resolved by: Claude-JG setup.py sdist drops an untracked copy of LICENSE.txt into main/ (#2384)

    • description: running python setup.py sdist creates main/LICENSE.txt; byte-identical to the repository root LICENSE.txt and not tracked; so it shows up as an untracked file after every sdist and is easy to commit by accident. Reproduced by deleting it and running sdist again. It is either a build artifact that belongs in .gitignore; or a second copy of the licence that should not exist at all - which revision2026 step R3.1 (flattening the packaging root) would settle. Found during revision2026 step R2.4

    • notes: no longer reproduces: it was setup.py reaching for ../LICENSE.txt and dropping the copy inside main/, and the flatten removed that level. setup.py now contains no LICENSE handling at all; MANIFEST.in includes the one file at the repository root, which is where it belongs and where the sdist picks it up. Confirmed after three sdist builds in this session: exactly one LICENSE.txt exists in the working tree, tracked, unmodified since e44aca1, and no untracked copy appears anywhere

    • date resolved: 2026-09-12 19:52, date raised: 2026-09-11

  • 1.11.45 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG issue text ending a word with an underscore breaks the generated RST and the docs CI job (#2401)

    • description: docs/RST/trackerlog.rst is generated from the tracker; and RST reads a trailing underscore as a link reference. The description of issue 2390 contains CIBW followed by an underscore; so sphinx reports ERROR: Unknown target name “cibw” at trackerlog.rst line 69. The docs CI job runs sphinx-build with -W –keep-going; so this fails the nightly pipeline. Introduced by my own issue text in commit 422ab48. The conversion should escape trailing underscores when writing issue descriptions rather than relying on issue authors to avoid them. Found while verifying the docs build for revision2026 step R3.1

    • notes: EscapeRSTmarkup in issueTracker.py now escapes what the shared LatexString2RST does not: a word-final underscore, which RST reads as a link reference, and an unpaired backtick. The notes field additionally now passes replaceMarkups=True like description already did, which is what let a lone asterisk through - the flatten issue mentioned *.md and opened an inline emphasis that never closed. Applied only at the five RST seams of the tracker, so the shared generator behaviour the rest of the documentation depends on is unchanged. Verified with the CI setting itself: sphinx-build -W –keep-going now exits 0 with no warning at all, where it previously reported Unknown target name cibw and an emphasis start-string

    • date resolved: 2026-09-12 19:50, date raised: 2026-09-12

  • 1.11.44 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG version.txt moved from docs/theDoc to the repository root (#2406)

    • description: the single version source sat inside the documentation tree; a build input buried among LaTeX chapters and - before the flatten - above the packaging root. It is now version.txt at the repository root; exudynVersion.py is the only code that resolves it and doc2rst.py keeps parsing it as a documentation input. revision2026 step R3.4

    • notes: moved with git mv. exudynVersion.py resolves it by walking up for a directory holding both pyproject.toml and version.txt; issueTracker.py writes it there; doc2rst.py special-cases it in the parsed-file loop because every other entry in that list is a LaTeX chapter under docs/theDoc/. regenerate.py excludedPaths, MANIFEST.in and the seven untracked build scripts follow. versionName.txt deliberately stays in docs/theDoc/: nothing builds from it

    • date resolved: 2026-09-12 19:36, date raised: 2026-09-12

  • 1.11.43 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG exudynVersion.py guessed four relative paths and fell back to the version string unknown (#2405)

    • description: it tried ../../../, ../../, ../ and ./ in sequence for docs/theDoc/version.txt and set version = unknown when all four missed. unknown is not a version: setuptools rejects it much later with an InvalidVersion naming neither this file nor version.txt, and a generator run would stamp it into generated sources instead of failing. revision2026 step R3.4

    • notes: replaced by one resolver anchored on the repository root: it walks upwards from __file__ (and from the working directory; setup.py and conf.py exec() this file, so __file__ is the executing script there) for a directory holding both pyproject.toml and docs/theDoc/version.txt. Missing or empty is now a RuntimeError naming the file and everything searched. Verified from the repository root, from src/pythonGenerator, and from a directory outside the repository where it now raises instead of returning unknown

    • date resolved: 2026-09-12 19:04, date raised: 2026-09-12

  • 1.11.42 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG the source distribution contains no C++ headers and cannot build (#2383)

    • description: python setup.py sdist produces an archive with all 133 .cpp files but ZERO of the 432 .h files under main/src (measured on 1.11.24.dev1: 200 entries total). So the sdist on pypi.org cannot be compiled by anyone. MANIFEST.in has no graft/recursive-include for the headers; and setuptools does not add them automatically for an Extension. Pre-existing; found while adding sources.json to the sdist for revision2026 step R2.4

    • notes: the sdist now builds and installs. Three things were missing once the flatten made them reachable: docs/theDoc/version.txt and LICENSE.txt (both sat above the old packaging root), and src/pythonGenerator/autoGenerateDocstrings.py; setup.py load_converter() raises FileNotFoundError on that one and stops the build. stubHeader.pyi and the five generated .pyi inputs were added as well; without them every sdist install shipped an unmerged __init__.pyi. The remaining blocker was #2376. Verified end to end: sdist built, then pip wheel from the tarball in a clean directory produced exudyn-1.11.40.dev1-cp313-cp313-win_amd64.whl; installed to a separate target; import exudyn reports 1.11.40.dev1 and a SystemContainer runs

    • date resolved: 2026-09-12 19:04, date raised: 2026-09-11

  • 1.11.41 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG setup.py leaves the working directory changed when stub generation fails (#2376)

    • description: the block around setup.py line 24 does os.chdir into src/pythonGenerator and restores the directory INSIDE the try; the bare except then swallows the failure; so if createStubFiles.py raises; the rest of setup.py runs in the wrong working directory and every later relative path is wrong. Restore belongs in a finally. Found during revision2026 step R2.2

    • notes: the stub-file block now restores the working directory in a finally, and reports the actual exception instead of a bare except with a fixed message. This was the real reason the sdist could not be built: createStubFiles.py failed on a missing stubHeader.pyi, the process stayed in src/pythonGenerator, and the next two steps then reported no setupPyConfig.json found and src/Autogenerated/versionCpp.cpp: No such file or directory - two misleading errors from one unrelated cause, and the package metadata degraded to the name UNKNOWN

    • date resolved: 2026-09-12 19:04, date raised: 2026-09-11

  • 1.11.40 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG the Python 3.14 CI job never compiles exudyn: the scipy pin has no 3.14 wheel (#2404)

    • description: buildManylinux.sh pins scipy==1.15.2 because newer releases have a much slower sparse eigenvalue solver (revision2026 fact 19). There is no cp314 wheel of 1.15.2; so pip built it from source and meson aborted with Dependency OpenBLAS not found. The job therefore failed in the dependency install step - exudyn itself was never compiled and no 3.14 result exists at all. Seen in the nightly GitLab run of 2026-09-12 for 1.11.31

    • notes: the pin now carries a PEP 508 marker: scipy==1.15.2 for python_version < 3.14 and an unpinned scipy at or above it. The pin exists for speed and 3.14 had no result at all; so an unmeasured scipy there is strictly better than no build. Re-pin once a fast-enough 3.14 wheel exists

    • date resolved: 2026-09-12 17:03, date raised: 2026-09-12

  • 1.11.39 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG two TestModels fail reproducibly on Linux and are not marked UnresolvedOnLinux (#2379)

    • description: generalContactImplicit1.py (error -5.310e-08) and sliderCrank3Dbenchmark.py (-5.037e-10) fail under manylinux_2_28 cp313 while the 8 other Linux differences are marked UnresolvedOnLinux and excluded. So the Linux build exits non-zero. Confirmed PRE-EXISTING and unrelated to revision2026 step R2.3: a build at the previous commit produced bit-identical values. Either the two belong on the UnresolvedOnLinux list with a reason; or the underlying difference needs investigation

    • notes: both tests are now on the UnresolvedOnLinux list with their measured relative differences (sliderCrank3Dbenchmark 2.0e-10; generalContactImplicit1 6.8e-08); so the Linux job reports FAILEDL and exits zero while Windows still enforces them. This records the difference - it does not explain it; the underlying Windows/Linux divergence stays scheduled for revision2026 phase R10, and the list is meant to shrink

    • date resolved: 2026-09-12 17:03, date raised: 2026-09-11

  • 1.11.38 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG stale project naming and no way to keep an experimental pytest.py out of commits (#2403)

    • description: after the flatten the Python project was still called pythonDev (python/pythonDev.pyproj, Name and RootNamespace pythonDev) although the directory is python/, its SearchPath pointed at ..\pythonDev which no longer exists, and it listed a Content item requirements.txt that has never existed in that directory (Visual Studio shows it with an exclamation mark). Separately: pytest.py is the scratch file used to try out features in MSVC with mixed debugging, the old practice was to overwrite the experimental version with the default one before committing, which is easy to forget and invisible in review. The solution file was likewise committed under the name main_sln_Template.sln while being the file actually opened. Maintainer request; found during revision2026 step R3.1

    • notes: project renamed to python/exudynPython.pyproj with Name and RootNamespace exudynPython, SearchPath corrected to ., the dangling requirements.txt Content item removed - the dependency lists are the extras in pyproject.toml and a second source would only go stale. The template/local pattern now covers both scratch files: exudynTemplate.sln and python/pytestTemplate.py are committed, exudyn.sln and python/pytest.py are in .gitignore, and tools/setupLocalWorkspace.py creates the local copies from the templates without ever overwriting an existing file. An experiment therefore cannot be committed by accident. Documented in docs/dev/WORKFLOW.md section 0a and in docs/dev/README.md

    • date resolved: 2026-09-12 16:54, date raised: 2026-09-12

  • 1.11.37 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG flatten the repository: remove the main/ level (#2402)

    • description: everything lived under main/ - src; include; libs; obj; pythonDev and the packaging files - so every path in every tool carried a main/ prefix; the packaging root was one level below the repository root (which is why the sdist cannot find version.txt; issue 2383) and the generators addressed the root as ../../../. revision2026 steps R3.1 and R3.2

    • notes: 1477 tracked files moved with git mv; recorded as 1475 pure renames: main/src->src; main/include->include; main/libs->libs; main/obj->msvc; main/pythonDev->python and the packaging files to the root. The vcxproj needed NO change - all 541 of its ClCompile/ClInclude entries are ..\src... and msvc/ and src/ remain siblings; so only the two project references in the .sln moved. Repaired: 26 relative paths in the generators (the root went from ../../../ to ../../); doc2rst destDir; the autoGenerateHelper import path in issueTracker.py; regenerate.py; gen_sources.py; checkExtras.py; setup.py; MANIFEST.in; pyproject.toml; conf.py; .gitlab-ci.yml; wheels.yml and buildManylinux.sh. MANIFEST.in include *.md became include README.md; because at the root the wildcard would have swept CLAUDE.md into the sdist. VERIFIED: wheel builds in 58.9 s with 133 sources and the correct package layout, full test suite passes, gen_sources –check and checkExtras –check pass, sphinx builds the documentation. NOTE regenerate.py –check cannot be meaningful until the move is in HEAD; because it compares each file against HEAD:<path> and every path is new - the regenerated content was confirmed byte identical to HEAD at the old paths instead

    • date resolved: 2026-09-12 16:06, date raised: 2026-09-12

  • 1.11.36 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG performance suite reports only a single total and had no large system test (#2399)

    • description: the suite printed CPU TIME per test scattered through the output and one total at the end; so it was impossible to see which kind of work a change had affected. All six tests were also overhead dominated or mid sized; four of them are a handful of coordinates run for about 1e6 steps. revision2026 step R2.10; maintainer request

    • notes: tests are now grouped as small (few coordinates; ~1e6 steps; measures per step overhead) and large (many coordinates; few steps; measures the work per step where long vectors and AVX2 are visible); and the suite prints a table of every test with its group; its time and its share of the total; plus a subtotal per group. A new large test perfLargeMassSpringChain.py was added: 2000 point masses; 6000 ODE2 coordinates; explicit Euler; deterministic (repeated runs bit identical) and about 4.8 s on Windows. All 7 performance tests pass

    • date resolved: 2026-09-12 14:29, date raised: 2026-09-12

  • 1.11.35 DOCU LOW raised by: Claude-JG resolved by: Claude-JG the comment claiming -mavx2 does not compile on Linux is stale (#2395)

    • description: setup.py:146 says “-mavx2 (does not compile)” and suspects memory alignment. Measured 2026-09-12: the full extension builds cleanly in manylinux_2_28 with -mavx2 -mfma on g++ 14; 567 vfmadd instructions are present in the resulting .so. What actually fails is at runtime and is a genuine alignment defect; see the LinkedDataVector issue. The comment should be corrected so the next reader does not conclude the toolchain is at fault

    • notes: comment at setup.py:146 corrected: -mavx2 does compile; the failure was at runtime and was the alignment defect of issue 2394. The comment now says so and points at revision2026 step R2.10 for the decision to enable AVX2 on Linux; and at the FMA rounding issue

    • date resolved: 2026-09-12 12:48, date raised: 2026-09-12

  • 1.11.34 BUG HIGH raised by: Claude-JG resolved by: Claude-JG misaligned __m256d load in ResizableVectorParallel MultAdd with a LinkedDataVector (#2394)

    • description: REPRODUCED 2026-09-12 in manylinux_2_28 cp313 with g++ 14 and -mavx2 -mfma -fsanitize=alignment -fno-sanitize-recover=alignment: src/Linalg/ResizableVectorParallel.h:309:28 runtime error: load of misaligned address for type __m256d which requires 32 byte alignment; in ResizableVectorParallelBase<double>::MultAdd<LinkedDataVectorParallelBase<double>> called from CSolverImplicitSecondOrderTimeInt::ComputeNewtonUpdate. Column 28 is the ptrVector[i] operand; that is the LinkedDataVector; not the ResizableVector. The cause is NOT the allocator: EXUDYN_USE_ALIGNED_VECTORS is enabled and VectorBase allocates through _aligned_malloc/posix_memalign; but a LinkedDataVector points into another buffer at an arbitrary element offset; so no allocator can make the sub-range 32 byte aligned. The observed pointer was 8 byte aligned. Latent today because AVX2 is only enabled on Windows (setup.py:230-233); it is what blocks enabling AVX2 on Linux. Fix is to use unaligned intrinsics (_mm256_loadu_pd/_mm256_storeu_pd) on the linked operands; which cost nothing on aligned data on Haswell and later. revision2026 step R2.9

    • notes: fixed by replacing aligned PReal* dereference with explicit unaligned load/store in every AVX loop whose pointer can come from a LinkedDataVector: all 40 casts in LinkedDataVectorParallel.h and ResizableVectorParallel.h; plus the six ParallelPReal* helpers in Vector.cpp; whose PReal* parameters had the same problem without a cast to find them by. Use_avx.h gained _mm_store_u for all four AVX variants (only _mm_load_u existed) and both for the scalar fallback; the arithmetic still uses operators; which work for __m256d and for plain Real alike. VERIFIED: (1) the manylinux cp313 build with -mavx2 -mfma -fsanitize=alignment -fno-sanitize-recover=alignment previously aborted at ResizableVectorParallel.h:309 and now reports ZERO misalignment errors and runs the suite to completion, (2) the same build without -mavx2 reproduces the previous Linux results BIT FOR BIT - same two known failures with identical values - so the change is numerically neutral, (3) on Windows; where AVX2 is live today; the full test suite passes and runPerformanceTests gives 33.33 s against a 33.04-34.16 s baseline measured twice before the change; i.e. inside the run to run noise

    • date resolved: 2026-09-12 12:48, date raised: 2026-09-12

  • 1.11.33 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG setupPyConfig.json is not validated: a typo silently changes the build (#2393)

    • description: setup.py warned about an unknown key or an illegal value and then continued with the default. So “compileParallell”: “True” produced a serial build minutes slower with nothing in the output explaining why; and the outer bare except also swallowed genuine read errors. revision2026 step R2.8

    • notes: setupPyConfig.json is now validated against the default config dict; which IS the schema: unknown key; value other than the strings “True”/”False”; a non object document or malformed JSON each raise with the offending key named and the valid keys listed. A MISSING file remains a warning using defaults; because building from an sdist legitimately has no config file - only a file that is present but wrong is fatal. The bare except is narrowed to OSError/JSONDecodeError. Verified by fault injection: unknown key, lowercase “true”, malformed JSON each exit 1 with a specific message, a missing file still builds, the committed file builds a wheel in 55.7 s, and the sed rewrite that tools/ci/buildManylinux.sh applies to compileExudynFast still validates

    • date resolved: 2026-09-12 11:56, date raised: 2026-09-12

  • 1.11.32 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG issueTracker does not report the number it assigned (#2392)

    • description: RaiseIssue and ResolveIssue printed no issue number; so the number had to be reconstructed by hand for the commit message and the documentation. That produced five wrong numbers in the revision plan; the log and two commit messages on 2026-09-12 (the ClInclude defect was written as 2388 but is 2387; and four following issues were likewise one too high). Maintainer request

    • notes: RaiseIssue now returns the assigned number and RaiseIssueDict prints “issue raised: #NNNN title”; ResolveIssue prints “issue resolved: #NNNN title” before the dict and returns the number. So the number never has to be guessed again

    • date resolved: 2026-09-12 11:56, date raised: 2026-09-12

  • 1.11.31 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG continue-on-error made failing wheel builds report success (#2391)

    • description: build_wheels carried continue-on-error: true; so a job that failed to build or whose test suite failed did not fail the workflow. fail-fast: false is what actually keeps the sibling jobs running; continue-on-error only hid the result. revision2026 step R2.7

    • notes: continue-on-error removed. fail-fast: false is kept; so one failing wheel still does not cancel the others - but the workflow now reports the failure

    • date resolved: 2026-09-12 10:01, date raised: 2026-09-12

  • 1.11.30 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG move the cibuildwheel configuration into [tool.cibuildwheel] (#2390)

    • description: the wheel matrix was configured through eleven CIBW_ environment variables in .github/workflows/wheels.yml; where nothing validates them: a lost newline had swallowed CIBW_BUILD_VERBOSITY: 1 into the trailing comment of the CIBW_TEST_SKIP line; so build verbosity was silently never set. revision2026 step R2.7

    • notes: the ten static settings moved to [tool.cibuildwheel] in main/pyproject.toml; with linux; macos and windows subtables for the per platform test-command; before-all and environment. Only CIBW_BUILD stays in the workflow; because it is built from the matrix entry. build-verbosity = 1 now actually applies. Verified with the pinned cibuildwheel 3.4.1: –print-build-identifiers returns the same set for all three platforms as the old environment variables did (cp313-manylinux_x86_64, cp313-macosx_universal2, cp313-win_amd64), the resolved options show build-verbosity 1, the test requirements, the dnf before-all on linux only and the cd /d form of the test command on windows, and a deliberately misspelled key is rejected with “Option build-verbosityy not supported in a config file” instead of being ignored

    • date resolved: 2026-09-12 10:01, date raised: 2026-09-12

  • 1.11.29 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG remove 32 bit support: libs/libs32 and the bitness branch in setup.py (#2389)

    • description: follow up to issue 2386; whose resolution note still says setup.py keeps its is32bits branch - that is no longer true. On the maintainer instruction the 32 bit support is removed outright: main/libs/libs32 (glfw.pdb; glfw3.lib; glfw3_d.lib; openvr_api.dll; openvr_api.lib) and the is32bits/is64bits branch in setup.py; whose only remaining effect was to choose that directory. revision2026 step R2.6

    • notes: the five libs32 files deleted and the bitness branch replaced by an explicit failure: a 32 bit interpreter now raises immediately with the reason; instead of falling through to the 64 bit import libraries and producing “DLL load failed: %1 is not a valid Win32 application” at import time - a symptom gettingStarted.tex documents in its troubleshooting section; far from its cause. The openVR path also loses its dead 32 bit half; which copied the 64 bit DLL while warning that 32 bit openVR was untested. Verified by a full wheel build (133 files) and the complete test suite. The installation guide still describes choosing between 32 and 64 bit and was deliberately not touched; that is issue 2389

    • date resolved: 2026-09-12 00:08, date raised: 2026-09-12

  • 1.11.28 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG drop the ReleaseP37 and Win32/x86 build configurations (#2386)

    • description: the solution and cppsrc.vcxproj carried six configurations: Debug; Release and ReleaseP37 times Win32 and x64. ReleaseP37 is the last artefact of Python 3.7 support and no 32 bit wheel has been built for years; so four of the six were dead weight that every vcxproj edit had to be repeated in. revision2026 step R2.6

    • notes: six configurations reduced to two; Debug|x64 and Release|x64. Removed from cppsrc.vcxproj the four ProjectConfiguration declarations and every PropertyGroup; ImportGroup and ItemDefinitionGroup conditioned on them (853 -> 660 lines); rewrote both GlobalSections of main_sln_Template.sln; and dropped the ReleaseP37 PropertyGroup from pythonDev.pyproj. Verified: all three files still parse as XML; the 133 ClCompile entries are untouched and still match sources.json; and MSBuild evaluates both surviving configurations without error - Release|x64 resolving to ConfigurationType DynamicLibrary; TargetExt .pyd; PlatformToolset v143 and OutDir bin/x64/Release. requires-python also moved from >=3.6 to >=3.10; which revision2026 step R2.11 had deferred to here: CI builds cp310-cp314 and no 3.6 wheel has existed for years. setup.py keeps its is32bits branch; it reacts to the running interpreter rather than to a VS configuration; and removing 32 bit support outright is not part of this step

    • date resolved: 2026-09-12 00:01, date raised: 2026-09-12

  • 1.11.27 IMPROVEMENT NORMAL raised by: Claude-JG resolved by: Claude-JG remove the three dead CMakeLists files (#2385)

    • description: none of the three could configure; let alone build. main/CMakeLists.txt was a fourth complete copy of the 133 file source list and called add_subdirectory(pybind11) on a directory that does not exist; its own header said “CMakeLists for Exudyn are not complete”. main/src/CMakeLists.txt and main/obj/autoCMakeLists.txt listed 63 of 133 files; missed 74; referenced sources deleted years ago (StaticSolver.cpp; CNodeRigidBody.cpp; solver/TimeIntegrationSolver.cpp) and used add_executable although exudyn is a Python module. Decision D3 keeps the .sln and .vcxproj and drops CMake. revision2026 step R2.5

    • notes: all three deleted (405 lines). main/include/Eigen/CMakeLists.txt is vendored third-party and was left untouched. No generator recreates them. The only reference in the documentation was one passing mention in docs/theDoc/gettingStarted.tex; which now names scikit-build-core alone rather than pointing at files that no longer exist. This also removes the last duplicate of the source list that revision2026 step R2.4 consolidated into main/sources.json

    • date resolved: 2026-09-11 23:52, date raised: 2026-09-11

  • 1.11.26 FIX NORMAL raised by: Claude-JG resolved by: Claude-JG cppsrc.vcxproj listed src/tests/UnitTestBase with the wrong case (#2382)

    • description: the vcxproj had ClCompile ..\src\tests\UnitTestBase.cpp and ClInclude for the header; while the tracked directory is src/Tests. Windows resolves both to the same file so it was invisible there; Linux does not. It did not break the manylinux build only because setup.py had its own list with the correct case. Found by tools/gen_sources.py; revision2026 step R2.4

    • notes: corrected to src\Tests\UnitTestBase for both the ClCompile and the ClInclude entry. tools/gen_sources.py –check now fails on any case mismatch; so this cannot silently return

    • date resolved: 2026-09-11 22:46, date raised: 2026-09-11

  • 1.11.25 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG derive the compile list from the vcxproj instead of duplicating it in setup.py (#2381)

    • description: setup.py carried a hand-maintained list of 133 .cpp paths in two literal Python lists; a second copy of the ClCompile entries of main/obj/cppsrc.vcxproj with nothing keeping the two in agreement. revision2026 step R2.4

    • notes: tools/gen_sources.py derives main/sources.json from the ClCompile entries of cppsrc.vcxproj; reading only ItemGroup blocks so every PropertyGroup setting stays hand-maintained. setup.py reads the JSON and no longer contains a source list; no XML is parsed at build time and the JSON ships in the sdist via MANIFEST.in. –check compares vcxproj; JSON and the files on disk and is run in CI as check_sources; the comparison is case-exact; because a wrong-case entry resolves on Windows and fails on Linux. The minimal subset cannot be expressed in the vcxproj; so it is carried in the JSON and validated as a subset. Verified: wheel builds in 57.3 s with 133 files and the full test suite passes; the checker was fault injected with a stale JSON entry and a nonexistent vcxproj entry; and it caught a real wrong-case entry on its first run (issue #2382)

    • date resolved: 2026-09-11 22:46, date raised: 2026-09-11

  • 1.11.24 BUG NORMAL raised by: Claude-JG resolved by: Claude-JG parallel-compile monkeypatch: thread-unsafe output and swallowed errors (#2378)

    • description: four defects in the parallel compile patch in setup.py. (1) on Linux the quiet path rebound the GLOBAL sys.stdout from every worker thread; each opening setuppy.output.txt with mode w; so threads truncated each other and the restore raced. (2) the outer bare except also swallowed KeyboardInterrupt/SystemExit and its message “trying serial compilation” described the compile; although it only wraps installing the patch. (3) the Windows handler did “raise ValueError(args)”; destroying the compiler CompileError and its message. (4) nObjects = len(objects)+2 made the progress counter report 135 for 133 files. revision2026 step R2.3

    • notes: the per-file redirect is replaced by one contextlib.redirect_stdout around the whole thread pool (the shape the Windows branch already used); and contextlib also restores sys.stdout when a compile raises; which the old “sys.stdout = sys.__stdout__” after the with-block did not. Progress now goes to sys.__stdout__ so it stays on the console rather than in the log. The Windows handler prints the command line and re-raises; keeping the compiler diagnostic. The outer except is now except Exception and says what it actually covers. nObjects = len(objects). The monkeypatch itself is KEPT: setuptools parallelises build_ext across extensions; not across sources within one; and exudyn has 133 sources in a single extension. Verified on both platforms: Windows wheel 56.8 s (unchanged); manylinux cp313 build plus test suite bit-identical to the previous commit; and a quiet Linux build reporting completed 001/133 .. 133/133

    • date resolved: 2026-09-11 21:27, date raised: 2026-09-11

  • 1.11.23 EXTENSION NORMAL raised by: Claude-JG resolved by: Claude-JG optional-dependency extras with a drift checker (#2375)

    • description: there was no way to install the packages needed for the tests or referred to internally; and no mechanism to notice when the code starts importing something that no declared list installs. revision2026 step R2.12

    • notes: [project.optional-dependencies] adds tests / all / rl; all built on the PEP 508 self-reference exudyn[tests]. tools/checkExtras.py AST-scans TestModels; exudyn and Examples and fails when an import is installed by no extra; run in CI as check_extras. Verified by fault injection: a fake import; a removed extra entry and a deleted name-mapping entry each reported with exit 1. rl is deliberately not part of all (torch size and the –index-url CUDA choice); confirmed that allExudynModulesTest.py announces the resulting skip rather than passing vacuously

    • date resolved: 2026-09-11 20:12, date raised: 2026-09-11

  • 1.11.22 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG package metadata drift: classifiers and MANIFEST.in (#2374)

    • description: classifiers claimed Python 3.9-3.13 while CI builds cp310-cp314; and MANIFEST.in contained include ../LICENSE.txt which points outside the sdist root and is a silent no-op; so the licence has not been in the sdist. revision2026 step R2.11

    • notes: classifiers now 3.10-3.14; matching the wheels CI actually builds. requires-python deliberately left at >=3.6 for revision2026 step R2.6. The unreachable MANIFEST.in include was replaced by a comment stating why the licence is absent and that revision2026 step R3.1 is what makes the include possible

    • date resolved: 2026-09-11 20:12, date raised: 2026-09-11

  • 1.11.21 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG pybind11 into build-system.requires (#2373)

    • description: setup_requires is deprecated and was the only thing fetching the pybind11 headers (into main/.eggs). The documented include path include/pybind11 does not exist and the vendored copy at include/pybind11local is inert; so an undeclared download was load-bearing. revision2026 step R2.2

    • notes: pybind11<3.0 moved to build-system.requires; setup_requires removed; the dead include/pybind11 path deleted; and get_pybind_include now raises an actionable ImportError naming the install command. Verified by moving main/.eggs away: the build failed with the new message; after pip install pybind11 the wheel built in 55 s and .eggs was NOT recreated. condaEnvironments.md now installs pybind11 explicitly; because build-system.requires is honoured only under build isolation and setup.py bdist_wheel has none

    • date resolved: 2026-09-11 20:12, date raised: 2026-09-11

  • 1.11.20 CHANGE NORMAL raised by: Claude-JG resolved by: Claude-JG PEP 621 metadata (#2371)

    • description: move static package metadata from setup(…) into a [project] table in main/pyproject.toml; setup.py keeps only version; classifiers; packages; package_data; ext_modules and cmdclass. build-system.requires floor raised to setuptools>=61; below that a [project] table is silently ignored. revision2026 step R2.1

    • notes: verified by diffing PKG-INFO from setup.py egg_info before and after: only the PEP 621 spellings changed (Author/Home-page -> Author-email/Project-URL) and the Dynamic: block shrank from ten entries to one. A full wheel built in 54 s with the .pyd and both .pyi stubs present

    • date resolved: 2026-09-11 18:24, date raised: 2026-09-11

  • 1.11.19 BUG raised by: Claude-JG resolved by: Claude-JG generated documentation depends on the filesystem listing order (#2370)

    • description: ExtractExamplesWithKeyword in autoGenerateHelper.py and the Examples listing in doc2rst.py used os.listdir() without sorting. NTFS returns alphabetical order and ext4 returns hash order; the Relevant-Examples lists are truncated to the first few entries; so the generated docs and two Tier 1 files under main/src/pythonGenerator/generated differed between Windows and Linux. Found by the first CI run of tools/regenerate.py on Linux (revision2026 step R0.2 and fact 18).

    • notes: Both listings now use sorted(…, key=str.lower). Case-insensitive reproduces the NTFS order the committed output was generated in, so Tier 1 is unchanged on Windows. Verified in a python:3.13 container: Linux and Windows now produce identical generated files.

    • date resolved: 2026-09-11 11:03, date raised: 2026-09-11

  • 1.11.18 BUG raised by: Claude-JG resolved by: Claude-JG relativeRotationTranslationMechanism now ends at rest at the origin (#2369)

    • description: norm(GetODE2Coordinates()) at the end of the run is 2.087948914872922e-12 while the reference recorded in the file is 4.172189649307425 (2023-06-12). The mechanism produces essentially zero motion. Found while triaging the unlisted TestModels for revision2026 step R5.9. Not added to the test suite.

    • notes: Fixed by the maintainer: endTime reduced from 2s to 0.2s. At 2s the mechanism was back in its initial configuration with no displacements, so the norm was ~0. Added to the test suite with reference 1.509631854432179.

    • date resolved: 2026-09-11 11:03, date raised: 2026-09-11

  • 1.11.17 TESTING raised by: Claude-JG resolved by: Claude-JG test suite does not notice models that are in no reference list (#2367)

    • description: runTestSuite.py builds its run list from the keys of TestExamplesReferenceSolution() and never lists the directory; a model on disk but in no list is therefore silently never executed. 19 models were in that state.

    • notes: testRunnerTools.CheckTestCoverage() added; runs at suite start-up; uncovered file or stale key fails under –exit-code. Verified by fault injection.

    • date resolved: 2026-09-10 22:31, date raised: 2026-09-10

  • 1.11.16 BUG raised by: Claude-JG resolved by: Claude-JG Python 3.6 non-AVX reference override never applied (#2366)

    • description: replaceRefSol in runTestSuiteRefSol.py spelled revoluteJointprismaticJointTest.py with a lowercase p while the file and the base dictionary use revoluteJointPrismaticJointTest.py. The overlay is applied by iterating the base keys; a key matching nothing is silently ignored; so this correction never applied on Python 3.6 without AVX.

    • notes: Overlay hoisted into Python36NonAVXOverrides() so its keys can be validated; spelling fixed; CheckTestCoverage reports any future dead override.

    • date resolved: 2026-09-10 22:31, date raised: 2026-09-10

  • 1.11.15 IMPROVEMENT raised by: Claude-JG resolved by: Claude-JG Clean up docs/howTo and remove the doxygen configuration (#2365)

    • description: docs/howTo held 26 loose .txt files, most describing VS2017/VS2019, 32-bit builds, Python 3.6/3.7 or the pre-WSLg X-server era, plus two exact duplicates. docs/doxygen held a 111 KB Doxyfile for a tool that broke on project size, whose PDF path never worked and whose graph generation had already been switched off. Also: no experimental folder remains in the tracked tree, so revision2026 step R1.4 has nothing to move. revision2026 steps R1.4, 30, 79.

    • notes: howTo cut 26 files to 8 all in .md, with the hard-won specifics salvaged into buildQuirks.md; doxygen removed; new docs/dev/ARCHITECTURE.md replaces what doxygen was wanted for. Experimental.h identified as a deliberate feature-flag mechanism and kept

    • date resolved: 2026-09-10 18:53, date raised: 2026-09-10

  • 1.11.14 TESTING raised by: Claude-JG resolved by: Claude-JG Verify the GitLab CI pipeline on the shared runners (#2364)

    • description: The GitLab CI configuration was written and tested locally under docker, but two environment questions could only be answered on the real runners: whether they may pull the manylinux image from quay.io, and whether EPEL is reachable for the GLFW and X11 packages. revision2026 step R1.7.

    • notes: First run 2026-09-10: all six jobs passed - wheels_linux cp310 to cp314 plus docs. quay.io reachable, EPEL reachable, and sphinx-build -W passes on Linux for the first time. Remaining: enable the weekly schedule and confirm failure mail

    • date resolved: 2026-09-10 14:21, date raised: 2026-09-10

  • 1.11.13 CHECK NORMAL raised by: Claude-JG resolved by: Claude-JG Known unresolved Windows/Linux differences in contact and friction tests (#2363)

    • description: Eight contact and friction test models give different results on Linux than the Windows reference values: relative errors from 3.4e-11 up to 1.6e+04 (sphereTriangleTest.py: reference 3.8226 vs Linux 59370.97). These are reproducible, so they are not the non-deterministic class - there is a cause that has not been found. Track them in UnresolvedOnLinux() and exclude from the exit code on Linux only, so Linux CI is usable while Windows stays strict. Investigation scheduled as revision plan phase R10 revision2026 step R10.1.

    • notes: List added and wired in; not the fix. Verified Windows still passes 106/106 with the list active and Linux exits 0 while reporting all eight. sphereTriangleTest.py is a divergence rather than an accuracy difference and should be investigated first

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

  • 1.11.12 BUG HIGH raised by: Claude-JG resolved by: Claude-JG Test runners truncate committed release logs at startup (#2362)

    • description: runTestSuite.py, runTestExamples.py and runPerformanceTests.py each call SetWriteToFile with flagAppend=False on a release-named file in a tracked directory at script start, before any test runs, with no existence check. An interrupted run leaves the committed release log half-written. 55 tracked log files are exposed. Filenames encode version, platform and Python but nothing machine-specific, so a second machine with the same configuration silently overwrites the first. revision2026 step R5.10.

    • notes: testRunnerTools.ResolveLogFile diverts to logsTmp when the target exists; –overwrite-log replaces deliberately. Also added package versions and CPU to the header, a per-test overview with runtimes at the end, and EXUDYN_MACHINE_ID for performance logs. Verified: divert leaves the tracked log byte-identical, override replaces it, absent target writes normally

    • date resolved: 2026-09-10 09:44, date raised: 2026-09-10

  • 1.11.11 TESTING HIGH raised by: Claude-JG resolved by: Claude-JG CI during the GitHub freeze (#2361)

    • description: GitHub Actions only fire on pushes to master and pull requests, so no wheels or tests run while master is frozen at 1.11.0 (decision D6). Add GitLab CI for Linux x86_64 across cp310-cp314 on the shared Docker runners, plus a docs build. Also fix that CI could not fail at all: wheels.yml sets continue-on-error and runTestSuite.py always exited 0. revision2026 step R1.7.

    • notes: runTestSuite.py gains –exit-code and loses the -F<NN> log suffix; reproducible vs sensitive tests separated in runTestSuiteRefSol.py; manylinuxBuild.sh deduplicated into tools/ci/buildManylinux.sh. Verified by fault injection. First pipeline run and the weekly schedule are still pending

    • date resolved: 2026-09-09 23:22, date raised: 2026-09-09

  • 1.11.10 CHANGE HIGH raised by: Claude-JG resolved by: Claude-JG Set up internal GitLab remote and sync v2-dev (#2360)

    • description: All v2.0 work needed an internal sync point so that GitHub master stays frozen at 1.11.0 (decision D6). Configure origin as the UIBK GitLab and github as the public remote; seed the server with full history and push v2-dev. revision2026 steps R1.1 and R1.3.

    • notes: GitLab rejects shallow pushes and caps packs at 1.17 GiB; seeded master from an existing full clone in 50-commit chunks, then v2-dev pushed from the shallow clone in 373 KB. Verified 30 refs matching by SHA. Local .git stays at 65 MB

    • date resolved: 2026-09-09 22:27, date raised: 2026-09-09

  • 1.11.9 EXTENSION HIGH raised by: Claude-JG resolved by: Claude-JG Add pre-push hook guarding the public repository (#2359)

    • description: Nothing mechanically prevented pushing v2-dev to public GitHub; only memory. Add tools/hooks/pre-push refusing any ref but master, release/* and tags when the target is GitHub, matched on both remote name and github.com URL. Activated per clone with git config core.hooksPath tools/hooks. Also verified that pushing from this shallow clone requires receive.shallowUpdate=true on the receiving repository. revision2026 steps R1.5 and R1.1.

    • notes: Verified with four cases against local throwaway repositories: v2-dev to github refused, master to github allowed, v2-dev to internal allowed, bare github.com URL refused before network access

    • date resolved: 2026-09-09 20:57, date raised: 2026-09-09

  • 1.11.8 FIX raised by: Claude-JG resolved by: Claude-JG Add .gitattributes for line endings and binary files (#2358)

    • description: The repository had no .gitattributes, so line endings depended on each contributor core.autocrlf setting and generation under a different shell could produce whole-file diffs. All generation and building so far has been on Windows; CI will run on Linux. Normalise text to LF in the repository with native checkout, and mark binary types explicitly. revision2026 step R0.5.

    • notes: Index was already fully LF-normalised so no renormalisation was introduced (git add –renormalize stages zero files). Two extension traps found: testData/rotorAnsys.rst is an ANSYS result file not reStructuredText, and *.eps/*.stl have ASCII variants so they are left to text=auto

    • date resolved: 2026-09-09 20:13, date raised: 2026-09-09

  • 1.11.7 TESTING HIGH raised by: Claude-JG resolved by: Claude-JG Add tools/regenerate.py drift gate (#2357)

    • description: No automated check existed for whether the committed generated files still match what the generators produce, so generator drift was silent. Add tools/regenerate.py: runs the six generators from their required cwd and classifies differences against HEAD, Tier 1 hard fail and Tier 2 warning. Must compare with IsEqualIgnoringDateStrings rather than raw git status, because the last-modified line otherwise produces permanent phantom drift. revision2026 step R0.2; CI wiring still open.

    • notes: Verified by fault injection: perturbed generator input gives exit 1 with correct tier classification; hand edit to an already-dirty tier file gives exit 1; date-only difference gives exit 0

    • date resolved: 2026-09-09 19:00, date raised: 2026-09-09

  • 1.11.6 TESTING raised by: Claude-JG resolved by: Claude-JG Golden file snapshot from a verified-current generated set (#2356)

    • description: The archived golden files were taken at e44aca1, where the committed generated set was already stale and where generator output was still cp1252-corrupted. Re-cut the reference with git archive from the current commit so it is provably identical to committed content. revision2026 step R0.3.

    • notes: goldenFiles_V1.11.5_910e2b5.zip, 871 files; full regeneration on that commit produces no drift, so the commit itself is the reference

    • date resolved: 2026-09-09 18:50, date raised: 2026-09-09

  • 1.11.5 DOCU raised by: Claude-JG resolved by: Claude-JG Regeneration must run after ResolveIssue (#2355)

    • description: ResolveIssue rewrites docs/theDoc/version.txt, but README.rst and docs/RST/Exudyn.rst embed the version string and are refreshed only by doc2rst.py. Regenerating before resolving leaves those two files one version behind, so the next drift check reports an unrelated change. Documented the required order in docs/dev/WORKFLOW.md and as a constraint on revision2026 step R0.2.

    • notes: Gate order is now: resolve issue, then regenerate, then commit

    • date resolved: 2026-09-09 18:49, date raised: 2026-09-09

  • 1.11.4 CHANGE raised by: Claude-JG resolved by: Claude-JG Track tools/issueTracker in the repository (#2354)

    • description: issueTracker.py and trackerlog.txt are the source of truth for the version number and the issue history but were local-only and never on GitHub. Commit them so the version derivation and the issue log live with the code. trackerlog.html and trackerlog_backup.txt stay ignored as regenerated output. tools/buildAndGenerate stays ignored until the cleanup in revision2026 step R3.7 because it still contains hard-coded local paths.

    • notes: Scanned trackerlog.txt for revision2026 step R1.6 first: no credentials, no email addresses, no absolute local paths

    • date resolved: 2026-09-09 18:47, date raised: 2026-09-09

  • 1.11.3 FIX raised by: Claude-JG resolved by: Claude-JG Reconcile GitHub Examples/TestModels with internal repository (#2353)

    • description: The GitHub copies of main/pythonDev/Examples and TestModels had drifted from the internal repository through the old auto-copy; six Examples and five TestModels were stale or missing so the committed docs did not match a fresh regeneration. Reconciled both folders. Also pruned TestSuiteLogs/PerformanceLogs per the new retention policy (decision D7) and added the missing 1.11 and testExamples logs. Adjusted movingGroundRobotTest.py output scaling factor from 0.01 to 0.005 with updated reference value because its error sat too close to the global 5e-14 tolerance.

    • notes: Examples and TestModels now match the internal repository; a fresh regeneration produces no doc differences

    • date resolved: 2026-09-09 18:47, date raised: 2026-09-09

  • 1.11.2 FIX HIGH raised by: Claude-JG resolved by: Claude-JG Generators write output with platform default encoding (#2352)

    • description: Twelve write sites and six paired read sites in the python generators used the platform default encoding (cp1252 on Windows) instead of UTF-8, corrupting non-ASCII output on every regeneration (e.g. degree sign in interfaces.tex). Blocks the regeneration drift gate. Also: pybind_manual_classes.h was rewritten unconditionally and StructuresAndSettingsIndex.rst had trailing spaces. Revision plan revision2026 step R0.6.

    • notes: All 12 write sites and 6 paired read sites now pass encoding=utf8; pybind_manual_classes.h routed through WriteTextIfDifferent; trailing spaces removed. Verified by two identical consecutive regenerations and a UTF-8 validity scan.

    • date resolved: 2026-09-09 18:33, date raised: 2026-09-09

  • 1.11.1 DOCU raised by: Claude-JG resolved by: Claude-JG Working setup for Claude sessions (#2351)

    • description: Add CLAUDE.md working contract, docs/dev (CODING_STYLE, WORKFLOW, README), docs/howTo/condaEnvironments.md and root .gitignore; untrack main/dist and cppsrc.vcxproj.user. Revision plan revision2026 step R0.1.

    • notes: CLAUDE.md + docs/dev + condaEnvironments.md + root .gitignore; main/dist and cppsrc.vcxproj.user untracked

    • date resolved: 2026-09-09 18:33, date raised: 2026-09-09

  • 1.11.0 BUG raised by: P. Manzl StableBaselines (#2348)

    • description: Importing exudyn.artificialIntelligence raises an error at to the old gym legacy flag with the latest stable-baselines3 versions due to non-numeric version numbers

    • date resolved: 2026-06-01 14:43, date raised: 2026-06-01

Version 1.10

  • 1.10.160 CHANGE special.solver.timeout (#2346)

    • description: change start time for this timer to output.cpuSolverStartTime to more accurately handle timeouts and simulationInRealtime

    • date resolved: 2026-04-20 22:39, date raised: 2026-04-20

  • 1.10.159 EXTENSION solver.output (#2347)

    • description: add distinguished flags for stopping simulation: simulationTimeout, simulationStoppedByUser and simulationStoppedByUserFunction to determine causes for stopped simulations (all giving finishedSuccessfully=True)

    • date resolved: 2026-04-20 22:38, date raised: 2026-04-20

  • 1.10.158 FIX Create functions (#2345)

    • description: several parameters like CreateTorsionalSpringDamper offset, velocityOffset and torque require UReal but only Real needed

    • date resolved: 2026-04-19 14:39, date raised: 2026-04-19

  • 1.10.157 CHANGE CreateSphereTriangleContact (#2341)

    • description: CreateSphereTriangleContact, CreateSphereQuadContact and CreateSphereSphereContact: adapt to make it work with mass points in case that there is no friction, similar to issue 2231

    • date resolved: 2026-04-07 20:15, date raised: 2026-04-07

  • 1.10.156 EXTENSION CreateSphereSphereContact (#2231)

    • description: if objects are mass points (2D, 3D), only add MarkerBodyPosition if dynamicFriction=0 (otherwise error); enable markers in bodyNumbers field

    • date resolved: 2026-04-07 20:13, date raised: 2026-01-19

  • 1.10.155 CHANGE CreateSphereTriangleContact (#2340)

    • description: CreateSphereTriangleContact and CreateSphereQuadContact shall accept list of quadPoints or trianglePoints instead of Vector3DList

    • date resolved: 2026-04-07 20:01, date raised: 2026-04-07

  • 1.10.154 FIX ContactSphereTriangle (#2339)

    • description: in case of frictionless contact, torques on triangle are neglected

    • date resolved: 2026-04-06 19:46, date raised: 2026-04-06

  • 1.10.153 FIX CreateContactSphereSphere (#2338)

    • description: allow mass points with MarkerBodyPosition or MarkerNodePosition in friction-less case

    • date resolved: 2026-04-06 19:42, date raised: 2026-04-06

  • 1.10.152 EXTENSION beams (#2336)

    • description: add new beams generate function GenerateBeamElementsAlongLine which is similar to GenerateStraightBeam, but has more readable args and a dict as return value

    • date resolved: 2026-04-06 15:53, date raised: 2026-04-06

  • 1.10.151 EXTENSION shells (#2335)

    • description: add visualization setting shells.thicknessFactor for drawing larger thickness for visual inspectation

    • date resolved: 2026-04-03 14:03, date raised: 2026-04-03

  • 1.10.150 EXTENSION VSettingsShells (#2334)

    • description: add visualization settings for plates and shells

    • date resolved: 2026-04-02 16:04, date raised: 2026-04-02

  • 1.10.149 EXTENSION NumpyMatrix (#2331)

    • description: add option to silently convert scalar values into NumpyMatrix in object parameter initialization (e.g. height in ANCFThinPlate being either scalar or matrix)

    • date resolved: 2026-04-02 13:25, date raised: 2026-04-02

  • 1.10.148 FIX AddSystem (#2330)

    • description: add py::keep_alive<0, 1>() to functions like AddSystem which return an object which depends on another object (SystemContainer); avoids severe problems when SystemContainer is destroyed

    • date resolved: 2026-03-31 19:03, date raised: 2026-03-31

  • 1.10.147 FIX InvoluteGear (#2329)

    • description: in machines.InvoluteGear, add tolerance to avoid point duplications, leading to graphics problems

    • date resolved: 2026-03-25 09:33, date raised: 2026-03-25

  • 1.10.146 FIX ANCFBeam (#2327)

    • description: add implementation for damping similar to ANCFCable elements

    • date resolved: 2026-03-24 17:00, date raised: 2026-03-24

  • 1.10.145 EXTENSION graphics (#2323)

    • description: add function LinkedCylinders which draws the convex hull of two cylinders with parallel axes, useful for levers in mechanisms

    • date resolved: 2026-03-05 16:21, date raised: 2026-03-05

  • 1.10.144 EXTENSION SolidExtrusion (#2324)

    • description: add WARNING for unreferenced vertices in Delauney triangles, as this can indicate duplicated vertices in contour and often causes graphical issues

    • date resolved: 2026-03-05 16:20, date raised: 2026-03-05

  • 1.10.143 FIX SolidExtrusion (#2322)

    • description: normals not correctly computed in case of smoothNormals=True

    • date resolved: 2026-03-05 12:48, date raised: 2026-03-05

  • 1.10.142 CHANGE clippingPlane (#2320)

    • description: add automatic normalization of clippingPlaneNormal in OpenGL renderer if norm is not 1 (except for 0 length)

    • date resolved: 2026-03-03 16:29, date raised: 2026-03-03

  • 1.10.141 EXTENSION Add ObjectJointSliding (#2314)

    • description: Add 3D SlidingJoint basic functionality

    • date resolved: 2026-03-02 09:48, date raised: 2026-03-02

  • 1.10.140 EXTENSION Add MarkerBodyBeamShape (#2313)

    • description: marker to be attached to beams for sliding joint and contact with beams

    • date resolved: 2026-03-02 09:46, date raised: 2026-03-02

  • 1.10.139 FIX Newton (#2312)

    • description: newton.useNewtonSolver not used

    • date resolved: 2026-02-27 16:02, date raised: 2026-02-27

  • 1.10.138 EXTENSION DrawSystemGraph (#2311)

    • description: extend to add more information in graph, like type and name; add option to only retrieve graph but not to show; optionally add all item information

    • date resolved: 2026-02-25 10:34, date raised: 2026-02-25

  • 1.10.137 FIX FEM (#2310)

    • description: ComputeHurtyCraigBamptonModes: for pure eigenmodes with no boundary lists, computation only works in sparse mode - extend to sparse mode and include optional exclusion of rigid body modes

    • date resolved: 2026-02-24 15:09, date raised: 2026-02-24

  • 1.10.136 EXTENSION VisualizationSettings (#2257)

    • description: check for all changed parameter names in .py and .tex files

    • date resolved: 2026-02-20 00:16, date raised: 2026-01-31

  • 1.10.135 EXTENSION VisualizationSettings (#2249)

    • description: add feature to re-link outdated/changed settings and print warnings

    • date resolved: 2026-02-20 00:16, date raised: 2026-01-31

  • 1.10.134 EXTENSION VisualizationSettings (#2248)

    • description: add backlink to top settings structure in every substructure and initialize in constructor

    • date resolved: 2026-02-20 00:16, date raised: 2026-01-31

  • 1.10.133 FIX visualizationSettings (#2285)

    • description: adapt Examples and TestModels to new visualizationSettings introduced in Exudyn 1.10.103

    • date resolved: 2026-02-20 00:15, date raised: 2026-02-12

  • 1.10.132 FIX rotationCenterPoint (#2300)

    • description: fix correct calculation of mouse coordinates, bounding box, etc. when changing rotationCenterPoint

    • date resolved: 2026-02-19 22:29, date raised: 2026-02-14

  • 1.10.131 EXTENSION GLFWClient (#2245)

    • description: add camera position and orentation as alternative to current modelview; centerPoint adds up to it and modelRotation rotates the camera

    • date resolved: 2026-02-19 13:54, date raised: 2026-01-31

  • 1.10.130 CHANGE zOffsetCamera (#2307)

    • description: removed raytracer.zOffsetCamera as the z-shift is now possible with camera.nearFarPlaneOffset

    • date resolved: 2026-02-17 15:55, date raised: 2026-02-17

  • 1.10.129 FIX trackMarker (#2306)

    • description: include trackMarker in light position and further transformations during OpenGL rendering and raytracing

    • date resolved: 2026-02-16 23:06, date raised: 2026-02-16

  • 1.10.128 FIX views (#2294)

    • description: raytracing bounding box (searchTree?) wrong for example unbalancedFlywheel.py

    • notes: was due to NaN in numpy calculation for Bearing graphics; fixed

    • date resolved: 2026-02-16 22:46, date raised: 2026-02-13

  • 1.10.127 FIX light positions (#2299)

    • description: Fix light positions for lights in camera frame - sync with lights initialization and with Raytracer

    • date resolved: 2026-02-16 22:45, date raised: 2026-02-14

  • 1.10.126 EXTENSION openGL settings (#2296)

    • description: add option showBoundingBox, which shows the bounding box of the current scene (as available in renderState)

    • date resolved: 2026-02-16 22:45, date raised: 2026-02-14

  • 1.10.125 FIX boundingBox (#2303)

    • description: bounding box calculation resets in case that nan is included in points; check for nan in points in graphicsData when reading!

    • date resolved: 2026-02-15 22:38, date raised: 2026-02-15

  • 1.10.124 FIX graphics (#2302)

    • description: BallBearingRings leads to nan (not a number) for impossible geometries, thus grooves not being calculated; add error message

    • date resolved: 2026-02-15 22:37, date raised: 2026-02-15

  • 1.10.123 FIX ConstSizeMatrix (#2301)

    • description: Fix wrong GetDataPointer function, which points to data instead of &data[0]

    • date resolved: 2026-02-15 01:24, date raised: 2026-02-15

  • 1.10.122 CHANGE systemStructures.py (#2241)

    • description: add structure for ChildWindow (childWindow1-3)

    • notes: added view1-3 already earlier;

    • date resolved: 2026-02-14 23:13, date raised: 2026-01-31

  • 1.10.121 FIX tkinter font (#2297)

    • description: Exudyn Command dialog raises error due to AttributeError for tkinter.font

    • date resolved: 2026-02-14 22:52, date raised: 2026-02-14

  • 1.10.120 EXTENSION FromPyMeshlabFile (#2291)

    • description: add option to check and normalize normals

    • date resolved: 2026-02-14 17:31, date raised: 2026-02-13

  • 1.10.119 EXTENSION graphics.Move (#2292)

    • description: remove explanation to scale, as it also scales normals; add function MoveAndScale, which does both and Move calls MoveAndScale

    • date resolved: 2026-02-14 17:30, date raised: 2026-02-13

  • 1.10.118 FIX AddEdgesAndSmoothenNormals (#2295)

    • description: remove arg pointTolerance as it is unused (roundDigits was introduced earlier)

    • date resolved: 2026-02-13 15:53, date raised: 2026-02-13

  • 1.10.117 CHANGE graphics (#2293)

    • description: functoin InvertTriangles: change arg invertVertexNormals to invertNormals for consistency reason with other functions

    • date resolved: 2026-02-13 15:02, date raised: 2026-02-13

  • 1.10.116 EXTENSION raytracer (#2283)

    • description: enable rendering of views with OpenGL or raytracer independently using flag view.camera.useRaytracer

    • date resolved: 2026-02-12 21:49, date raised: 2026-02-11

  • 1.10.115 EXTENSION FromPyMeshlabFile (#2280)

    • description: add graphics.FromPyMeshlabFile to import arbitrary geometries, e.g., .stl, .obj, .dae, etc. which can be loaded with pymeshlab; note: currently no textures or materials are loaded

    • date resolved: 2026-02-12 21:48, date raised: 2026-02-11

  • 1.10.114 EXTENSION RedrawAndGetImage (#2254)

    • description: add optional viewID=0 to enable offline rendering of window; use renderer.EnableView(viewID=…) before rendering to enable virtual camera and adjust settings with renderer.SetState(viewID=…) (without opening window)

    • date resolved: 2026-02-12 21:48, date raised: 2026-02-01

  • 1.10.113 CHANGE GLFWClient (#2253)

    • description: homogenize functions that operate on modelRotation and modelTranslation

    • date resolved: 2026-02-12 21:45, date raised: 2026-02-01

  • 1.10.112 EXTENSION VisualizationSettings (#2252)

    • description: add advanced subfolders to avoid large settings folders: general.advanced, contour.advanced, openGL.advanced, raytracer.advanced, interactive.advanced

    • date resolved: 2026-02-12 21:45, date raised: 2026-01-31

  • 1.10.111 EXTENSION VisualizationSettings (#2250)

    • description: put openGL.light0/1xyz data to settings.openGL.light0/1.xyz; add total of 4 lights both for OpenGL and raytracer; add shadow to all lights; put cameraPos/Rot, lockModelView, clippingPlaneDistance, clippingPlaneNormal, perspective, facesTransparent, showFaceEdges, showFaces, showMeshEdges, showMeshFaces, general.worldBasisSize, general.drawCoordinateSystem, general.drawWorldBasis, general.showComputationInfo, general.textSize, … to scene, window or camera

    • date resolved: 2026-02-12 21:45, date raised: 2026-01-31

  • 1.10.110 EXTENSION raytracer (#2284)

    • description: add separate multiSampling flag: raytracers.advanced.multiSampling which is independent from OpenGL multiSampling

    • date resolved: 2026-02-12 21:42, date raised: 2026-02-11

  • 1.10.109 CHANGE light position (#2290)

    • description: change default values for openGL.light0position to [2,2,10,0] leading to less spot lights in flat scenes in x-y plane; similar for light1position

    • date resolved: 2026-02-12 16:31, date raised: 2026-02-12

  • 1.10.108 CHANGE nodes markers loads (#2289)

    • description: simplified drawing cannot be turned on any more if drawFaces=False, because drawFaces has now moved to view.scene; added flag drawNodesMarkersLoadsWithFaces in C++ code to mark changes

    • date resolved: 2026-02-12 15:44, date raised: 2026-02-12

  • 1.10.107 CHANGE nodes (#2288)

    • description: drawNodesAsPoint together with showBasis: showBasis shall be drawn with lines if drawNodesAsPoint=True and with 3D faces otherwise

    • date resolved: 2026-02-12 15:41, date raised: 2026-02-12

  • 1.10.106 CHANGE lightModelAmbient (#2287)

    • description: use openGL.lightModelAmbient throughout for ambient color both for OpenGL and raytracer; adapt to [0.4,0.4,0.4,1] being slightly lighter while diffuse light0 is reduced from 0.6 to 0.5; this should give better visibility; light ambient color removed

    • date resolved: 2026-02-12 14:02, date raised: 2026-02-12

  • 1.10.105 FIX ambientAndDiffuse (#2286)

    • description: In OpenGL materialAmbientAndDiffuse is not used for colored materials, so remove the value (deprecated structure redirects now to materialSpecular but must not be used anymore)

    • date resolved: 2026-02-12 14:02, date raised: 2026-02-12

  • 1.10.104 EXTENSION VisualizationSettings (#2251)

    • description: relocate options and add new folders scene, camera, window in new folders view0 (standard view as before), view0, view2, etc.

    • date resolved: 2026-02-11 23:18, date raised: 2026-01-31

  • 1.10.103 CHANGE light0 position (#2282)

    • description: changed from [0.2,0.2,10,0] to [2,2,10,0] to avoid specular effects of objects in x-y plane in initial configuration

    • date resolved: 2026-02-11 14:00, date raised: 2026-02-11

  • 1.10.102 CHANGE openGL.light0ambient (#2279)

    • description: openGL.light0ambient and openGL.light1ambient are removed as they are redundant with openGL.lightModelAmbient which shall be used in future

    • notes: for that reason, the default value of openGL.lightModelAmbient has been changed to [0.3,0.3,0.3,1] to stay consistent!

    • date resolved: 2026-02-10 22:34, date raised: 2026-02-10

  • 1.10.101 CHANGE charBitmap.h (#2276)

    • description: split up into header and implementation to suppress warnings

    • date resolved: 2026-02-09 14:56, date raised: 2026-02-09

  • 1.10.100 EXTENSION GLFWClient (#2275)

    • description: add new substructure RenderView which collects GLFWwindow and RenderState, allowing to open several windows; window0=main window as before

    • date resolved: 2026-02-08 00:15, date raised: 2026-02-08

  • 1.10.99 EXTENSION GLFWClient (#2243)

    • description: add crosslines instead of mouse cursor when mouse coordinates are shown in renderer

    • date resolved: 2026-02-08 00:14, date raised: 2026-01-31

  • 1.10.98 FIX Raytracer (#2274)

    • description: improve line drawing linewidth to comply with OpenGL renderer

    • date resolved: 2026-02-06 23:53, date raised: 2026-02-06

  • 1.10.97 EXTENSION ZoomAll (#2271)

    • description: allow call to ZoomAll with inactive renderer; add flag render=True; put current ZoomAll functionality from GLFWClient to accessible location

    • date resolved: 2026-02-06 23:53, date raised: 2026-02-06

  • 1.10.96 FIX RenderState (#2273)

    • description: Initialize RenderState provisionally with default visualizationSettings at SystemContainer creation, then initialize with current SC.visualizationSettings at first call to any renderer function

    • date resolved: 2026-02-06 21:24, date raised: 2026-02-06

  • 1.10.95 FIX general.autoFitScene (#2272)

    • description: already called at initialization of SystemContainer; needs to be overwritten at start of renderer or at first call to renderer/raytracer function - otherwise ZoomAll always called

    • date resolved: 2026-02-06 21:20, date raised: 2026-02-06

  • 1.10.94 EXTENSION docstrings (#2263)

    • description: similar to issue 0444, auto-convert comments to docstrings when creating wheels

    • date resolved: 2026-02-06 15:22, date raised: 2026-02-03

  • 1.10.93 DOCU docstrings (#444)

    • description: change function comments in .py files to PEP standardized docstrings

    • date resolved: 2026-02-06 15:21, date raised: 2020-09-06

  • 1.10.92 EXTENSION Renderer (#2270)

    • description: in mode showMouseCoordinates, enable logging of mouse coordinates in current axis-aligned plane; behavior switched with logMouseCoordinates; only in case that perspective=0

    • date resolved: 2026-02-05 23:20, date raised: 2026-02-04

  • 1.10.91 CHANGE showMouseCoordinates (#2258)

    • description: make not available for perspective!=0 as it gives wrong values; disable zoom and mouse move as well

    • date resolved: 2026-02-05 23:20, date raised: 2026-02-02

  • 1.10.90 EXTENSION docstrings (#2268)

    • description: add docstrings to itemInterface

    • date resolved: 2026-02-05 23:19, date raised: 2026-02-04

  • 1.10.89 EXTENSION docstrings (#2266)

    • description: add docstrings for itemInterface items (__init__ function with all parameters)

    • date resolved: 2026-02-05 23:19, date raised: 2026-02-03

  • 1.10.88 EXTENSION stub files (.pyi) (#2265)

    • description: add details (input, output, example) for functions created in autoGeneratePyBindings, using a common GoogleStyle generator

    • date resolved: 2026-02-05 23:19, date raised: 2026-02-03

  • 1.10.87 EXTENSION Renderer (#2269)

    • description: allow finer zoom stepsstep with CTRL+mouse wheel

    • date resolved: 2026-02-04 20:27, date raised: 2026-02-04

  • 1.10.86 EXTENSION stub files (.pyi) (#2262)

    • description: add description for objects created in autoGeneratePyBindings

    • date resolved: 2026-02-03 16:20, date raised: 2026-02-03

  • 1.10.85 EXTENSION stub files (.pyi) (#2256)

    • description: add docstrings for better help, as .pyi information is prioritized in Spyder

    • date resolved: 2026-02-03 16:20, date raised: 2026-02-01

  • 1.10.84 EXTENSION docstrings (#2264)

    • description: add docstrings for enums

    • date resolved: 2026-02-03 09:06, date raised: 2026-02-03

  • 1.10.83 EXTENSION stub files (.pyi) (#2261)

    • description: add docstrings to system structures

    • date resolved: 2026-02-02 23:37, date raised: 2026-02-02

  • 1.10.82 CHANGE solvers (#2260)

    • description: change default value exu.SimulationSettings() to None, but keep default behavior internally; this improves in-editor help

    • date resolved: 2026-02-02 22:48, date raised: 2026-02-02

  • 1.10.81 CHANGE ResetKeyPressUserFunction (#2255)

    • description: removed functionality as keyPressUserFunction can be reset by assigning it to 0

    • notes: keyPressUserFunction can now be reset by setting it to 0

    • date resolved: 2026-02-01 17:02, date raised: 2026-02-01

  • 1.10.80 EXTENSION GLFWClient (#2242)

    • description: add option for autorotation of scene, using a angular velocity vector; standard=[0,0,pi/2]; factor related to start time when timer is started

    • date resolved: 2026-02-01 12:13, date raised: 2026-01-31

  • 1.10.79 CHANGE GLFWClient (#2246)

    • description: model translation currently only uses x and y components: glTranslatef(translationMV[0], translationMV[1], 0.f); => fix in order to avoid large offsets in large scenes

    • notes: check graphics functionality in examples…

    • date resolved: 2026-01-31 22:12, date raised: 2026-01-31

  • 1.10.78 EXTENSION computeInitialAccelerations (#2233)

    • description: extend to sparse mode for initial velocities by simple global differentiation of sparse constraints

    • date resolved: 2026-01-23 00:29, date raised: 2026-01-21

  • 1.10.77 CHANGE storeInitialAlgebraicCoordinates (#2232)

    • description: in case of computation of initial accelerations, also store initial Lagrange multipliers in initial coordinates

    • date resolved: 2026-01-21 23:01, date raised: 2026-01-21

  • 1.10.76 EXTENSION ANCFThinPlate (#2224)

    • description: add slopes scaling to elements

    • date resolved: 2026-01-18 23:07, date raised: 2026-01-16

  • 1.10.75 DOCU Jacobian description (#2222)

    • description: jacobians are computed e.g. as J = partial p/partial q and generalized forces are computed as J^T * f; fix this in item descriptions, in ObjectMassPoint2D and ObjectMassPoint where J * f is used; check

    • date resolved: 2026-01-15 11:04, date raised: 2026-01-15

  • 1.10.74 EXTENSION CreateForce, CreateTorque (#2221)

    • description: allow marker indices in bodyNumber

    • date resolved: 2026-01-14 13:57, date raised: 2026-01-14

  • 1.10.73 CHANGE AVX2 linux (#2220)

    • description: enable AVX2 on linux and activate performance flags (O3)

    • date resolved: 2026-01-14 01:46, date raised: 2026-01-14

  • 1.10.72 EXTENSION shells.py (#2214)

    • description: add shells module for plate and shell elements; add generator function for planar meshes

    • date resolved: 2026-01-13 22:25, date raised: 2026-01-11

  • 1.10.71 EXTENSION ANCFThinPlate (#2199)

    • description: add access functions

    • date resolved: 2026-01-13 22:25, date raised: 2026-01-07

  • 1.10.70 EXTENSION graphics.Sphere (#2216)

    • description: add option to draw only part of sphere using min and max axis length given by angles; add option to draw hollow sphere with innerRadius

    • date resolved: 2026-01-12 22:37, date raised: 2026-01-12

  • 1.10.69 EXTENSION graphics.Sphere (#2217)

    • description: double tiling of circles to obtain better visibility

    • date resolved: 2026-01-12 19:03, date raised: 2026-01-12

  • 1.10.68 EXTENSION graphics.Basis (#2215)

    • description: add option to add text within arg labels

    • date resolved: 2026-01-12 18:37, date raised: 2026-01-12

  • 1.10.67 EXTENSION ANCFThinPlate (#2198)

    • description: add position, velocity, … computation

    • date resolved: 2026-01-11 17:25, date raised: 2026-01-07

  • 1.10.66 EXTENSION ANCFThinPlate (#2197)

    • description: add correct element jacobian

    • date resolved: 2026-01-11 17:25, date raised: 2026-01-07

  • 1.10.65 FIX GeometricallyExactBeam2D (#2213)

    • description: correct drawing with cross section and drawVertical

    • date resolved: 2026-01-09 20:43, date raised: 2026-01-09

  • 1.10.64 BUG __init__.py, AVX2 (#2212)

    • description: error in __init__.py causes exudyn to always choose non-AVX2 version

    • date resolved: 2026-01-09 10:48, date raised: 2026-01-09

  • 1.10.63 EXTENSION GeometricallyExactBeam2D (#2211)

    • description: add autodiff jacobian

    • date resolved: 2026-01-09 02:15, date raised: 2026-01-08

  • 1.10.62 EXTENSION GeometricallyExactBeam2D (#2209)

    • description: add reference curvature and correct reference rotation for curved case

    • date resolved: 2026-01-08 23:10, date raised: 2026-01-08

  • 1.10.61 EXTENSION GeometricallyExactBeam2D (#2210)

    • description: flag includeReferenceRotations=False now refers to axial slopes rather to the direction of endpoints; this is identical for linear elements, but different for quadratic ones

    • date resolved: 2026-01-08 22:47, date raised: 2026-01-08

  • 1.10.60 EXTENSION GeometricallyExactBeam2D (#2207)

    • description: extend element for 3-node case with quadratic interpolation (just by providing a 3rd nodeNumber)

    • date resolved: 2026-01-08 21:42, date raised: 2026-01-08

  • 1.10.59 EXTENSION Manylinux wheels (#2206)

    • description: switch to docker, add compile manylinux wheels locally

    • date resolved: 2026-01-08 13:32, date raised: 2026-01-08

  • 1.10.58 EXTENSION maxSceneSize (#2195)

    • description: add bounding box for scene for better adjustments

    • date resolved: 2026-01-08 00:07, date raised: 2026-01-06

  • 1.10.57 EXTENSION OutputVariable (#2201)

    • description: change to 64bit

    • date resolved: 2026-01-07 19:03, date raised: 2026-01-07

  • 1.10.56 EXTENSION ANCFThinPlate (#1662)

    • description: add ANCF plate element based on 2 inplane slope vectors Slope12, based on Dufva/Shabana

    • date resolved: 2026-01-07 19:00, date raised: 2023-10-15

  • 1.10.55 FIX perspective (#2190)

    • description: find causes for raytracer artifacts in case of larger perspective values

    • notes: adapted centerPoint; artifacts may still appear for very out of center models

    • date resolved: 2026-01-06 22:34, date raised: 2026-01-04

  • 1.10.54 EXTENSION ZoomAll (#2196)

    • description: add parameters zoomAllUseBoundingBox, boundingBoxZoomAllOffset and boundingBoxZoomAllFactor to adjust to exact bounding box of scene in rotated coordinates

    • date resolved: 2026-01-06 18:30, date raised: 2026-01-06

  • 1.10.53 EXTENSION store model view (#2193)

    • description: print SetModelView code to console when pressing CTRL-F3

    • notes: see also section ‘Storing the model view’ in the docu

    • date resolved: 2026-01-06 16:59, date raised: 2026-01-06

  • 1.10.52 TESTING GLFWclient (#2170)

    • description: Test new USE_GLFW_GRAPHICS settings in compilation with -noglfw

    • date resolved: 2026-01-06 11:46, date raised: 2025-12-25

  • 1.10.51 CHANGE coordinateSystem (#2192)

    • description: add option to draw coordinate system with arrows; change general.drawCoordinateSystem to integer where 2 and 3 represent drawing with arrows

    • date resolved: 2026-01-06 02:09, date raised: 2026-01-06

  • 1.10.50 FIX RedrawAndGetImage (#2191)

    • description: UpdatePostProcessData needs to be called in case that renderer is not running

    • date resolved: 2026-01-05 10:44, date raised: 2026-01-05

  • 1.10.49 EXTENSION raytracer (#2153)

    • description: add text using textures

    • date resolved: 2026-01-05 00:21, date raised: 2025-11-02

  • 1.10.48 CHANGE perspective (#2167)

    • description: revise perspective model and synchronize raytracer with openGL implementation

    • date resolved: 2026-01-04 22:19, date raised: 2025-12-16

  • 1.10.47 CHANGE polygonOffset (#2189)

    • description: increase openGL polygonOffset due to change in OpenGL projection method (zMaxSceneFactor changed from 100 to 2)

    • date resolved: 2026-01-04 20:34, date raised: 2026-01-04

  • 1.10.46 CHANGE zMaxSceneFactor (#2188)

    • description: add factor that previously was fixed to 100.; now defaulting to smaller default value, thus requiring adjustment in certain cases!

    • date resolved: 2026-01-04 14:17, date raised: 2026-01-04

  • 1.10.45 FIX MainSystemExtensions (#2187)

    • description: JointPreCheckCalcBodyMarkers requires position even if not used

    • date resolved: 2026-01-04 12:44, date raised: 2026-01-04

  • 1.10.44 EXTENSION resolved by: S. Weyrer Create functions (#2185)

    • description: Add mbs.CreateFFRFReducedOrderObject

    • date resolved: 2026-01-04 11:42, date raised: 2026-01-04

  • 1.10.43 EXTENSION ObjectFFRFreducedOrder sparse (#1196)

    • description: add sparse option for ObjectFFRFreducedOrder, filling in flexible-flexible mass terms into sparse mass matrix

    • notes: partially resolved and moved to newer issues

    • date resolved: 2026-01-04 11:35, date raised: 2022-07-11

  • 1.10.42 CHECK ObjectFFRFreducedOrder (#599)

    • description: compare Tait-Bryan and RotationVector cases with Euler parameters

    • notes: already resolved earlier

    • date resolved: 2026-01-04 11:23, date raised: 2021-03-18

  • 1.10.41 DOCU ObjectFFRFreducedOrder / CMS (#643)

    • description: create tutorial with two bodies (crank, connecting rod, rigid piston)

    • notes: already resolved earlier with FFRF tutorial

    • date resolved: 2026-01-04 11:22, date raised: 2021-04-30

  • 1.10.40 CHANGE GLFWclient (#2169)

    • description: decouple graphics settings from USE_GLFW_GRAPHICS if they do not require OpenGL and GLFW

    • date resolved: 2026-01-03 23:38, date raised: 2025-12-25

  • 1.10.39 EXTENSION renderer.SetModelView (#2180)

    • description: add renderer function renderer.SetModelView(zoom, rotationVector, centerPoint) which adjusts the view to zoom, rotation and center point; in particular for raytracing

    • date resolved: 2026-01-03 01:51, date raised: 2026-01-03

  • 1.10.38 EXTENSION renderer.RedrawAndGetImage (#2177)

    • description: extended for software renderer (useRaytracer=True), to grab images of the 3D view completely without starting the renderer

    • date resolved: 2026-01-03 01:51, date raised: 2026-01-01

  • 1.10.37 CHANGE renderState (#2181)

    • description: update visualizationSettings.window.renderWindowSize when renderState.currentWindowSize is prescribed in call to renderer.SetState(…)

    • date resolved: 2026-01-03 01:11, date raised: 2026-01-03

  • 1.10.36 FIX raytracer (#2179)

    • description: check why raytracer does not render triangles at first run

    • date resolved: 2026-01-03 00:50, date raised: 2026-01-03

  • 1.10.35 EXTENSION raytracer (#2147)

    • description: export images without opening renderer; including view settings

    • date resolved: 2026-01-03 00:43, date raised: 2025-09-23

  • 1.10.34 CHANGE RendererInActiveError (#2178)

    • description: add error handling if a renderer function is called which requires the renderer to be active but it is not

    • date resolved: 2026-01-01 23:09, date raised: 2026-01-01

  • 1.10.33 EXTENSION resolved by: Z. Zhang processing (#2176)

    • description: useMPI is not used in GeneticOptimization and in ComputeSensitivities; add flag and pass through to ProcessParameterList

    • date resolved: 2025-12-31 16:31, date raised: 2025-12-31

  • 1.10.32 CHANGE GlfwRenderer (#2175)

    • description: change the way how interactive.lockModelView is realized, ignoring keys and mouse actions on model view

    • date resolved: 2025-12-29 23:57, date raised: 2025-12-29

  • 1.10.31 CHANGE GlfwRenderer (#2174)

    • description: change selectBufferSize during mouse select from 10000 to 1000 to reduce stack size problems

    • date resolved: 2025-12-29 23:57, date raised: 2025-12-29

  • 1.10.30 EXTENSION GraphicsData (#2173)

    • description: add fontSize and offset to graphicsData text structure as well as to graphics.Text(…) function

    • date resolved: 2025-12-29 21:40, date raised: 2025-12-29

  • 1.10.29 EXTENSION contour (#2172)

    • description: add contour colors to VisualizationSettings

    • date resolved: 2025-12-27 23:09, date raised: 2025-12-26

  • 1.10.28 EXTENSION raytracer (#2166)

    • description: add shortkey to switch to raytracing

    • notes: CTRL-R used for switching

    • date resolved: 2025-12-27 22:01, date raised: 2025-12-16

  • 1.10.27 CHANGE GLFWclient (#2171)

    • description: decouple Raytracer from GlfwClient

    • date resolved: 2025-12-26 00:03, date raised: 2025-12-26

  • 1.10.26 CHANGE GLFWclient (#2168)

    • description: decouple GlfwClientBitmapText.h from USE_GLFW_GRAPHICS as it does not require OpenGL and GLFW

    • date resolved: 2025-12-25 22:47, date raised: 2025-12-25

  • 1.10.25 CHANGE perspective (#2165)

    • description: improve perspective for raytracer, accepting values > 1

    • date resolved: 2025-12-16 14:30, date raised: 2025-12-16

  • 1.10.24 EXTENSION multiSampling (#2164)

    • description: allow 3 as value for multisampling, in accordance with raytracer

    • date resolved: 2025-12-16 14:29, date raised: 2025-12-16

  • 1.10.23 EXTENSION raytracer (#2146)

    • description: improve performance of line-triangle cuts by skipping bounding boxes further away

    • date resolved: 2025-12-15 00:47, date raised: 2025-09-23

  • 1.10.22 EXTENSION Create functions (#2163)

    • description: extend Create functions in MainSystemExtensions to accept marker indices in bodyNumbers in connector and joint functions when useful for flexible bodies - CreateSpringDamper, CreateRevoluteJoint, etc.

    • date resolved: 2025-12-13 01:11, date raised: 2025-12-13

  • 1.10.21 FIX raytracer (#2162)

    • description: lines: adjust functionality to openGL settings; currently mesh edges and face edges draw with same settings

    • date resolved: 2025-12-12 23:26, date raised: 2025-12-12

  • 1.10.20 CHANGE __init__.py, AVX2 (#2161)

    • description: remove numpy determination of AVX2 support and just use try-except approach; should work better with newer numpy versions

    • date resolved: 2025-12-08 17:08, date raised: 2025-12-08

  • 1.10.19 EXTENSION resolved by: S. Weyrer FEMinterface (#2160)

    • description: add function Get BoundaryNodeSetsAsLists to retrieve boundary node sets as two lists containing nodes list and weights list

    • date resolved: 2025-11-27 10:11, date raised: 2025-11-27

  • 1.10.18 EXTENSION FEMinterface (#2159)

    • description: nodeSets receive additional “type” information, e.g. used to indicate boundary node sets in CreateNGsolveBoundaryNodeSets

    • date resolved: 2025-11-27 10:09, date raised: 2025-11-27

  • 1.10.17 EXTENSION FEMinterface (#2158)

    • description: add metaData dictionary for optional information and source of mesh/model

    • notes: switching to FEM fileVersion 4

    • date resolved: 2025-11-27 10:08, date raised: 2025-11-27

  • 1.10.16 FIX resolved by: S. Weyrer FEMinterface (#2157)

    • description: ComputeHurtyCraigBamptonModesNGsolve: change dtype=np.int into dtype=int to comply with numpy

    • date resolved: 2025-11-27 10:06, date raised: 2025-11-27

  • 1.10.15 FIX Exudyn version (#2156)

    • description: version shown as unknown in readthedocs page

    • date resolved: 2025-11-11 15:12, date raised: 2025-11-11

  • 1.10.14 EXTENSION renderer (#2152)

    • description: add function RedrawAndGetImage to directly obtain numpy array with RGB image data to be used with matplotlib imshow

    • date resolved: 2025-10-17 18:38, date raised: 2025-10-17

  • 1.10.13 FIX general.showHelpOnStartup (#2151)

    • description: only allows values >0 but 0 required to turn of message

    • date resolved: 2025-10-17 18:37, date raised: 2025-10-17

  • 1.10.12 CHANGE simulation (#2150)

    • description: add smiley and frowney for end of simulation

    • date resolved: 2025-10-17 09:14, date raised: 2025-10-17

  • 1.10.11 CHANGE UTF-8 encoding (#2149)

    • description: unify internal character representation, add full greek letters and sub/super indices for numbers

    • notes: some special characters may now appear differently!

    • date resolved: 2025-10-16 23:02, date raised: 2025-10-16

  • 1.10.10 FIX InteractiveDialog (#2148)

    • description: problems showing marker as set_data in matplotlib does not accept scalars any more

    • date resolved: 2025-10-13 10:14, date raised: 2025-10-13

  • 1.10.9 EXTENSION raytracer (#2145)

    • description: add smoothing filter for shadows, only applied in case that values in kernel are not containing 0 and 1 (which could be real edges)

    • notes: smoothing done at low resolution shadow map, using number of shadowSmoothingSteps

    • date resolved: 2025-09-30 15:17, date raised: 2025-09-23

  • 1.10.8 EXTENSION raytracer (#2144)

    • description: improve smooth shadows performance by precomputation of smoothed shadow map (without multisampling)

    • notes: added raytracer options shadowScalingFactor and shadowSmoothingSteps; default values work well with lightRadiusVariations=31

    • date resolved: 2025-09-30 15:14, date raised: 2025-09-23

  • 1.10.7 FIX raytracer (#2143)

    • description: improve smooth shadows by adding radius variations for lightRadius

    • date resolved: 2025-09-23 12:26, date raised: 2025-09-23

  • 1.10.6 CHANGE resolved by: S. Holzinger Lie group sigma (#2142)

    • description: improve accuracy of implicit Lie group integrator; to activate set timeIntegration.generalizedAlpha.lieGroupSimplifiedKinematicRelations = False; see paper Holzinger, Arnold, Gerstmayr. Sigma-modified Lie group generalized alpha methods for constrained multibody systems, 2025 (to be sumitted)

    • date resolved: 2025-08-07 13:40, date raised: 2025-08-07

  • 1.10.5 FIX MacOS Rosetta (#1650)

    • description: importing numpy gives Intel MKL Warning: Support of Intel Streaming SIMD Extensions 4.2 … has been deprecated. Intel oneAPI Math Kernel Library 2025.0 will require AVX instructions

    • notes: works at least with Exudyn 1.10.0; Rosetta will be abandoned in future, if compilation does not work any more

    • date resolved: 2025-07-11 15:59, date raised: 2023-07-20

  • 1.10.4 TESTING Save as PNG (#1026)

    • description: check MacOS implementation if glfw works with saving PNG files

    • notes: resolved earlier; works with Exudyn 1.10.0

    • date resolved: 2025-07-11 15:58, date raised: 2022-04-02

  • 1.10.2 FIX resolved by: P. Manzl CreateDistanceSensor (#2141)

    • description: args storeInternal and fileName not used

    • date resolved: 2025-07-10 16:53, date raised: 2025-07-10

  • 1.10.1 FIX linux (#2139)

    • description: time seems to be non-initilized in linux version

    • date resolved: 2025-07-10 01:56, date raised: 2025-07-10

  • 1.10.0 EXTENSION Mechanisms (#2123)

    • description: Add example for gear and toothed rack mounted on body, using relative translation/rotation marker

    • notes: see Example involuteGearGraphics.py

    • date resolved: 2025-07-09 18:43, date raised: 2025-07-02

Version 1.9

  • 1.9.234 EXTENSION Mechanisms (#2122)

    • description: Add example for two gears mounted on a body with revolute joints, using CoordinateSpringDamperExt

    • notes: see Example involuteGearGraphics.py

    • date resolved: 2025-07-09 18:10, date raised: 2025-07-02

  • 1.9.233 DOCU general open source (#2137)

    • description: add some warnings at beginning of docu regarding open source and potential errors

    • date resolved: 2025-07-09 18:07, date raised: 2025-07-05

  • 1.9.232 DOCU RST, latex (#2138)

    • description: fill issues with references in RST and latex files

    • date resolved: 2025-07-05 18:29, date raised: 2025-07-05

  • 1.9.231 FIX TestSuite (#2135)

    • description: put all variables into static TestSuite class, to avoid unintentionally changing variables in the testsuite scope by models

    • date resolved: 2025-07-05 15:07, date raised: 2025-07-05

  • 1.9.230 CHANGE trackerlog (#2136)

    • description: change to utf-8 format; this may cause problems when loading old (backup) files, which shall be manually changed to utf-8

    • date resolved: 2025-07-05 14:54, date raised: 2025-07-05

  • 1.9.229 TESTING ContactSphereTriangle (#2134)

    • description: add test example using CreateSphereQuadContact with two contacting bodies to check momentum conservation

    • date resolved: 2025-07-05 12:10, date raised: 2025-07-05

  • 1.9.228 FIX ContactSphereTriangle (#2133)

    • description: marker transformation missing for contact computation

    • date resolved: 2025-07-05 11:10, date raised: 2025-07-05

  • 1.9.227 CHANGE nodes (#2132)

    • description: letter N for basis only shown in case that nodes.showNumbers=True

    • date resolved: 2025-07-05 10:46, date raised: 2025-07-05

  • 1.9.226 FIX MarkerBodiesRelativeRotationCoordinate (#2129)

    • description: does not work without nodeNumber provided

    • date resolved: 2025-07-03 22:21, date raised: 2025-07-03

  • 1.9.225 EXTENSION Involute gear (#2121)

    • description: add function to generate graphics for toothed rack

    • date resolved: 2025-07-03 18:33, date raised: 2025-07-02

  • 1.9.224 EXTENSION SolidExtrusion (#2128)

    • description: add relative rotation and relative offset for second surface of extrusion; used e.g. for helical gears

    • date resolved: 2025-07-03 16:48, date raised: 2025-07-03

  • 1.9.223 EXTENSION Involute gear (#2126)

    • description: add function to create involute gear graphics

    • date resolved: 2025-07-03 15:37, date raised: 2025-07-03

  • 1.9.222 EXTENSION BallBearing (#2125)

    • description: add function to create ball bearing into machines; similar to issue 2031

    • date resolved: 2025-07-03 14:57, date raised: 2025-07-03

  • 1.9.221 EXTENSION Involute gear (#2118)

    • description: add function to create involute gear profile

    • date resolved: 2025-07-03 12:57, date raised: 2025-07-02

  • 1.9.220 EXTENSION BallBearing (#2031)

    • description: put function into machines module; function shalll take two markers (for outer and inner ring), which represent the interface to other bodies; add simple test model

    • date resolved: 2025-07-03 09:20, date raised: 2025-05-18

  • 1.9.219 EXTENSION BallBearing (#2124)

    • description: add graphics function to create rings of ball bearings

    • date resolved: 2025-07-03 09:19, date raised: 2025-07-03

  • 1.9.218 EXTENSION Involute gear (#2119)

    • description: add function to generate graphics for involute gear

    • date resolved: 2025-07-02 09:40, date raised: 2025-07-02

  • 1.9.217 EXTENSION MarkerRelative (#2117)

    • description: add offset to MarkerBodiesRelativeRotationCoordinate

    • date resolved: 2025-07-01 23:00, date raised: 2025-07-01

  • 1.9.216 EXTENSION MarkerRelativeRotation (#2112)

    • description: Consider marker MarkerBodiesRelativeRotationCoordinate which measures scalar relative rotation, in particular rotation relative between two bodies; action is realized as torques on two bodies, using body-fixed coordinates of body0

    • date resolved: 2025-07-01 20:09, date raised: 2025-06-25

  • 1.9.215 EXTENSION Raytracer (#2116)

    • description: add line color

    • date resolved: 2025-07-01 14:22, date raised: 2025-07-01

  • 1.9.214 EXTENSION Raytracer (#2115)

    • description: make raytracer compatible with facesTransparent, showFaces, showFaceEdges

    • date resolved: 2025-07-01 14:22, date raised: 2025-07-01

  • 1.9.213 EXTENSION resolved by: S. Weyrer FEM (#2114)

    • description: add function GetRigidBodyInertia to return RigidBodyInertia of nodal position-based FEM models

    • date resolved: 2025-06-30 14:30, date raised: 2025-06-30

  • 1.9.212 EXTENSION MarkerRelativeTranslation (#2111)

    • description: Consider marker MarkerBodiesRelativeTranslationCoordinate which measures scalar relative translation, in particular relative displacement between two bodies; action is realized as forces on two bodies, using body-fixed coordinates of body0

    • date resolved: 2025-06-29 23:16, date raised: 2025-06-25

  • 1.9.211 EXTENSION CreateSphereQuadContact (#1961)

    • description: add create function, which uses 2 CreateSphereTriangleContact elements; should be practical for simple robots, etc.

    • date resolved: 2025-06-29 12:01, date raised: 2025-02-24

  • 1.9.210 EXTENSION CreateSphereSphereContact (#1958)

    • description: add Create function, including data node; similar to spring-damper; add checks that in case of friction, a rigid body marker is required

    • date resolved: 2025-06-29 11:06, date raised: 2025-02-24

  • 1.9.209 FIX ExportSTL (#2113)

    • description: invertNormals and invertTriangles not used

    • date resolved: 2025-06-25 17:18, date raised: 2025-06-25

  • 1.9.208 FIX parallel (#2050)

    • description: check global counters in parallelized computations which cause huge cache issues

    • notes: current issues seem to be related to fetch_add (use task stealing?) and cache-polution between different PARALLEL_FOR loops

    • date resolved: 2025-06-24 23:32, date raised: 2025-05-26

  • 1.9.207 TESTING ContactSphereTriangle (#2108)

    • description: test with explicit integration

    • date resolved: 2025-06-22 16:54, date raised: 2025-06-21

  • 1.9.206 TESTING ContactSphereSphere (#2107)

    • description: test with explicit integration

    • date resolved: 2025-06-22 16:54, date raised: 2025-06-21

  • 1.9.205 FIX Examples and TestModels (#2105)

    • description: remove uncommitted test files from Examples and TestModels as they are included as examples in theDoc

    • date resolved: 2025-06-21 22:48, date raised: 2025-06-19

  • 1.9.204 CHANGE automatic code (#2102)

    • description: avoid writing dates to systemstrutures files and others

    • date resolved: 2025-06-19 00:22, date raised: 2025-06-18

  • 1.9.203 DOCU docu (#2018)

    • description: when searching for keywords in examples, exclude matches (like MassMatrix) where the character before or after the keyword is a letter (a-zA-Z) to avoid wrong matches!

    • date resolved: 2025-06-18 22:22, date raised: 2025-05-15

  • 1.9.202 FIX FEMinterface (#2104)

    • description: add try except to automatic nodeSet creation in case that there are no boundaries computable

    • date resolved: 2025-06-18 18:17, date raised: 2025-06-18

  • 1.9.201 EXTENSION Item selection (#2103)

    • description: write currently selected item (+type, etc.) into renderer.state

    • date resolved: 2025-06-18 17:00, date raised: 2025-06-18

  • 1.9.200 EXTENSION parallel (#2101)

    • description: add simulationSettings.parallel.useLoadBalancing to switch two multithreading modes

    • date resolved: 2025-06-18 12:00, date raised: 2025-06-18

  • 1.9.199 CHANGE taskmanager (#1695)

    • description: extend microthreading for taskmanager-based load management; remove taskmanager from repo and create pure BSD license

    • notes: in C++ ExuThreading being now the only mode; optionally use exu.special.solver.multiThreadingLoadBalancing to switch load balancing on/off

    • date resolved: 2025-06-18 10:00, date raised: 2023-11-19

  • 1.9.198 FIX Command window (#2100)

    • description: does not show edit dialog

    • date resolved: 2025-06-16 14:52, date raised: 2025-06-16

  • 1.9.197 EXTENSION contour (#2099)

    • description: add alpha channel visualizationSettings option for contour colors

    • date resolved: 2025-06-16 11:28, date raised: 2025-06-16

  • 1.9.196 EXTENSION graphics.CheckerBoard (#2098)

    • description: add arg materialIndex for graphics material of both colors

    • date resolved: 2025-06-16 11:03, date raised: 2025-06-16

  • 1.9.195 TESTING ContactSphereTriangle (#2096)

    • description: add test model sphereTriangleTest.py

    • date resolved: 2025-06-15 19:56, date raised: 2025-06-15

  • 1.9.194 TESTING CreateKinematicTree (#2095)

    • description: add test model

    • notes: add test model createKinematicTreeTest.py

    • date resolved: 2025-06-15 19:55, date raised: 2025-06-15

  • 1.9.193 EXTENSION ObjectContactSphereTriangle (#1960)

    • description: add contact similar to GeneralContact and to ObjectContactSphereSphere, but being able to be computed implicitly; add option to exclude certain edges to be able to also correctly handle meshes

    • date resolved: 2025-06-15 11:50, date raised: 2025-02-24

  • 1.9.192 BUG ContactSphereSphere (#2094)

    • description: ContactSphereSphere and ContactSphereTorus set frictionRegularizedRegion wrong in case of computeFromData

    • notes: now leads to improved convergence

    • date resolved: 2025-06-15 09:37, date raised: 2025-06-15

  • 1.9.191 EXTENSION FEMinterface (#2092)

    • description: ComputePostProcessingModesNGsolve: extend for multi-material coefficient function, using materials dict;

    • date resolved: 2025-06-14 10:40, date raised: 2025-06-13

  • 1.9.190 EXTENSION FEMinterface (#2090)

    • description: extend ImportMeshFromNGsolve to include several materials given as dict of materials

    • date resolved: 2025-06-14 10:31, date raised: 2025-06-13

  • 1.9.189 EXTENSION FEMinterface (#2089)

    • description: add function to compute nodeSets from NGsolve boundary names: CreateNGsolveBoundaryNodeSets

    • date resolved: 2025-06-14 10:31, date raised: 2025-06-13

  • 1.9.188 EXTENSION FEMinterface (#2088)

    • description: add internal function to get node numbers of NGsolve boundary condition: GetNodesOfNGsolveBoundary

    • date resolved: 2025-06-14 10:31, date raised: 2025-06-13

  • 1.9.187 EXTENSION FEMinterface (#2093)

    • description: adapt class KirchhoffMaterial for multi-domain materials

    • date resolved: 2025-06-14 10:30, date raised: 2025-06-14

  • 1.9.186 CHANGE FEMinterface (#2091)

    • description: remove deprecated arg computeEigenmodes from ImportMeshFromNGsolve

    • date resolved: 2025-06-13 22:16, date raised: 2025-06-13

  • 1.9.185 CHANGE GetOtherMarker (#2087)

    • description: return MarkerBodyRigid as body anyway must provide position and orientation

    • date resolved: 2025-06-13 22:13, date raised: 2025-06-13

  • 1.9.184 EXTENSION CreateKinematicTree (#2067)

    • description: add Create function for KinematicTree, using list of TreeLink; add special class TreeLink to itemInterface

    • date resolved: 2025-06-10 08:52, date raised: 2025-05-29

  • 1.9.183 EXTENSION SolidOfRevolution (#2083)

    • description: add check to graphics.SolidOfRevolution that order of list is correct (leads to correct inside-outside relations)

    • date resolved: 2025-06-10 01:02, date raised: 2025-06-09

  • 1.9.182 EXTENSION RigidBodyInertia (#2086)

    • description: Add GetGraphics for combined inertia and graphics generation

    • date resolved: 2025-06-09 12:31, date raised: 2025-06-09

  • 1.9.181 FIX graphics (#2056)

    • description: Renderer raises warning that some objects contain inconsistencies between computed triangle normals and vertex normals

    • notes: mainly due to SolidOfRevolution

    • date resolved: 2025-06-09 01:14, date raised: 2025-05-28

  • 1.9.180 CHANGE SolidOfRevolution (#2085)

    • description: switch triangle order in SolidOfRevolution to have consistent normals and triangles

    • date resolved: 2025-06-09 01:06, date raised: 2025-06-09

  • 1.9.179 CHANGE drawFaceNormals (#2084)

    • description: openGL.drawFaceNormals shall draw the computed normal from the triangle points, thus showing the correct orientation of triangles

    • date resolved: 2025-06-09 00:48, date raised: 2025-06-09

  • 1.9.178 FIX shadow (#2082)

    • description: add lightPositionsInCameraFrame flag to shadow computation to consistently draw shadow and lights in openGL

    • date resolved: 2025-06-08 18:11, date raised: 2025-06-08

  • 1.9.177 TESTING HDF5 (#2080)

    • description: Add test with all data types

    • notes: added example testHDF5loadSave.py

    • date resolved: 2025-06-08 18:11, date raised: 2025-06-08

  • 1.9.176 BUG LoadDictFromHDF5 (#2079)

    • description: does not correctly convert np.array inside list

    • date resolved: 2025-06-08 18:11, date raised: 2025-06-07

  • 1.9.175 EXTENSION GL_LIGHT (#2081)

    • description: add option to switch between local and global lights, to be compatible with Raytracer

    • notes: added option openGL.lightPositionsInCameraFrame to switch behavior; in raytracer, this setting is always True

    • date resolved: 2025-06-08 15:44, date raised: 2025-06-08

  • 1.9.174 EXTENSION netgen (#2078)

    • description: add option to convert netgen / ngsolve mesh into points, triangles and normals including smooth geometries

    • date resolved: 2025-06-07 19:12, date raised: 2025-06-07

  • 1.9.173 EXTENSION Raytracer (#2077)

    • description: light radius receives circular variation normal to ray, giving an effient and good effect of spherical lights; use lightRadius and lightRadiusVariations

    • date resolved: 2025-06-05 21:03, date raised: 2025-06-05

  • 1.9.172 EXTENSION Raytracer (#2076)

    • description: add option for spherical lights with radius and random sampling

    • notes: added lightRadius

    • date resolved: 2025-06-04 17:52, date raised: 2025-06-04

  • 1.9.171 DOCU Raytracer (#2059)

    • description: add short docu part

    • notes: example available in Examples/newtonsCradle.py

    • date resolved: 2025-06-04 10:58, date raised: 2025-05-28

  • 1.9.170 EXTENSION invert triangles (#2074)

    • description: Add function to invert triangles and normals of graphicsData, e.g., for inverted sphere or brick

    • notes: added graphics.InvertTriangles and ConsistentTriangleList

    • date resolved: 2025-06-04 01:37, date raised: 2025-06-02

  • 1.9.169 EXTENSION Raytracer (#2061)

    • description: add materials interface via SystemContainer: renderer.SetMaterial(index, dict), dict=GetMaterial(index)

    • notes: can do read [] access, Set(), New(), etc.

    • date resolved: 2025-06-03 16:06, date raised: 2025-05-28

  • 1.9.168 EXTENSION Raytracer (#2063)

    • description: make first 10 materials in renderer accessible via visualization systems dialog

    • date resolved: 2025-06-03 16:05, date raised: 2025-05-28

  • 1.9.167 EXTENSION Raytracer (#2060)

    • description: adjust minZ and line offset to scene dimension

    • date resolved: 2025-06-02 17:45, date raised: 2025-05-28

  • 1.9.166 EXTENSION Raytracer (#2058)

    • description: add separate visualization options; keep lights

    • date resolved: 2025-06-02 17:45, date raised: 2025-05-28

  • 1.9.165 CHECK Renderer timeout (#2070)

    • description: check whether calling glfwWaitEventsTimeout, glfwPollEvents or glfwSwapBuffers fixes problems with redraw timeouts with Raytracing

    • notes: can be done with option raytracer.keepWindowActive

    • date resolved: 2025-06-02 17:44, date raised: 2025-05-31

  • 1.9.164 EXTENSION Raytracer (#2069)

    • description: add global fog and material fog

    • notes: only global fog added

    • date resolved: 2025-06-02 17:44, date raised: 2025-05-29

  • 1.9.163 EXTENSION Raytracer (#2068)

    • description: activate cutting plane for raytracer; include in function IntersectRayWithTriangles, which shall first check for cutting plane and only takes then objects behind cutting plane (if hit); color is then taken from triangle behind cutting plane-without reflections and shadows

    • date resolved: 2025-06-02 17:44, date raised: 2025-05-29

  • 1.9.162 EXTENSION font bitmaps (#2073)

    • description: Add smoothing at pixel level for base text fonts (at grey scale) to obtain smoother fonts

    • date resolved: 2025-06-01 22:53, date raised: 2025-06-01

  • 1.9.161 CHANGE renderer (#2072)

    • description: exu.StartRenderer() and exu.StopRenderer() are changed into SC.renderer.Start() and SC.renderer.Stop(), having a SystemContainer SC

    • notes: NOTE that this affects your existing models a lot!

    • date resolved: 2025-06-01 19:13, date raised: 2025-06-01

  • 1.9.160 EXTENSION Raytracer (#2071)

    • description: draw system message texts as overlay of render image

    • date resolved: 2025-06-01 18:00, date raised: 2025-06-01

  • 1.9.159 CHANGE renderer (#2036)

    • description: put renderer-related functions into SystemContainer; preserve compatibility; consider substructure renderer in SC to collect rendering-related functionality

    • date resolved: 2025-06-01 02:36, date raised: 2025-05-21

  • 1.9.158 CHANGE renderer (#2037)

    • description: homogenize WaitForUserToContinue, DoRendererIdleTasks, DoIdleOperations and WaitForRenderEngineStopFlag as they are widely identical; homogenize functionality; note that DoRendererIdleTasks() with default args has to be replaced by renderer.DoIdleTasks(0)

    • notes: merged into SC.renderer.DoIdleTasks(); NOTE that this change affects your existing models a lot!

    • date resolved: 2025-06-01 02:35, date raised: 2025-05-21

  • 1.9.157 EXTENSION resolved by: CHANGE renderer (#2062)

    • description: add renderer substructure to SystemContainer (with backlink to MainSystemContainer)

    • notes: all examples, test models, teaching models and exudyn submodules adapted; old functionality preserved so far with warnings

    • date resolved: 2025-06-01 02:34, date raised: 2025-05-28

  • 1.9.156 EXTENSION visualization (#2045)

    • description: use templated function to have only one single function for triangle drawing

    • date resolved: 2025-05-30 01:01, date raised: 2025-05-22

  • 1.9.155 EXTENSION graphics (#2066)

    • description: add option for special shape of graphics.Brick with rounded edges, offering a transition to an ellipsoid

    • date resolved: 2025-05-30 00:59, date raised: 2025-05-29

  • 1.9.154 FIX SetRenderState (#2049)

    • description: seems to ignore autoFitScene = False and therefore does not reload zoom factor

    • notes: SetRenderState is extended by a flag which by default waits until the renderer is fully started or redrawn; this can impede performance, which is why this should be set to False in such cases

    • date resolved: 2025-05-29 16:22, date raised: 2025-05-26

  • 1.9.153 CHANGE SimulationSettings (#2065)

    • description: timeIntegration.numberOfSteps: change type to Real in order to accept steps as Python float; add warning in solver if numberOfSteps deviates significantely from integer number

    • date resolved: 2025-05-29 15:33, date raised: 2025-05-29

  • 1.9.152 CHANGE exudyn.config (#2064)

    • description: move further options to config: SetWriteToConsole, flush always, etc.

    • date resolved: 2025-05-29 14:47, date raised: 2025-05-29

  • 1.9.151 FIX PrintDelayed (#2057)

    • description: printing from visualiuation thread: buffer is never emptied; use idle tasks to do so

    • date resolved: 2025-05-28 01:12, date raised: 2025-05-28

  • 1.9.150 CHANGE exudyn.Print (#2055)

    • description: replace print commands in exudyn modules by exudyn.Print(…) in order to have common handling of file writing, etc.

    • date resolved: 2025-05-28 00:08, date raised: 2025-05-28

  • 1.9.149 BUG GeneticOptimization (#2054)

    • description: computationIndex and parameterFunctionData do not work except for first generation

    • date resolved: 2025-05-27 23:39, date raised: 2025-05-27

  • 1.9.148 EXTENSION exudyn.Print (#2052)

    • description: function shall accept kwargs end, flush and sep in order to be more compatible with original Python print

    • date resolved: 2025-05-27 22:39, date raised: 2025-05-27

  • 1.9.147 FIX FEM (#2053)

    • description: ComputePostProcessingModes raises error for larger problems due to print command

    • date resolved: 2025-05-27 22:16, date raised: 2025-05-27

  • 1.9.146 FIX Raytracer (#2051)

    • description: resolve parallelization issue by removing global hit count

    • date resolved: 2025-05-26 18:58, date raised: 2025-05-26

  • 1.9.145 EXTENSION Raytracer (#2048)

    • description: add Raytracer as option; map options from openGL to Raytracer (lights, material, multiSampling, shadow, perspective, etc.)

    • date resolved: 2025-05-26 10:51, date raised: 2025-05-26

  • 1.9.144 EXTENSION graphics.Quad (#2047)

    • description: add normals; also affects graphics.CheckerBoard; normals are not needed, but may be modified in transformations

    • date resolved: 2025-05-25 15:40, date raised: 2025-05-25

  • 1.9.143 EXTENSION Raytracer (#2046)

    • description: add CPU-based software renderer / raytracer als option to render images for animations

    • notes: note that this is experimental; image resolution shall be small (start with 400x300) as long render times may lead to problems

    • date resolved: 2025-05-25 12:32, date raised: 2025-05-25

  • 1.9.142 EXTENSION visualization (#2044)

    • description: add option to sort transparent triangles to improve quality of transparent objects; use simple depth sort for triangle midpoints

    • notes: added option openGL.depthSorting which sorts triangles by their depth for improved transparency view (but requires triangles to be small enough)

    • date resolved: 2025-05-22 16:35, date raised: 2025-05-22

  • 1.9.141 FIX stub files (.pyi) (#2043)

    • description: revise section for exudyn stubs in order to enable completion of exudyn.config and other exudyn functions

    • notes: seems that removing erroneous info like “special.” was sufficient to work

    • date resolved: 2025-05-22 11:00, date raised: 2025-05-22

  • 1.9.140 EXTENSION InertiaSphere (#2033)

    • description: use density and radius to initialize as alternative option

    • date resolved: 2025-05-22 10:32, date raised: 2025-05-20

  • 1.9.139 CHANGE exudyn (#2042)

    • description: move exudyn.SetLinalgOutputFormatPython(), exudyn.SetOutputPrecision(), exudyn.SetPrintDelayMilliSeconds(), exudyn.SuppressWarnings(), exudyn.InfoStat(), exudyn.GetVersionString() to according variables and functions in exudyn.config, see current docu

    • date resolved: 2025-05-22 09:30, date raised: 2025-05-22

  • 1.9.138 CHANGE exudyn.Solve (#2041)

    • description: remove exudyn.SolveStatic exudyn.SolveDynamic and exudyn.ComputeODE2Eigenvalues from exudyn, being only available in MainSystem as mbs.SolveDynamic, etc.

    • date resolved: 2025-05-22 08:35, date raised: 2025-05-22

  • 1.9.137 CHANGE exudyn.Demo1() (#2040)

    • description: and exudyn.Demo2() only available as exudyn.demos.Demo1() or .Demo2()

    • date resolved: 2025-05-22 07:56, date raised: 2025-05-22

  • 1.9.136 CHANGE exudyn.Go() (#2039)

    • description: remove function Go() which is not intended to be used

    • date resolved: 2025-05-22 07:44, date raised: 2025-05-22

  • 1.9.135 CHANGE exudyn.SetOutputPrecision (#2038)

    • description: moved to exudyn.config.outputPrecision

    • date resolved: 2025-05-22 07:21, date raised: 2025-05-22

  • 1.9.134 EXTENSION exudyn module (#1630)

    • description: consider settings instead of putting all variables globally into module

    • date resolved: 2025-05-22 07:20, date raised: 2023-06-23

  • 1.9.133 CHANGE exudyn.config (#2035)

    • description: collect specific settings into config structure, see also issue 1630

    • date resolved: 2025-05-22 07:19, date raised: 2025-05-21

  • 1.9.132 EXTENSION Sensors.traces (#2034)

    • description: add trace time span for past and future traces, to limit length of traces

    • date resolved: 2025-05-20 08:19, date raised: 2025-05-20

  • 1.9.131 FIX sensor traces (#2032)

    • description: wrong description using visualizationSettings.sensorTraces in docu

    • date resolved: 2025-05-20 08:19, date raised: 2025-05-20

  • 1.9.130 EXTENSION OutputVariables (#2028)

    • description: add outputvariables to ContactSphereTorus

    • date resolved: 2025-05-19 20:18, date raised: 2025-05-18

  • 1.9.129 CHANGE ObjectContactFrictionCircleCable2DOld (#2024)

    • description: remove outdated object

    • date resolved: 2025-05-18 23:35, date raised: 2025-05-17

  • 1.9.128 EXTENSION SolidOfRevolution (#2030)

    • description: add smoothingAngle for contour below which smoothing is applied

    • date resolved: 2025-05-18 15:35, date raised: 2025-05-18

  • 1.9.127 EXTENSION graphics (#2029)

    • description: add start and end angle for minor radius of torus

    • date resolved: 2025-05-18 11:24, date raised: 2025-05-18

  • 1.9.126 EXTENSION ContactTorusSphere (#2022)

    • description: add basic contact element; typically used for ball bearings; similar to ContactSphereSphere

    • date resolved: 2025-05-18 00:03, date raised: 2025-05-16

  • 1.9.125 CHANGE CreateRigidBody (#2027)

    • description: if graphicsDataList is provided, node shall still be shown, but drawsize gets 0; this allows to easily show the node basis

    • notes: also done for CreateMassPoint

    • date resolved: 2025-05-17 23:30, date raised: 2025-05-17

  • 1.9.124 EXTENSION graphics Tube (#2026)

    • description: add function graphics.Tube which generates graphicsData for a tube along a line of points with axis vectors

    • date resolved: 2025-05-17 21:48, date raised: 2025-05-17

  • 1.9.123 EXTENSION Torus (#2025)

    • description: add graphics function for torus

    • notes: using graphics.Tube function

    • date resolved: 2025-05-17 21:48, date raised: 2025-05-17

  • 1.9.122 TESTING ContactSphereSphere (#1922)

    • description: add test model with various contact models

    • date resolved: 2025-05-17 00:15, date raised: 2024-11-02

  • 1.9.121 EXTENSION graphics.Cylinder (#2023)

    • description: add option to draw hollow cylinder

    • date resolved: 2025-05-17 00:05, date raised: 2025-05-17

  • 1.9.120 EXTENSION ContactSphereSphere (#2021)

    • description: add option to include hollow sphere - sphere contact

    • date resolved: 2025-05-16 18:10, date raised: 2025-05-16

  • 1.9.119 CHANGE version files (#2020)

    • description: remove different version files and use only a single file for .tex and .cpp

    • date resolved: 2025-05-15 21:25, date raised: 2025-05-15

  • 1.9.118 FIX Numpy2.0 (#2019)

    • description: Since Numpy2.0 __cpu_features__ are not available any more, therefore we need to find another way to automatically detect AVX2 features

    • date resolved: 2025-05-15 20:20, date raised: 2025-05-15

  • 1.9.117 FIX CObjectContactCurveCircles (#2012)

    • description: complete CheckPreAssembleConsistency

    • date resolved: 2025-05-15 08:50, date raised: 2025-05-11

  • 1.9.116 EXTENSION ContactCurveCircles (#2014)

    • description: check damping mechanism and check negative contact forces

    • date resolved: 2025-05-13 15:12, date raised: 2025-05-11

  • 1.9.115 TESTING ContactCurveCircles (#1926)

    • description: add simple test model

    • date resolved: 2025-05-11 22:53, date raised: 2024-11-04

  • 1.9.114 EXTENSION ContactCurveCircles (#2013)

    • description: add visualization for contact circles

    • date resolved: 2025-05-11 22:07, date raised: 2025-05-11

  • 1.9.113 FIX ContactSphereSphere (#2015)

    • description: radius unused in visualization

    • date resolved: 2025-05-11 21:44, date raised: 2025-05-11

  • 1.9.112 EXTENSION ContactCurveCircles (#2010)

    • description: change dynamic arrays to local temp arrays in CObject, similar to FFRF object

    • date resolved: 2025-05-11 15:36, date raised: 2025-05-11

  • 1.9.111 EXTENSION ContactCurveCircles (#2009)

    • description: draw active contact segments

    • date resolved: 2025-05-11 12:02, date raised: 2025-05-11

  • 1.9.110 EXTENSION ContactCurveCircles (#2008)

    • description: draw contact segments

    • date resolved: 2025-05-11 12:02, date raised: 2025-05-11

  • 1.9.109 BUG ContactCurveCircles (#2011)

    • description: force computation not correct regarding simultaneous contact with several segments

    • date resolved: 2025-05-11 12:01, date raised: 2025-05-11

  • 1.9.108 EXAMPLE ContactCurveCircles (#1925)

    • description: add example of chain drive

    • date resolved: 2025-05-11 12:01, date raised: 2024-11-04

  • 1.9.107 TESTING CreateTorsionalSpringDamper (#1952)

    • description: add test example

    • notes: included in createFunctionsTest

    • date resolved: 2025-05-10 23:23, date raised: 2025-02-05

  • 1.9.106 EXTENSION realtime (#2005)

    • description: measure realtime reserve in special timers

    • date resolved: 2025-05-10 23:18, date raised: 2025-05-10

  • 1.9.105 EXTENSION Create functions (#2001)

    • description: add automatism to create geometry from inertia objects by default (cylinder, sphere, brick, …); using default colors

    • date resolved: 2025-05-10 23:07, date raised: 2025-05-08

  • 1.9.104 EXTENSION RigidBodyInertia (#2006)

    • description: add self.data dictionary which stores data of special inertia classes, such as radius of cylinder, etc.; this allows to obtain geometry information

    • date resolved: 2025-05-10 20:39, date raised: 2025-05-10

  • 1.9.103 EXTENSION Create functions (#1971)

    • description: add general test model

    • date resolved: 2025-05-10 19:56, date raised: 2025-03-05

  • 1.9.102 EXTENSION CreateCoordinateConstraint (#1987)

    • description: add option to constrain coordinate of object via its nodes; add option to constrain single coordinates or even a list of coordinates

    • date resolved: 2025-05-10 19:37, date raised: 2025-04-08

  • 1.9.101 EXTENSION Delete item (#657)

    • description: add functionality to delete items, adding specific features to re-index nodes in objects/markers, etc. if a node, object or marker is deleted; add MaxItemNumber() function to systemData which returns unique name for items even after deletion

    • notes: resolved by reordering dependent items; no maxItem used

    • date resolved: 2025-05-10 01:31, date raised: 2021-05-01

  • 1.9.100 EXTENSION GetJointArgs (#2004)

    • description: add a utility function, which takes an existing marker and rotationMarker and another body to compute a new marker and rotationMarker for the other body; can be directly used as joint arguments like in revolute, prismatic or generic joints

    • date resolved: 2025-05-09 23:59, date raised: 2025-05-09

  • 1.9.99 EXTENSION GetOtherMarker (#2003)

    • description: add a utility function, which the computes a new marker from the reference position of an existing marker and another body; for easier setup of markers

    • date resolved: 2025-05-09 15:34, date raised: 2025-05-09

  • 1.9.98 EXTENSION delete (#1999)

    • description: add option to delete dependent markers when deleting loads

    • date resolved: 2025-05-09 08:08, date raised: 2025-05-08

  • 1.9.97 EXTENSION delete (#1998)

    • description: add option to delete dependent markers in connectors/joints when deleting objects

    • date resolved: 2025-05-09 08:08, date raised: 2025-05-07

  • 1.9.96 EXTENSION delete (#2000)

    • description: consistently delete loads and sensors

    • date resolved: 2025-05-08 20:57, date raised: 2025-05-08

  • 1.9.95 CHANGE BasicTraits.h (#2002)

    • description: remove and add new AdvancedStuff.h and put there sort, atomics operations, iterators, etc. which are not needed everywhere

    • date resolved: 2025-05-08 20:39, date raised: 2025-05-08

  • 1.9.94 EXTENSION delete (#1997)

    • description: consistently delete nodes and markers in MainSystem

    • date resolved: 2025-05-08 13:35, date raised: 2025-05-06

  • 1.9.93 EXTENSION CreateFunctions (#1985)

    • description: check pyi files and workflows to enable code completion and navigation in Spyder with Create functions

    • notes: shall be resolved with issue 1996, as it natively derives from C++ class

    • date resolved: 2025-05-06 22:20, date raised: 2025-04-02

  • 1.9.92 EXTENSION ObjectMassPoint (#1986)

    • description: add outputvariables rotation matrix and angular velocity (also to NodePoint) in order to allow spherical joint to be attached.

    • date resolved: 2025-05-06 22:12, date raised: 2025-04-08

  • 1.9.91 BUG Sensor (#1995)

    • description: case SensorType::KinematicTree missing in GetTypeDependentIndex

    • date resolved: 2025-05-06 17:13, date raised: 2025-05-06

  • 1.9.90 FIX pybind11 (#1994)

    • description: local files using pybind11 2.6, not suitable for Numpy >= 2.0

    • date resolved: 2025-05-06 16:44, date raised: 2025-05-06

  • 1.9.89 FIX MSVC (#1993)

    • description: compilation/execution of Exudyn in MSVC and python differ considerably

    • date resolved: 2025-05-06 16:00, date raised: 2025-05-06

  • 1.9.88 FIX CSystem (#1992)

    • description: systemIsConsistent used instead of systemIsInteger in CheckSystemIntegrity

    • date resolved: 2025-05-06 12:07, date raised: 2025-05-06

  • 1.9.87 FIX MainSystem (#1991)

    • description: Node, Object, Marker, … functions have wrong internal range check (not including invalid index)

    • date resolved: 2025-05-05 22:43, date raised: 2025-05-05

  • 1.9.86 EXTENSION delete object (#1990)

    • description: first step to fulfill issue 657; reorder markers and sensors and assign invalid object number if object is used; add assemble check function for invalid indices

    • date resolved: 2025-05-05 22:18, date raised: 2025-05-05

  • 1.9.85 EXTENSION FEM (#1984)

    • description: Load/Save of FEM and FFRF data: default value NPY switched to NPZ due to Numpy2.x conflicts; for compatibility set mode to NPY

    • notes: all load/save functions should work with npy, npz, pkl and hdf5

    • date resolved: 2025-04-01 19:21, date raised: 2025-04-01

  • 1.9.84 CHANGE FEM (#1983)

    • description: adjust Load/Save functions to by-default support hdf5 or pkl as npy does not work with numpy 2.0

    • notes: changed ObjectFFRFreducedOrderInterface and FEM class to by default use numpy NPZ format

    • date resolved: 2025-04-01 16:44, date raised: 2025-04-01

  • 1.9.83 EXTENSION SolutionViewer (#1982)

    • description: add option Make mp4 to create videos with python ffmpeg lib

    • date resolved: 2025-04-01 08:51, date raised: 2025-04-01

  • 1.9.82 EXTENSION Images2Video (#1981)

    • description: add function ConvertImages2Video and dialog InteractiveImages2Video to convert images to videos directly in Python

    • date resolved: 2025-04-01 02:20, date raised: 2025-04-01

  • 1.9.81 CHANGE PlotSensor (#1980)

    • description: change to matplotlib.get_backend().lower() when comparing with matplotlib agg render mode; this shall avoid warnings in case of plots with agg in background

    • date resolved: 2025-03-31 23:03, date raised: 2025-03-31

  • 1.9.80 FIX artificialIntelligence (#1972)

    • description: PreInitializeSolver always uses Generalized alpha solver, but should go in line with SetSolver

    • notes: this issue was erratic and is ignored; PreInitializeSolver shall be replaced by derived class calling SetSolver with the desired solverType; added remarks in artificialIntelligence.py

    • date resolved: 2025-03-31 22:42, date raised: 2025-03-06

  • 1.9.79 CHANGE mbs.Assemble() (#1976)

    • description: check if assembled in SolveStatic and SolveDynamic and automatically call mbs.Assemble() prior to solver; only raise warning

    • date resolved: 2025-03-31 22:15, date raised: 2025-03-30

  • 1.9.78 CHANGE ComputeSystemDegreeOfFreedom (#1979)

    • description: change print to exudyn.Print for workflow consistency

    • notes: also fixed other print commands in solver.py

    • date resolved: 2025-03-31 21:52, date raised: 2025-03-31

  • 1.9.77 EXTENSION SetWriteToFile (#1978)

    • description: add flushAlways (default:False) option for immediate writing to file

    • date resolved: 2025-03-31 21:48, date raised: 2025-03-31

  • 1.9.76 FIX CreateTorsionalSpringDamper (#1975)

    • description: does not work for unlimitedRotations=True due to additional comma

    • date resolved: 2025-03-12 15:08, date raised: 2025-03-12

  • 1.9.75 CHANGE CreateSphericalJoint (#1974)

    • description: Make it work for bodies that do not offer a rotation matrix (mass points)

    • date resolved: 2025-03-12 14:35, date raised: 2025-03-12

  • 1.9.74 CHANGE GeneralContact (#1973)

    • description: remove frictionVelocityPenalty as it is not used; also remove macro ANCFuseFrictionPenalty

    • date resolved: 2025-03-07 17:00, date raised: 2025-03-07

  • 1.9.73 EXTENSION CreateRollingDisc (#1970)

    • description: create test model

    • date resolved: 2025-03-05 22:36, date raised: 2025-03-05

  • 1.9.72 EXTENSION CreateRollingDisc (#1969)

    • description: add create function to MainSystem

    • date resolved: 2025-03-05 22:17, date raised: 2025-03-05

  • 1.9.71 EXTENSION GeneralContact (#1968)

    • description: add option to only use dynamic search tree with no duplicated search bins

    • notes: in case of no static triangles, static searchtree is only created once and no additional operations are performed

    • date resolved: 2025-03-05 21:11, date raised: 2025-03-03

  • 1.9.70 CHANGE Create functions (#1967)

    • description: change return values of all mbs.Create functions with joints (CreateRevoluteJoint, CreateSphericalJoint, CreatePrismaticJoint, CreateGenericJoint, CreateDistanceConstraints, …) to the object index instead of lists

    • date resolved: 2025-03-03 22:04, date raised: 2025-03-03

  • 1.9.69 EXTENSION RollingDiscPenalty (#1949)

    • description: add create function to MainSystem

    • notes: already done with issue 1957

    • date resolved: 2025-03-03 20:41, date raised: 2025-02-04

  • 1.9.68 EXTENSION GeneralContact (#1966)

    • description: SearchTree: add option to perform more accurate test for triangles: add simple check to see if bin is fully on one side of the triangle

    • date resolved: 2025-03-02 18:50, date raised: 2025-03-02

  • 1.9.67 EXTENSION GeneralContact (#1895)

    • description: add option to add static objects to GeneralContact and to SearchTree

    • date resolved: 2025-03-02 15:42, date raised: 2024-10-16

  • 1.9.66 CHANGE GeneralContact (#1965)

    • description: ODE2RHS timer removed and replaced with CSystem Contact:Overall timer (which includes PostNewtonStep)

    • date resolved: 2025-03-02 11:46, date raised: 2025-03-02

  • 1.9.65 EXTENSION resolved by: EXTENSION CuttingPlane (#1962)

    • description: add simple option for cutting plane (point, normal vector, flag) to exclude triangles and other objects from graphics

    • notes: added options openGL.clippingPlaneNormal and openGL.clippingPlaneDistance to enable simple clipping

    • date resolved: 2025-02-28 21:30, date raised: 2025-02-27

  • 1.9.64 EXTENSION Cable2D (#1964)

    • description: add setting useReducedOrderIntegration=2 to interface docu

    • date resolved: 2025-02-28 20:57, date raised: 2025-02-28

  • 1.9.63 TESTING CreateRollingDiscPenalty (#1963)

    • description: create test model

    • date resolved: 2025-02-28 00:22, date raised: 2025-02-27

  • 1.9.62 TESTING RollingDiscPenalty (#1957)

    • description: add test example

    • date resolved: 2025-02-27 16:50, date raised: 2025-02-09

  • 1.9.61 TESTING RigidBody2D (#1951)

    • description: add test for physicsCenterOfMass != 0

    • date resolved: 2025-02-05 15:08, date raised: 2025-02-05

  • 1.9.60 FIX FEM (#1955)

    • description: WarnNumpy2 contains error, as it tries to compare int with str

    • date resolved: 2025-02-05 15:04, date raised: 2025-02-05

  • 1.9.59 EXTENSION RigidBody2D (#1950)

    • description: add parameter physicsCenterOfMass, similar to RigidBody

    • date resolved: 2025-02-05 14:53, date raised: 2025-02-05

  • 1.9.58 EXTENSION mainSystemExtensions (#1581)

    • description: add LinearSpringDamper and TorsionalSpringDamper

    • notes: transferred to issues 1948 and 1953

    • date resolved: 2025-02-05 08:44, date raised: 2023-05-21

  • 1.9.57 EXTENSION CreateTorsionalSpringDamper (#1948)

    • description: add create function to MainSystem

    • date resolved: 2025-02-04 13:44, date raised: 2025-02-04

  • 1.9.56 BUG SphereSphereContact (#1946)

    • description: error in PostNewtonStep: always uses data variables

    • date resolved: 2025-02-03 15:40, date raised: 2025-02-03

  • 1.9.55 CHANGE lieGroupSimplifiedKinematicRelations (#1945)

    • description: lieGroupSimplifiedKinematicRelations used to test more accurate Lie group solver; for now, default value set to false in order to have test suite running

    • date resolved: 2025-01-28 11:53, date raised: 2025-01-28

  • 1.9.54 FIX solver (#1944)

    • description: always writes ‘Solver terminated unsuccessfully’ independently of success.

    • date resolved: 2025-01-05 18:00, date raised: 2025-01-05

  • 1.9.53 FIX RotationVector2RotationMatrix (#1479)

    • description: both in Python and C++, fix range to 0..2*pi, as large angles cause low accuracy

    • date resolved: 2024-12-01 19:13, date raised: 2023-03-27

  • 1.9.52 EXTENSION Python 3.11 (#1651)

    • description: added Python 3.11 workflows for Windows, Linux and MacOS builds (note: problems with Rosetta x86 on MacOS)

    • notes: resolved earlier also for 3.12 and 3.13

    • date resolved: 2024-12-01 12:31, date raised: 2023-07-20

  • 1.9.51 FIX NORMAL PUMA560 (#1483)

    • description: COM frames of KinematicTree drawn wrong: serialRobotInverseKinematics; check COM setting

    • notes: resolved already with issue 1857

    • date resolved: 2024-12-01 12:29, date raised: 2023-03-29

  • 1.9.50 BUG FEMinterface (#1943)

    • description: CreateNonlinearFEMObjectGenericODE2NGsolve does not work due to change in internal FEM stiffness and mass matrices, stored as scipy sparse matrices now

    • date resolved: 2024-11-27 21:24, date raised: 2024-11-27

  • 1.9.49 DOCU System equations of motion (#1942)

    • description: add missing term partial g/partial qDot in ODE2 part, in particular for non-holonomic constriants; this part was already implemented in a generic way since the very beginning, but missed to find the way into the documentation.

    • date resolved: 2024-11-18 19:15, date raised: 2024-11-18

  • 1.9.48 EXTENSION NumPy2 (#1940)

    • description: Add warning in FEM for some functions that do not work properly with NumPy 2.x

    • date resolved: 2024-11-10 19:57, date raised: 2024-11-10

  • 1.9.47 EXTENSION HDF5 load/save (#1939)

    • description: extend to None type (but excluding numpy arrays containing None!

    • date resolved: 2024-11-10 18:43, date raised: 2024-11-10

  • 1.9.46 CHANGE GraphicsData functions (#1935)

    • description: adjust graphics.Sphere, graphics.Brick, etc. to create numpy arrays for improved efficiency

    • date resolved: 2024-11-10 17:24, date raised: 2024-11-10

  • 1.9.45 CHANGE GraphicsData functions (#1936)

    • description: adjust graphics conversion functions (graphics.Move, etc.) to handle numpy arrays as well

    • date resolved: 2024-11-10 16:37, date raised: 2024-11-10

  • 1.9.44 FIX graphics.Sphere (#1938)

    • description: only works if addEdges <=1; add condition for number of edges

    • date resolved: 2024-11-10 16:09, date raised: 2024-11-10

  • 1.9.43 FIX graphics.color (#1937)

    • description: type completion not working

    • date resolved: 2024-11-10 15:32, date raised: 2024-11-10

  • 1.9.42 CHANGE GraphicsData write (#1934)

    • description: GetObject now returns GraphicsData as numpy arrays to be consistent with issue 1934

    • date resolved: 2024-11-10 14:26, date raised: 2024-11-10

  • 1.9.41 CHANGE GraphicsData read (#1933)

    • description: allow that all colors, positions, triangles, points, normals, edges, … are either lists or numpy.arrays (but flatten to 1D)

    • date resolved: 2024-11-10 14:26, date raised: 2024-11-10

  • 1.9.40 EXTENSION GraphicsData (#1929)

    • description: extend import/export function of GraphicsData for numpy arrays; speeds up load/safe significantly

    • date resolved: 2024-11-10 14:26, date raised: 2024-11-08

  • 1.9.39 FIX StaticSolver (#1908)

    • description: does not write appropriate error message, but only writes: ValueError: SolveStatic terminated due to errors

    • notes: together with 1931

    • date resolved: 2024-11-09 17:33, date raised: 2024-10-24

  • 1.9.38 CHANGE Solver (#1930)

    • description: change message when solver finishes, distinguishing between solver success and failure: ‘Solver terminated unsuccessfully’ or ‘Solver terminated unsuccessfully’

    • date resolved: 2024-11-09 17:32, date raised: 2024-11-09

  • 1.9.37 CHECK URDF (#1928)

    • description: check import from roboticstoolbox-python and pymeshlab

    • date resolved: 2024-11-08 22:31, date raised: 2024-11-08

  • 1.9.36 EXTENSION SaveDictToHDF5 (#1927)

    • description: extend for saving int32, int64, float32 and float64

    • date resolved: 2024-11-08 22:30, date raised: 2024-11-08

  • 1.9.35 EXTENSION ContactCurveCircles (#1923)

    • description: add special contact element between curve defined by segments in contact with circles; 2D curves and circle co-move with rigid body marker at which curve is attached; enables Cam-follower mechanism, chain-sprocket contact, etc.

    • date resolved: 2024-11-04 23:36, date raised: 2024-11-04

  • 1.9.34 EXTENSION ContactSphereSphere (#1921)

    • description: add option to use restitution coefficient

    • date resolved: 2024-11-04 23:32, date raised: 2024-11-02

  • 1.9.33 EXTENSION resolved by: S. Weyrer ContactSphereSphere (#1919)

    • description: extend for nonlinear contact models; in particular restitution coefficient and adhesive elasto-plastic contact model

    • date resolved: 2024-11-04 23:32, date raised: 2024-11-02

  • 1.9.32 EXTENSION ContactSphereSphere (#1918)

    • description: add basic contact object for sphere-sphere contact, with options for linear and nonlinear contact models as well as adhesion

    • date resolved: 2024-11-02 11:49, date raised: 2024-11-02

  • 1.9.31 EXTENSION useRecommendedStepSize (#1917)

    • description: add option in timeIntegration.discontinuous to turn on/off step size recommendations for contact and other discontinuous phenomena

    • date resolved: 2024-11-02 11:46, date raised: 2024-11-02

  • 1.9.30 DOCU KinematicTree (#1916)

    • description: add clarification for order to application of joint offset and joint transformation (rotation)

    • date resolved: 2024-10-30 10:56, date raised: 2024-10-30

  • 1.9.29 EXTENSION RigidBodyInertia (#1915)

    • description: add warning in case of unphysical inertia parameters

    • date resolved: 2024-10-29 22:26, date raised: 2024-10-29

  • 1.9.28 CHANGE GeneralContact (#1914)

    • description: GetSystemODE2RhsContactForces: change argument reference to copy to make it more consistent with other reference access and avoid confusion with reference configuration; default behavior unchanged

    • date resolved: 2024-10-27 10:13, date raised: 2024-10-27

  • 1.9.27 EXTENSION MainSystem.systemData (#1913)

    • description: add function GetODE2CoordinatesTotal which includes reference values added to coordinates

    • date resolved: 2024-10-27 10:00, date raised: 2024-10-27

  • 1.9.26 CHANGE OutputVariableType (#1911)

    • description: change order of types, leading to different numerical values behind OutputVariableType enum (should not affect normal codes)

    • notes: affected by issue 1909

    • date resolved: 2024-10-26 19:30, date raised: 2024-10-26

  • 1.9.25 EXTENSION OutputVariableType (#1909)

    • description: Add CoordinatesTotal which includes the reference configuration for output variables, used in sensors, or object and node outputs

    • date resolved: 2024-10-26 19:26, date raised: 2024-10-26

  • 1.9.24 EXTENSION reference coordinates (#1505)

    • description: add option to get total coordinates, being reference + current coordinates; gives 4 new configurations; use harmonized interface functions

    • date resolved: 2024-10-26 19:26, date raised: 2023-04-08

  • 1.9.23 EXTENSION particles (#1897)

    • description: Add particles module with functionality for creating densly packed particles in a box with proper regular initialization

    • date resolved: 2024-10-19 20:57, date raised: 2024-10-16

  • 1.9.22 EXTENSION GeneralContact (#1903)

    • description: GetSystemODE2RhsContactForces(…): add additional arg reference in order to allow linking to contact forces and thus allowing faster access (writing to this vector has no effect!)

    • date resolved: 2024-10-19 18:59, date raised: 2024-10-19

  • 1.9.21 CHANGE FEMinterface (#1902)

    • description: store elements as consistently as np.array instead of list of lists; check that all large arrays are np.arrays; do this also for surface list of lists

    • notes: now all previous list of lists in FEMinterface are defined to be numpy arrays for speed up of load/save; check your interfaces! GetSurfaceTriangles still returns list of lists

    • date resolved: 2024-10-19 18:48, date raised: 2024-10-19

  • 1.9.20 EXTENSION GetSystemState (#1629)

    • description: extend behavior for returning a dictionary with all data incl. accelerations and possibly alg. accelerations for generalized-alpha solver; check also option to link coords, as in issue 1504

    • notes: added mbs.systemData.GetSystemStateDict(…) with option to return a reference (link) to system vectors, which do not require copying and allow modifications directly

    • date resolved: 2024-10-19 18:45, date raised: 2023-06-23

  • 1.9.19 EXTENSION NORMAL Reference/link (#1504)

    • description: extend mbs and systemData functions for reference, e.g., GetODE2Coordinates; use different function with “Link” extension, e.g., GetODE2CoordinatesLink

    • notes: added systemData function GetSystemStateDict which allows to obtain writeable references

    • date resolved: 2024-10-19 01:28, date raised: 2023-04-08

  • 1.9.18 BUG FEM LoadFromFile (#1901)

    • description: does not work correctly for forceVersion>0.

    • date resolved: 2024-10-18 14:58, date raised: 2024-10-18

  • 1.9.17 TESTING MainSystem UserFunctions (#1900)

    • description: Add TestModel for all kinds of PreStep, PostStep, reNewtonResidual, etc. functions

    • date resolved: 2024-10-17 23:09, date raised: 2024-10-16

  • 1.9.16 EXTENSION SystemJacobianUserFunction (#1899)

    • description: add a MainSystem user function with SetSystemJacobianUserFunction(…) which adds terms to the system jacobian; this is valuable as it may modify only few terms and add appropriate (experimental) terms in extension with the PreNewtonResidualUserFunction which otherwise would lead to bad convergence if important couplings are not added; as mentioned in the description, the solver’s user functions are more general and should be also considered

    • date resolved: 2024-10-17 23:09, date raised: 2024-10-16

  • 1.9.15 EXTENSION preNewtonResidualUserFunction (#1882)

    • description: add user function called in every iteration of Newton solver in static or implicit dynamic computations

    • notes: function SetPreNewtonResidualUserFunction added to MainSystem, see description at MainSystem

    • date resolved: 2024-10-16 23:27, date raised: 2024-10-10

  • 1.9.14 EXTENSION GeneralContact jacobian (#838)

    • description: add jacobian and PostNewton for cable-sphere (circle) contact

    • notes: already done earlier for ANCF beam elements

    • date resolved: 2024-10-16 16:52, date raised: 2021-12-19

  • 1.9.13 BUG keyPressUserFunction (#1893)

    • description: not working any more!

    • notes: works, but needs to activate window.ignoreKeys in order to call user function

    • date resolved: 2024-10-15 23:21, date raised: 2024-10-15

  • 1.9.12 EXAMPLE Symbolic (#1717)

    • description: add examples to testsuite; modify existing examples

    • notes: exu.symbolic used in 5 tests and examples

    • date resolved: 2024-10-15 23:08, date raised: 2023-12-08

  • 1.9.11 EXAMPLE Mainsystem extensions (#1718)

    • description: modify some examples for .Create…(…) functions

    • notes: new functions usually only using CreateGenericJoint, CreateRevoluteJoint, etc.; still keeping old workflows with markers for LLM trainings

    • date resolved: 2024-10-15 23:06, date raised: 2023-12-08

  • 1.9.10 CHANGE Mainsystem extensions (#1721)

    • description: in extension to issue 1718, change all AddRigidBody(…) functions to CreateRigidBody functionality

    • date resolved: 2024-10-15 23:05, date raised: 2023-12-08

  • 1.9.9 TESTING pickleCopyMBS (#1885)

    • description: add TestModel for copying and pickling (load/save) of MainSystem mbs

    • date resolved: 2024-10-13 22:52, date raised: 2024-10-11

  • 1.9.8 EXTENSION load/save mbs (#1891)

    • description: improve functionalities to load and save mbs, using GetDictionary / SetDictionary; see example pickleCopyMbs.py using pickle and HDF5 files

    • date resolved: 2024-10-13 19:16, date raised: 2024-10-13

  • 1.9.7 EXTENSION LoadSaveHDF5 (#1890)

    • description: enable option to load/save Python user functions

    • date resolved: 2024-10-11 22:49, date raised: 2024-10-11

  • 1.9.6 TESTING NGsolve CMS test (#1886)

    • description: add test model for whole CMS functionality but loading from stored data; test all 3 new file formats for storing FEM data

    • date resolved: 2024-10-11 09:00, date raised: 2024-10-11

  • 1.9.5 EXTENSION HDF5 (#1887)

    • description: add functions to advancedUtilities to load/save hierarchical dictionary data

    • date resolved: 2024-10-11 01:00, date raised: 2024-10-11

  • 1.9.4 EXTENSION FEMinterface (#1884)

    • description: extend LoadFromFile and SaveToFile for HDF5 and PKL (pickle) file formats

    • date resolved: 2024-10-11 01:00, date raised: 2024-10-11

  • 1.9.3 CHANGE RigidBodySpringDamper (#1883)

    • description: C++: change computation of outputvariables such that springForceTorqueUserFunction is not called for computation of displacement, rotation, etc., but only for forces and torques

    • date resolved: 2024-10-11 00:03, date raised: 2024-10-11

  • 1.9.2 CHECK Loads visualization (#1881)

    • description: consider an option to show time-dependent loads, in particular in case of symbolic user functions

    • notes: added flag visualizationSettings.loads.drawWithUserFunction and test model loadUserFunctionTest.py

    • date resolved: 2024-10-10 10:48, date raised: 2024-10-09

  • 1.9.1 EXTENSION Symbolic (#1723)

    • description: SymbolicRealVector: add EvaluateItem(i) in operators wherever possible to efficiently evaluate single components instead of all vector components

    • date resolved: 2024-10-09 22:23, date raised: 2023-12-09

  • 1.9.0 FIX MatrixContainer (#1880)

    • description: when initialized with lists of lists, it prints the lists

    • date resolved: 2024-10-09 11:06, date raised: 2024-10-09

Version 1.8

  • 1.8.81 EXTENSION MatrixContainer (#1879)

    • description: add feature to directly initialize with scipy sparse csr matrix; add new function Initialize to initialize MatrixContainer, and AddSparseMatrix for adding sparse matrices with factor

    • date resolved: 2024-10-09 09:39, date raised: 2024-10-09

  • 1.8.80 CHANGE robotics.mobile (#1878)

    • description: correct camelcase writing of mobileRobot2MBS to MobileRobot2MBS, getWheelVelocities to GetWheelVelocities, and getCartesianVelocities to GetCartesianVelocities; adjust examples

    • date resolved: 2024-10-09 08:04, date raised: 2024-10-09

  • 1.8.79 CHANGE AddRigidBody (#1844)

    • description: add warning to this and related functions for deprecation

    • date resolved: 2024-10-09 07:40, date raised: 2024-05-28

  • 1.8.78 FIX MarkerSuperElementRigidBody (#1455)

    • description: fix derivative of exponential map for velocity level

    • notes: already resolved earlier

    • date resolved: 2024-10-09 07:37, date raised: 2023-03-05

  • 1.8.77 FIX NORMAL MacOS multithreading (#1341)

    • description: resolve compilation problems with NGsolve taskmanager on Apple MacOS

    • notes: already resolved earlier

    • date resolved: 2024-10-09 07:36, date raised: 2022-12-26

  • 1.8.76 EXTENSION controller (#496)

    • description: add possibility to differentiate loads w.r.t. sensor?/object/node (use additional sensor numbers which provide dependencies); add optional dependence on sensors; integrateors using ODE1 or discrete implementation

    • notes: already resolved in version 1.6.84; available via systemData.AddODE2LoadDependencies

    • date resolved: 2024-10-09 07:33, date raised: 2020-12-09

  • 1.8.75 CHANGE Create functions (#1877)

    • description: CreateDistanceConstraint, CreateSpringDamper and similar create functions have bodyList instead of bodyNumbers, which is used for joints; use bodyNumbers and allow bodyList as deprecated option

    • notes: kept compatibility with existing bodyList args, but will be removed in future versions

    • date resolved: 2024-10-08 23:04, date raised: 2024-10-08

  • 1.8.74 EXTENSION CSR functionality in FEM (#1862)

    • description: change internal CSR format to scipy CSR format; add simple check for Scipy to be installed at start of FEM, set scipyInstalled=True, use CheckSciPyInstalled() function for unified errors

    • date resolved: 2024-10-08 17:29, date raised: 2024-10-02

  • 1.8.73 CHECK FEMinterface (#1870)

    • description: check all occurances of GetStiffnessMatrix and GetMassMatrix for sparse mode now using scipy sparse matrix

    • notes: Make sure that using FEMinterface fem, fem.GetMassMatrix of fem.GetStiffnessMatrix now returns a SciPy sparse matrix, which can be converted into the previous form by using ScipySparseCSRtoCSR(fem.GetMassMatrix())

    • date resolved: 2024-10-08 17:28, date raised: 2024-10-07

  • 1.8.72 CHANGE FEMinterface (#1876)

    • description: SaveToFile: used wrong default fileVersion=13, which should have been fileVersion=1; as we now shift to fileVersion=2, old files may be loaded with forceVersion=1

    • date resolved: 2024-10-08 17:26, date raised: 2024-10-08

  • 1.8.71 FIX MatrixContainer (#1871)

    • description: fix compilation issues with pybind11 and scipy coo matrix

    • date resolved: 2024-10-08 17:26, date raised: 2024-10-07

  • 1.8.70 CHANGE FEMinterface (#1875)

    • description: the mass and stiffness matrices in FEMinterface are either None or given in SciPy-sparse csr format; this gives also a a new load/save fileVersion of FEMinterface

    • date resolved: 2024-10-08 13:09, date raised: 2024-10-08

  • 1.8.69 CHANGE FEMinterface (#1874)

    • description: SaveToFile: add version 2 which also pickles mass and stiffnessMatrix

    • date resolved: 2024-10-08 11:11, date raised: 2024-10-08

  • 1.8.68 CHANGE FEM module (#1873)

    • description: replace print(…) with exu.Print(…) commands to better control output flow

    • date resolved: 2024-10-08 10:33, date raised: 2024-10-08

  • 1.8.67 EXTENSION MatrixContainer (#1872)

    • description: SetWithSparseMatrixCSR: mark as deprecated; instead add new function SetWithSparseMatrix with additional arg factor (default=1) to multply matrix values with factor before adding

    • date resolved: 2024-10-07 18:34, date raised: 2024-10-07

  • 1.8.66 CHANGE FEMinterface (#1869)

    • description: change default values of massMatrix and stiffnessMatrix to None instead of np.zeros((0,0))

    • date resolved: 2024-10-07 01:54, date raised: 2024-10-07

  • 1.8.65 EXTENSION MatrixContainer (#1865)

    • description: add functionality to add Scipy csr matrix AddSparseMatrix(…, factor=1) with factor

    • date resolved: 2024-10-07 01:35, date raised: 2024-10-02

  • 1.8.64 EXTENSION explicit solvers velocity verlet (#840)

    • description: add velocity verlet integration scheme in particular for particle and contact simulation

    • notes: added, but not yet tested for Lie group case!

    • date resolved: 2024-10-07 00:37, date raised: 2021-12-19

  • 1.8.63 CHANGE SetWithSparseMatrixCSR (#1868)

    • description: change default behavior to useDenseMatrix=False, using sparse mode by default

    • date resolved: 2024-10-06 22:03, date raised: 2024-10-06

  • 1.8.62 DOCU graphicsDataUtilities (#1867)

    • description: adapt documentation to replace graphicsDataUtilities with graphics

    • date resolved: 2024-10-06 17:24, date raised: 2024-10-06

  • 1.8.61 FIX DOCU GraphicsData: Line (#1866)

    • description: Mistake in Line example; add hint to use graphics.Lines function

    • date resolved: 2024-10-06 17:06, date raised: 2024-10-06

  • 1.8.60 DOCU figure (#1854)

    • description: replace figure theoryRotationsTaitBryanAngles, which has been accidentially copied

    • date resolved: 2024-10-06 16:51, date raised: 2024-06-05

  • 1.8.59 BUG ComputeODE2Eigenvalues (#1860)

    • description: in case of computeComplexEigenvalues=True, the option convert2Frequencies=True computes wrong frequencies; this combination thus will be deactivated, as it makes little sense anyhow

    • date resolved: 2024-09-19 16:15, date raised: 2024-09-19

  • 1.8.58 FIX Frames (#1859)

    • description: frame numbers not shown (e.g. for nodes)

    • notes: fixed together with issue 1858

    • date resolved: 2024-08-07 17:26, date raised: 2024-08-07

  • 1.8.57 FIX KinematicTree (#1858)

    • description: frame numbers not shown

    • notes: changing default showFramesNumbers=False

    • date resolved: 2024-08-07 17:26, date raised: 2024-08-07

  • 1.8.56 BUG KinematicTree (#1857)

    • description: COM not correctly drawn (drawn at joint location)

    • date resolved: 2024-08-07 17:05, date raised: 2024-08-07

  • 1.8.55 FIX FromSTLfile (#1856)

    • description: function does not work for A or p being different from []

    • date resolved: 2024-07-03 11:33, date raised: 2024-07-03

  • 1.8.54 DOCU tutorial (#1849)

    • description: add FFRFreducedOrder with NGsolve tutorial

    • date resolved: 2024-06-23 16:59, date raised: 2024-06-02

  • 1.8.53 CHANGE lie group integrator (#1855)

    • description: add improved lie group integrator for generalized alpha, not using the simplified update and thus having higher accuracy

    • date resolved: 2024-06-15 13:42, date raised: 2024-06-15

  • 1.8.52 DOCU tutorials (#1852)

    • description: adapt tutorials to new exudyn.graphics structure

    • date resolved: 2024-06-04 21:48, date raised: 2024-06-04

  • 1.8.51 DOCU exudyn.graphics (#1853)

    • description: add documentation in python utilities for these functions

    • date resolved: 2024-06-04 21:06, date raised: 2024-06-04

  • 1.8.50 CHANGE artificialIntelligence (#1851)

    • description: adapt examples to new stable-baselines version

    • notes: tested with stable-baselines3 V1.7.0 and V2.3.2

    • date resolved: 2024-06-04 17:24, date raised: 2024-06-04

  • 1.8.49 CHANGE resolved by: P. Manzl artificialIntelligence (#1850)

    • description: adapt to stable-baselines3 2.3; add old mode with gym and new mode with gymnasium

    • notes: kept old mode available if gym is installed with stable-baselines without gymnasium

    • date resolved: 2024-06-04 14:59, date raised: 2024-06-04

  • 1.8.48 EXTENSION add NGsolve test (#406)

    • description: with FEMinterface, only for Python37 version

    • notes: outdated and removed (see new issue 1849)

    • date resolved: 2024-06-02 13:30, date raised: 2020-05-22

  • 1.8.47 EXTENSION GeneralContact jacobian (#837)

    • description: add jacobian and PostNewton for Triangle-Sphere contact

    • date resolved: 2024-06-02 10:58, date raised: 2021-12-19

  • 1.8.46 FIX GeneralContact (#1847)

    • description: change several for-break commands to continue to improve contact behavior

    • date resolved: 2024-06-01 20:13, date raised: 2024-06-01

  • 1.8.45 DOCU NORMAL tutorial videos (#1475)

    • description: add new tutorial, replace old ones

    • notes: already completed on Feb 15 2024

    • date resolved: 2024-05-20 19:13, date raised: 2023-03-27

  • 1.8.44 FIX HIGH tutorial videos (#1474)

    • description: fix gettings started video

    • notes: already completed on Feb 15 2024

    • date resolved: 2024-05-20 19:13, date raised: 2023-03-27

  • 1.8.43 EXTENSION add FurtherExampels folder for further examples, especially useful for training of LLMs (#1842)

    • description: EXTENSION

    • date resolved: 2024-05-20 19:08, date raised: 2024-05-17

  • 1.8.42 DOCU simulationSettings (#1843)

    • description: correct path of simulationSettings.staticSolverSettings to simulationSettings.staticSolver in RTD description

    • date resolved: 2024-05-17 18:36, date raised: 2024-05-17

  • 1.8.41 FIX AddODE2LoadDependencies (#1841)

    • description: description is wrong

    • date resolved: 2024-05-17 18:29, date raised: 2024-05-17

  • 1.8.40 FIX std::isalpha (#1840)

    • description: remove std::isalpha and std::isalnum, as it does not compile on certain older compilers

    • date resolved: 2024-05-13 17:08, date raised: 2024-05-13

  • 1.8.39 EXTENSION Examples check (#1838)

    • description: add test to check whether examples basically run; use timeout and special setting to turn off all key-press waiting; exclude large examples

    • date resolved: 2024-05-12 10:19, date raised: 2024-05-11

  • 1.8.38 BUG ALEANCFCable2D (#1839)

    • description: raises error ‘ANCFCable2d:ComputeAxialStrain_t not implemented’ if ForceLocal is evaluated

    • notes: results have to be verified

    • date resolved: 2024-05-11 19:18, date raised: 2024-05-11

  • 1.8.37 EXTENSION ALEANCFCable2D (#1187)

    • description: add missing terms related to damping terms coupled with delta qALE

    • notes: already implemented and checked with paper up to come

    • date resolved: 2024-05-11 19:00, date raised: 2022-07-06

  • 1.8.36 FIX exudyn.graphics (#1692)

    • description: change GraphicsData functions in examples to exudyn.graphics

    • notes: CHECK your files, if there are any issues due to this change; in general, the previous functionality should be maintained

    • date resolved: 2024-05-11 01:18, date raised: 2023-11-19

  • 1.8.35 CHANGE GraphicsDataCube (#1825)

    • description: rename to GraphicsDataBrick… functions; use assignment to keep previous functionality

    • notes: not changed, but introduced exudyn.graphics submodule for graphics functions. OrthoCube now available as exudyn.graphics.Brick

    • date resolved: 2024-05-11 01:16, date raised: 2024-04-25

  • 1.8.34 EXTENSION exudyn.graphics (#1691)

    • description: map graphicsDataUtilities functions to exudyn.graphics for better readability

    • notes: NOTE that previous GraphicsData functions still work; however, it may be necessary to import exudyn.utilities if you imported exudyn.graphicsDataUtilities directly; examples and test models are adjusted to new functions; it is recommended that users switch to new exudyn.graphics functionality!

    • date resolved: 2024-05-10 19:45, date raised: 2023-11-19

  • 1.8.33 CHECK graphics (#1837)

    • description: test graphics submodule for future replacement of graphicsDataUtilities

    • date resolved: 2024-05-10 10:09, date raised: 2024-05-10

  • 1.8.32 DOCU theory docu (#1832)

    • description: add description of computation of stresses for FFRFreducedOrder

    • date resolved: 2024-05-09 17:12, date raised: 2024-05-03

  • 1.8.31 EXTENSION ComputeLinearizedSystem (#1836)

    • description: output constraint and nullspace matrices for constrained systems

    • date resolved: 2024-05-05 16:18, date raised: 2024-05-05

  • 1.8.30 EXTENSION ComputeLinearizedSystem (#1835)

    • description: add option to compute linearized system of constrained system

    • date resolved: 2024-05-05 16:18, date raised: 2024-05-05

  • 1.8.29 CHANGE ComputeLinearizedSystem (#1834)

    • description: remove sparse solver option useSparseSolver, as it is not implemented

    • date resolved: 2024-05-05 16:17, date raised: 2024-05-05

  • 1.8.28 EXTENSION ComputeODE2EigenValues (#1833)

    • description: extend to complex eigenvalues

    • notes: added TestModel complexEigenvaluesTest.py

    • date resolved: 2024-05-04 18:12, date raised: 2024-05-03

  • 1.8.27 CHANGE ObjectJointRollingDisc (#1831)

    • description: change computation of constraints into local joint frame, enabling lateral and forward constraint independently; see old comment on constrainedAxes

    • date resolved: 2024-04-29 08:03, date raised: 2024-04-29

  • 1.8.26 FIX AddLidar (#1830)

    • description: angles of sensors should be equally arranged between angleStart and angleEnd using numberOfSensors and having a sensor both at start and end angle

    • date resolved: 2024-04-27 17:06, date raised: 2024-04-27

  • 1.8.25 FIX AddLidar (#1829)

    • description: several arguments are not passed to CreateDistanceSensor; add all arguments to interface, which may cause some change in behavior!

    • date resolved: 2024-04-27 16:48, date raised: 2024-04-27

  • 1.8.24 EXAMPLE resolved by: P. Manzl Examples (#1828)

    • description: add example mobileMecanumWheelRobotWithLidar.py for a mecanum wheeled robot with lidar and mapping

    • date resolved: 2024-04-27 11:11, date raised: 2024-04-27

  • 1.8.23 FIX AddLidar (#1827)

    • description: argument rotation is not used

    • date resolved: 2024-04-27 11:08, date raised: 2024-04-27

  • 1.8.22 CHANGE AddLidar (#1826)

    • description: angles of sensor directions are not defined and erronously with respect to Y-axis; angleStart and angleEnde shall be measured w.r.t. the X-axis (angle=0) and in positive rotation sense about local Z-axis

    • date resolved: 2024-04-27 11:08, date raised: 2024-04-27

  • 1.8.21 DOCU ObjectConnectorCoordinateVector (#1824)

    • description: fix docu and remove inexisting parameters

    • date resolved: 2024-04-21 19:34, date raised: 2024-04-21

  • 1.8.20 CHANGE item type info (#1820)

    • description: change py::dict to py:object in functions such as AddMarker according to github issue #64, otherwise giving typing errors in PyLance and similar

    • date resolved: 2024-04-21 19:17, date raised: 2024-04-19

  • 1.8.19 CHANGE stub files (.pyi) (#1823)

    • description: change type in AddObject, AddMarker, AddSensor, AddLoad, AddNode from pyObject: dict to pyObject: Any in order to resolve typing errors

    • date resolved: 2024-04-21 19:16, date raised: 2024-04-19

  • 1.8.18 EXAMPLE resolved by: P. Manzl KinematicTreePendulum.py (#1819)

    • description: Version 1.7.71 broke example kinematicTreePendulum with transition from SensorObject to SensorBody

    • notes: changed SensorObject(objectNumber=oKT into SensorBody(bodyNumber=oKT

    • date resolved: 2024-04-17 16:13, date raised: 2024-04-17

  • 1.8.17 FIX stub files (.pyi) (#1818)

    • description: add types for mainsystem extensions (e.g. SolutionViewer)

    • notes: not resolved, because mainSystemExtension functions do not contain argument types

    • date resolved: 2024-04-14 17:54, date raised: 2024-04-14

  • 1.8.16 FIX stub files (.pyi) (#1817)

    • description: add types for system structures (mainly solver functions)

    • notes: not resolved, because this information is not available in the structures for solver methods

    • date resolved: 2024-04-14 17:53, date raised: 2024-04-14

  • 1.8.15 FIX stub files (.pyi) (#1816)

    • description: fix a couple of wrong return types and similar wrong typings (in particular return types in SetODE2Coordinates, etc.

    • date resolved: 2024-04-14 16:15, date raised: 2024-04-14

  • 1.8.14 FIX stub files (.pyi) (#1814)

    • description: .pyi files do not contain correct default args for C++ interfaces

    • date resolved: 2024-04-14 16:15, date raised: 2024-04-14

  • 1.8.13 FIX stub files (.pyi) (#1815)

    • description: .pyi are missing backslash before underscore (for latex) documentation

    • date resolved: 2024-04-14 15:15, date raised: 2024-04-14

  • 1.8.12 FIX GetMarkerOutput (#1812)

    • description: not working for MarkerKinematicTreeRigid in case of Reference configuration; adjustments done in CObjectKinematicTree::ComputeTreeTransformations to avoid the need for velocities in the retrieval of positions

    • date resolved: 2024-04-03 19:38, date raised: 2024-04-03

  • 1.8.11 FIX raised by: PM resolved by: P. Manzl Sensitivity Analysis for functions with single outputs (#1811)

    • description: ComputeSensitivities and PlotSensitivityResults does not work for functions with a single output

    • date resolved: 2024-03-26 19:24, date raised: 2024-03-26

  • 1.8.10 CHANGE GeneralContact (#1810)

    • description: unify computation of contact forces and jacobians for sphere-sphere and trig-sphere contact

    • date resolved: 2024-03-25 08:21, date raised: 2024-03-25

  • 1.8.9 FIX GeneralContact (#1809)

    • description: apply changes in sphere-sphere contact to Jacobian and to docu

    • date resolved: 2024-03-17 19:05, date raised: 2024-03-17

  • 1.8.8 BUG GeneralContact (#1807)

    • description: sphere-shpere contact causes spurious internal torque

    • notes: fixed by adding 0.5*penetration in lever arm; adjusted also documentation; gives new test suite results

    • date resolved: 2024-03-17 10:56, date raised: 2024-03-17

  • 1.8.7 BUG CreateRigidBody (#1805)

    • description: raises exception in case that initialRotationMatrix is not None; SOLUTION: replace == None for ALL cases (check other functions) with is None or is not Note!

    • notes: fixed with 1808

    • date resolved: 2024-03-17 10:55, date raised: 2024-03-16

  • 1.8.6 BUG CreateRigidBody (#1806)

    • description: initialRotationMatrix has no effect at least in explicit integration

    • notes: wrong operator* used for multiplication of reference rotation matrix and initial rotation matrix; FIXED

    • date resolved: 2024-03-17 10:54, date raised: 2024-03-16

  • 1.8.5 EXTENSION advanced utilities (#1808)

    • description: added function to check for None and not None: IsNone(x), IsNotNone(x)

    • date resolved: 2024-03-17 10:29, date raised: 2024-03-17

  • 1.8.4 CHECK GeneralContact (#1804)

    • description: check triangle-sphere contact: torque for triangle computed with “((-sphereI.radius)*deltaP0).CrossProduct(fVec)” lever arm should be -(trigPP - rigid.position) ?

    • notes: changed term for torque on rigid body according to added documentation in theory section

    • date resolved: 2024-03-17 10:15, date raised: 2024-03-16

  • 1.8.3 CHECK RigidBodySpringDamper (#1802)

    • description: check intrinsic joint formulation

    • notes: no inconsistencies found or detected in examples

    • date resolved: 2024-03-13 13:10, date raised: 2024-03-07

  • 1.8.2 EXTENSION MarkerSuperElementRigid (#1803)

    • description: add option for tangent operator in alternativeFormulation

    • date resolved: 2024-03-13 13:09, date raised: 2024-03-13

  • 1.8.1 TESTING continuous integration (#734)

    • description: test CI capabilities with GitHub and MacOS compilation

    • notes: resolved with issue 1792

    • date resolved: 2024-03-09 16:04, date raised: 2021-08-12

  • 1.8.0 EXTENSION AvailableItems (#1789)

    • description: add exudyn.special function to retrieve available items as dictionary with lists

    • date resolved: 2024-03-06 09:02, date raised: 2024-02-21

Version 1.7

  • 1.7.123 DOCU joint constraints (#1795)

    • description: theory: add description for formulation of joint constraints

    • notes: added equations to position markers and JointSpherical

    • date resolved: 2024-03-03 22:04, date raised: 2024-02-25

  • 1.7.122 EXTENSION GeneralContact (#1800)

    • description: add option for GetActiveContacts to return number of contacts per contact type in case that itemIndex=-1

    • date resolved: 2024-02-29 15:50, date raised: 2024-02-29

  • 1.7.121 CHANGE exudyn __init__.py (#1799)

    • description: remove NoAVX option for linux, as linux does not (yet) have a AVX2 option; crashed on linux arm/aarch architecture

    • date resolved: 2024-02-29 14:34, date raised: 2024-02-29

  • 1.7.120 EXTENSION Github actions (#1797)

    • description: create single line output for testsuite with specific mode; add test suite for github actions and merge outputs into single file

    • notes: put information into filename of text tilde with output of testsuite

    • date resolved: 2024-02-29 14:32, date raised: 2024-02-27

  • 1.7.119 EXTENSION linux arm (#1798)

    • description: add multilinux aarch64 wheels to GH build actions

    • date resolved: 2024-02-29 14:31, date raised: 2024-02-29

  • 1.7.118 EXTENSION MacOSX universal2 (#1796)

    • description: add build option for macos universal files on GH actions to have both arm and x86 on board

    • notes: NOTE that pip 20.3 is required to install these wheels!

    • date resolved: 2024-02-27 15:06, date raised: 2024-02-27

  • 1.7.117 DOCU fix curly brackets (#1794)

    • description: fix curly brackets {} in RST files

    • date resolved: 2024-02-25 20:43, date raised: 2024-02-25

  • 1.7.116 EXTENSION manylinux2014 (#1793)

    • description: build highly compatible manylinux2014 and manylinux2_17 wheels with github actions docker, to run on CentOS and Rocky Linux as well as ubuntu

    • date resolved: 2024-02-24 23:28, date raised: 2024-02-24

  • 1.7.115 EXTENSION Github actions CI (#1792)

    • description: add github actions to create automatically Windows, Ubunut and MacOS wheels

    • date resolved: 2024-02-24 23:28, date raised: 2024-02-24

  • 1.7.114 EXTENSION Python 3.12 (#1787)

    • description: include Python 3.12 wheels into build process

    • date resolved: 2024-02-24 23:25, date raised: 2024-02-21

  • 1.7.113 BUG Autoregistration items (#1791)

    • description: node does not initialize CData

    • date resolved: 2024-02-24 17:45, date raised: 2024-02-24

  • 1.7.112 CHANGE items auto-registration (#1788)

    • description: add a simple way to automatically register items; use C++ map to create item in object-factory

    • date resolved: 2024-02-21 19:17, date raised: 2024-02-21

  • 1.7.111 EXTENSION exudyn minimal (#1790)

    • description: add flag EXUDYN_MINIMAL_ITEMS to achieve fast compilation for testing

    • date resolved: 2024-02-21 18:53, date raised: 2024-02-21

  • 1.7.110 BUG ComputeODE2singleLoad (#1786)

    • description: raises error in static computation “inconsistent jacobian”; workaround settings computeLoadsJacobian=False or using sparse solver

    • notes: exception due to inconsistent computation of mass proportional load jacobian with rigid body

    • date resolved: 2024-02-16 11:42, date raised: 2024-02-16

  • 1.7.109 DOCU beam tutorial (#1785)

    • description: add beam tutorial example and tutorial in theDoc

    • date resolved: 2024-02-13 22:08, date raised: 2024-02-13

  • 1.7.108 DOCU theory theDoc (#1784)

    • description: add introduction to multibody dynamics, kinematics, dynamics, rotations

    • date resolved: 2024-02-13 16:10, date raised: 2024-02-13

  • 1.7.107 DOCU RST graphics (#1783)

    • description: add graphics for readthedocs representation, in solvers; fix references

    • date resolved: 2024-02-13 16:10, date raised: 2024-02-13

  • 1.7.106 EXTENSION GeneralContact (#1782)

    • description: add flag computeContactForces to settings, which computes contribution of contact forces to system vector (may slow down computations!); similar to issue 936

    • date resolved: 2024-02-12 09:07, date raised: 2024-02-12

  • 1.7.105 EXTENSION GeneralContact (#936)

    • description: add interface function to get contact forces

    • date resolved: 2024-02-12 09:07, date raised: 2022-02-10

  • 1.7.104 EXTENSION GeneralContact (#1781)

    • description: add function Get/SetTriangleRigidBodyBased, to get data or modify data of current contact triangle

    • date resolved: 2024-02-08 20:38, date raised: 2024-02-08

  • 1.7.103 EXTENSION GeneralContact (#1780)

    • description: add function SetSphereMarkerBased to set data for spheres during simulation

    • date resolved: 2024-02-08 20:38, date raised: 2024-02-08

  • 1.7.102 CHANGE GeneralContact (#1779)

    • description: GetMarkerBasedSphere: change to GetSphereMarkerBased; add flag to decide whether to add basic data or not

    • date resolved: 2024-02-08 19:08, date raised: 2024-02-08

  • 1.7.101 CHANGE cRGB settings (#1778)

    • description: change cRGB consistently to RGBA in visualization settings

    • date resolved: 2024-02-08 18:57, date raised: 2024-02-08

  • 1.7.100 FIX BodyGraphicsData (#1775)

    • description: access with Get/SetObjectParameter is missing for graphicsData

    • date resolved: 2024-02-04 22:01, date raised: 2024-02-04

  • 1.7.99 CHANGE CreateSymbolicUserFunction (#1774)

    • description: change order of args userFunctionName, itemIndex, and verbose; add additional itemTypeName

    • date resolved: 2024-02-04 00:36, date raised: 2024-02-04

  • 1.7.98 EXTENSION CreateSymbolicUserFunction (#1773)

    • description: add option to directly pass itemTypeName instead of itemIndex in order to pre-compute user function

    • date resolved: 2024-02-04 00:36, date raised: 2024-02-04

  • 1.7.97 CHANGE TransferUserFunction2Item (#1771)

    • description: add functionality to allow direct assignment of symbolic user functions to userFunction parameters in objects, loads, etc.; remove TransferUserFunction2Item as this function is then no longer needed

    • date resolved: 2024-02-03 23:55, date raised: 2024-02-03

  • 1.7.96 EXTENSION Python user functions (#1766)

    • description: use PythonUserFunctionBase class for all Item user functions; add consistent Get/Set function for item access; should then automatically work with pickle

    • date resolved: 2024-02-03 23:54, date raised: 2024-02-02

  • 1.7.95 EXTENSION python user functions (#1750)

    • description: add additional py::function to user functions in order to store original python function for pickling

    • date resolved: 2024-02-03 23:54, date raised: 2024-01-29

  • 1.7.94 FIX Renderer (#1759)

    • description: there is an issue when restarting the renderer, which displays previous (old) data; requires to add some function which erases stored graphics data on call of StartRenderer()

    • date resolved: 2024-02-03 23:53, date raised: 2024-01-31

  • 1.7.93 EXTENSION mainsystem extensions (#1770)

    • description: add user function to mbs.Create…() functions

    • date resolved: 2024-02-03 22:50, date raised: 2024-02-03

  • 1.7.92 EXTENSION Python user functions (#1763)

    • description: add pickle functionality (requires issue 1752)

    • date resolved: 2024-02-02 10:36, date raised: 2024-01-31

  • 1.7.91 EXTENSION user functions types (#1752)

    • description: create UserFunctionBase class and derived classes, containing std::function, and a py::object with metadata (Python function, Symbolic function, etc.); When settings user functions, they can be either initialized with 0 / Python function or with a UserFunction dict, which contains additional decorators; In particular, user functions will be rebuilt as symbolic; return values of user functions are then dictionaries

    • date resolved: 2024-02-02 10:36, date raised: 2024-01-29

  • 1.7.90 EXTENSION MainSystem user functions (#1765)

    • description: test special class for MainSystem user functions such as preStepUserFunction; if requeste, convert to Dict, in particular for symbolic or other special user functions

    • date resolved: 2024-02-02 10:33, date raised: 2024-02-02

  • 1.7.89 EXTENSION SystemContainer (#1762)

    • description: add pickle functionality

    • date resolved: 2024-01-31 20:22, date raised: 2024-01-31

  • 1.7.88 EXTENSION pickle MainSystem (#1628)

    • description: consider a pickle method for certain objects; add consistent info in description; MainSystem, SimulationSettings, VisualizationSettings

    • notes: consider with care, as not all things are copied (user functions, contact, …)

    • date resolved: 2024-01-31 20:22, date raised: 2023-06-23

  • 1.7.87 EXTENSION pickle (#1761)

    • description: add pickle to settings and structures

    • date resolved: 2024-01-31 20:21, date raised: 2024-01-31

  • 1.7.86 EXTENSION pickle (#1760)

    • description: add pickle to ItemIndices

    • date resolved: 2024-01-31 20:21, date raised: 2024-01-31

  • 1.7.85 EXTENSION DictionariesGetSet (#1757)

    • description: add C++ GetDictionary(…) function for read/write of system structures; add Get/SetDictionary to pybind interface

    • date resolved: 2024-01-31 17:27, date raised: 2024-01-30

  • 1.7.84 FIX StartRenderer (#1758)

    • description: add UpdateGraphicsDataNow() after start of renderer in order to avoid showing stored data for second run or renderer

    • date resolved: 2024-01-31 12:52, date raised: 2024-01-31

  • 1.7.83 CHANGE CSystem in MainSystem (#1755)

    • description: change CSystem* to CSystem in MainSystem, to make copying easier

    • date resolved: 2024-01-30 16:43, date raised: 2024-01-30

  • 1.7.82 CHANGE SystemContainer (#1756)

    • description: remove SystemContainer and just keep MainSystemContainer, as it is not needed; simplifies copying

    • date resolved: 2024-01-30 16:42, date raised: 2024-01-30

  • 1.7.81 EXTENSION MainSystem (#1754)

    • description: change creation of MainSystem; allow construction like exudyn.MainSystem(), add new function Append(MainSystem) to MainSystemContainer; this will allow pickling both of MainSystem and MainSystemContainer

    • date resolved: 2024-01-30 14:34, date raised: 2024-01-30

  • 1.7.80 EXTENSION postStepUserFunction (#1753)

    • description: add user function to be called at end of time step, just before storing results to file; this allows to override results, etc.

    • date resolved: 2024-01-30 08:01, date raised: 2024-01-30

  • 1.7.79 FIX user functions (#1748)

    • description: check option to set them to 0; PreStepUserFunction as well as item user functions

    • notes: Note that when reading user functions, mbs.GetObjectParameter(…) also consistently gives now 0 instead of previously None

    • date resolved: 2024-01-29 14:41, date raised: 2024-01-29

  • 1.7.78 EXTENSION User function (#1749)

    • description: allow assignment to 0 for MainSystem user functions; SetPreStepUserFunction and SetPostNewtonUserFunction

    • date resolved: 2024-01-29 14:34, date raised: 2024-01-29

  • 1.7.77 EXTENSION GenerateStraightBeam (#1746)

    • description: build generic function to create beams along straight line; add interface both for ANCF (old GenerateStraightLineANCFCable function) as well as for geometrically exact beam

    • date resolved: 2024-01-28 19:46, date raised: 2024-01-28

  • 1.7.76 EXTENSION GeometricallyExactBeam2D (#1747)

    • description: finish interface for load mass proportional

    • notes: also done for 3D version

    • date resolved: 2024-01-28 18:17, date raised: 2024-01-28

  • 1.7.75 CHANGE geometrically exact beam 2D (#1745)

    • description: adjust implementation of reference strains to allow connection of several beams at one node in case that includeReferenceRotations=0

    • date resolved: 2024-01-27 22:16, date raised: 2024-01-27

  • 1.7.74 DOCU geometrically exact beam 2D (#1744)

    • description: fix inconsistent documentation of reference strains

    • date resolved: 2024-01-27 22:16, date raised: 2024-01-27

  • 1.7.73 FIX CreateRevoluteJoint (#1743)

    • description: Description for local/global axis is wrong; behavior is switched by useGlobalFrame flag

    • date resolved: 2024-01-06 11:20, date raised: 2024-01-06

  • 1.7.72 FIX CreatePrismaticJoint (#1742)

    • description: Description for local/global axis is wrong; behavior is switched by useGlobalFrame flag

    • date resolved: 2024-01-06 11:20, date raised: 2024-01-06

  • 1.7.71 BUG ObjectKinematicTree (#1741)

    • description: SensorObject does not work with OutputVariableType Coordinates; example does not work;

    • notes: Coordinates, Force, etc. now available with GetObjectOutputBody and SensorBody

    • date resolved: 2024-01-06 11:02, date raised: 2024-01-06

  • 1.7.70 FIX symbolic (#1739)

    • description: SetValue should raise exception if called with symbolic expression

    • date resolved: 2023-12-19 08:30, date raised: 2023-12-19

  • 1.7.69 EXTENSION symbolic (#1737)

    • description: add symbolic.pyi stub file for autocompletion of symbolic features

    • date resolved: 2023-12-18 19:48, date raised: 2023-12-18

  • 1.7.68 DOCU symbolic (#1738)

    • description: fix documentation for operators

    • date resolved: 2023-12-18 19:47, date raised: 2023-12-18

  • 1.7.67 DOCU SymbolicRealMatrix (#1727)

    • description: add documentation and example for symbolic matrix for user functions

    • date resolved: 2023-12-18 08:24, date raised: 2023-12-12

  • 1.7.66 BUG symbolic (#1736)

    • description: symbolic user function: crashes when user function object is deleted

    • date resolved: 2023-12-15 18:01, date raised: 2023-12-15

  • 1.7.65 FIX symbolic (#1735)

    • description: check delete counts and reference counts for +=, etc.

    • date resolved: 2023-12-15 18:01, date raised: 2023-12-15

  • 1.7.64 TESTING Symbolic (#1729)

    • description: add vector/matrix tests in comparison with Python numpy and check delete counts

    • date resolved: 2023-12-15 13:52, date raised: 2023-12-12

  • 1.7.63 TESTING Symbolic (#1728)

    • description: add scalar tests in comparison with Python math and check delete counts

    • date resolved: 2023-12-15 13:52, date raised: 2023-12-12

  • 1.7.62 CHECK symbolic (#1733)

    • description: check overloading __len__ operator for vector

    • date resolved: 2023-12-15 13:06, date raised: 2023-12-15

  • 1.7.61 FIX symbolic (#1734)

    • description: write operator[] for Matrix and Vector fails

    • date resolved: 2023-12-15 11:51, date raised: 2023-12-15

  • 1.7.60 BUG symbolic (#1732)

    • description: Vector.SetVector(…), Matrix.SetMatrix(…) not working; fix Pybind interface

    • date resolved: 2023-12-15 11:12, date raised: 2023-12-15

  • 1.7.59 EXAMPLE chatGPTupdate (#1680)

    • description: add simple example for load userFunction

    • date resolved: 2023-12-14 00:01, date raised: 2023-10-29

  • 1.7.58 FIX VObjectGround (#1693)

    • description: remove parameter color, as it is not used (check)

    • date resolved: 2023-12-13 23:40, date raised: 2023-11-19

  • 1.7.57 EXTENSION SymbolicRealMatrix (#1726)

    • description: add symbolic matrix for user functions

    • notes: note: currently implemented less efficient with memory allocations

    • date resolved: 2023-12-13 14:02, date raised: 2023-12-12

  • 1.7.56 EXTENSION ANCFCable2D (#1731)

    • description: add user functions for bending moment and axial force, allowing to implement arbitrary material models

    • date resolved: 2023-12-13 13:47, date raised: 2023-12-13

  • 1.7.55 FIX GenerateStraightLineANCFCable (#1730)

    • description: raises Warning for default values [0,0,0,0,0,0] in 2D case

    • date resolved: 2023-12-13 13:27, date raised: 2023-12-13

  • 1.7.54 EXTENSION Symbolic (#1725)

    • description: add ResizableConstMatrix and create symbolic matrix-vector functions

    • date resolved: 2023-12-12 14:16, date raised: 2023-12-10

  • 1.7.53 DOCU Symbolic (#1716)

    • description: add symbolic user function description to documentation; also mention in performance section

    • date resolved: 2023-12-10 21:57, date raised: 2023-12-08

  • 1.7.52 CHANGE C++ ToString (#1724)

    • description: changing the behavior for standard conversion of double and int values to strings, in particular during errors. Now using the same precision as defined with exudyn.SetOutputPrecision()

    • date resolved: 2023-12-09 19:26, date raised: 2023-12-09

  • 1.7.51 DOCU Symbolic (#1715)

    • description: add symbolic section to documentation

    • date resolved: 2023-12-09 16:29, date raised: 2023-12-08

  • 1.7.50 EXTENSION Symbolic (#1708)

    • description: make symbolic variable space, available globally in exudyn.symbolic as well as in mbs.symbolic; this allows to store/transfer data into user functions without the need for Python; use integer handles which are returned by creation function: a=NamedReal(value, name); handle=AddVariableReal(a)

    • notes: not yet put into mbs and using no integer handles, but std::unordered_map, which has highly efficient hash table included

    • date resolved: 2023-12-09 16:29, date raised: 2023-12-03

  • 1.7.49 DOCU exudyn. … (#1699)

    • description: add undocumented features of exudyn module, such as Demo1(), Demo2(), __version__ or C++

    • date resolved: 2023-12-08 18:41, date raised: 2023-11-22

  • 1.7.48 DOCU experimental, special (#1698)

    • description: add experimental and special features to documentation / pybindings

    • date resolved: 2023-12-08 18:41, date raised: 2023-11-21

  • 1.7.47 EXTENSION Symbolic (#1710)

    • description: add basic (automatic) differentiation feature for expressions: EvaluateDiff()

    • date resolved: 2023-12-08 07:22, date raised: 2023-12-03

  • 1.7.46 EXTENSION ResizableConstSizeVector (#1700)

    • description: consider a Vector with fixed size, which can be extended if necessary - e.g. for local variables in sensors or GetOutputVariable; is efficient for small vectors and still works for larger one

    • date resolved: 2023-12-07 23:03, date raised: 2023-11-22

  • 1.7.45 EXTENSION Symbolic (#1714)

    • description: add vector as symbolic expression, allowing vectors in user functions

    • date resolved: 2023-12-07 19:55, date raised: 2023-12-07

  • 1.7.44 CHANGE user functions (#1713)

    • description: change StdVector to StdVector3D and StdVector6D in relevant cases in order to achieve light-weight interface for symbolic interfaces

    • date resolved: 2023-12-07 19:53, date raised: 2023-12-07

  • 1.7.43 EXTENSION Symbolic (#1712)

    • description: add automatic creation of user functions to AutoGenerateObjects

    • date resolved: 2023-12-05 00:06, date raised: 2023-12-03

  • 1.7.42 EXTENSION Symbolic (#1711)

    • description: put most parts of specific user functioninto base SymbolicFunction; EvaluateUF: use variadic args to generalize

    • date resolved: 2023-12-05 00:06, date raised: 2023-12-03

  • 1.7.41 EXTENSION Symbolic (#1709)

    • description: add most of Pythons math module functions to symbolic functions list

    • date resolved: 2023-12-03 15:01, date raised: 2023-12-03

  • 1.7.40 EXTENSION Symbolic user function (#1705)

    • description: allow parallel computation of non-Python user functions

    • notes: this is enabled by adding user function after Assemble, thus objects are not registered to have Python user functions

    • date resolved: 2023-12-03 14:58, date raised: 2023-11-28

  • 1.7.39 DOCU RigidBodySpringDamper (#1706)

    • description: intrinsicFormulation: add test to test suite and document new functionality

    • date resolved: 2023-11-30 23:56, date raised: 2023-11-30

  • 1.7.38 CHECK RigidBodySpringDamper (#1707)

    • description: intrinsicFormulation: check conserving properties of joint forces for two freely rotating bodies: additional torque of forces may be required in implementation

    • date resolved: 2023-11-30 23:39, date raised: 2023-11-30

  • 1.7.37 EXTENSION RigidBodySpringDamper (#1486)

    • description: extend for Lie group formulation, evaluating connectors at mid-configuration according to Masarati and Morandini

    • date resolved: 2023-11-30 20:51, date raised: 2023-04-01

  • 1.7.36 EXTENSION resolved by: EXTENSION exudyn.symbolic (#1696)

    • description: add experimental expression trees for building symbolic expressions to be used for user functions

    • notes: basic symbolic functionality added; tested with SpringDamper user function, leading to speedup of 10 against regular Python function

    • date resolved: 2023-11-28 09:08, date raised: 2023-11-21

  • 1.7.35 EXTENSION solver timeout (#1704)

    • description: added module-wide flag for timeout: exudyn.special.solver.timeout in order to stop simulations after certain time; use with care

    • date resolved: 2023-11-22 09:43, date raised: 2023-11-22

  • 1.7.34 CHANGE Pybind module (#1703)

    • description: use suggestions of from search: pybind11, how to split my code into multiple modules/files - stackoverflow; should improve compilation time

    • notes: created 2 new pybind module files; no major compilation speedup visible on laptop

    • date resolved: 2023-11-22 08:24, date raised: 2023-11-22

  • 1.7.33 CHECK PyErr_CheckSignals (#1702)

    • description: check if this method available in pybind helps to allow stopping long-lasting computations in exudyn

    • notes: still does not work in Spyder

    • date resolved: 2023-11-22 02:03, date raised: 2023-11-22

  • 1.7.32 CHANGE RunCppUnitTests (#1701)

    • description: move to exudyn.special.RunCppUnitTests

    • date resolved: 2023-11-22 00:29, date raised: 2023-11-22

  • 1.7.31 CHANGE exudyn.experimental (#1697)

    • description: change exudyn.Experimental() into exudyn.experimental structure for clearer view on it; not intended to be used widely

    • notes: see also issue 1613

    • date resolved: 2023-11-21 21:18, date raised: 2023-11-21

  • 1.7.30 CHANGE load user functions (#1694)

    • description: add stl and numpy bindings in order to have Vector3D converted into numpy arrays in loadVectorUserFunction

    • date resolved: 2023-11-19 23:05, date raised: 2023-11-19

  • 1.7.29 EXTENSION mainSystemExtensions (#1690)

    • description: add CreateGround() with referencePosition, referenceRotationMatrix and visualization

    • date resolved: 2023-11-19 23:05, date raised: 2023-11-19

  • 1.7.28 EXTENSION CreateTorque (#1679)

    • description: add create function for nodes and bodies (using node=None, body=None default) to be used either for nodes or bodies; automatically adds markers; bodyFixed=False; add option to add userFunction

    • date resolved: 2023-11-19 22:22, date raised: 2023-10-29

  • 1.7.27 EXTENSION CreateForce (#1678)

    • description: add create function for nodes and bodies (using node=None, body=None default) to be used either for nodes or bodies; automatically adds markers; bodyFixed=False; add option to add userFunction

    • date resolved: 2023-11-19 22:22, date raised: 2023-10-29

  • 1.7.26 EXTENSION mainSystemExtensions (#1689)

    • description: change bodyOrNodeList into bodyList; allow bodyOrNodeList as alternative arg, but avoid using in examples

    • date resolved: 2023-11-19 21:04, date raised: 2023-11-19

  • 1.7.25 EXTENSION mainSystemExtensions (#1688)

    • description: allow special case distance=0 in CreateDistanceConstraint; this will then create a SphericalJoint

    • date resolved: 2023-11-19 21:04, date raised: 2023-11-19

  • 1.7.24 EXTENSION mainSystemExtensions (#1687)

    • description: allow referenceLength=0 in ConnectorSpringDamper

    • date resolved: 2023-11-19 21:04, date raised: 2023-11-19

  • 1.7.23 EXTENSION ANCFCable (#1667)

    • description: add visulization with cylinders

    • date resolved: 2023-11-19 19:39, date raised: 2023-10-16

  • 1.7.22 EXTENSION SpringDamper (#1686)

    • description: allow springLength=0, as it does not cause problems in computations

    • notes: added special behavior for L=0, but velocity not equal 0; may cause convergence issues in particular for static problems; added special behavior for L=0, but velocity not equal 0; may cause convergence issues in particular for static problems; also allow referenceLength=0

    • date resolved: 2023-11-19 19:11, date raised: 2023-11-19

  • 1.7.21 EXAMPLE ANCF cable with rigid marker (#1685)

    • description: add example with ANCFCable2D and rigid body marker, prescribing rotation of one end

    • notes: ANCFrotatingCable2D.py

    • date resolved: 2023-11-07 14:04, date raised: 2023-11-07

  • 1.7.20 FIX ReadTheDocs (#1673)

    • description: add the required .readthedocs.yaml file and move requirements.txt into docs folder, as it is related to sphinx only

    • date resolved: 2023-10-25 09:16, date raised: 2023-10-25

  • 1.7.19 CHANGE LieGroup explicit integration (#1672)

    • description: fixed lieGroupDataNodes; lieGroupDataNodes renamed into lieGroupNodes in explict integration

    • date resolved: 2023-10-16 10:00, date raised: 2023-10-16

  • 1.7.18 CHANGE PlotSensor (#1671)

    • description: use IsListOrArray function to check for non-empty offsets and factors, to comply with numpy arrays

    • date resolved: 2023-10-16 08:32, date raised: 2023-10-16

  • 1.7.17 EXTENSION GenerateStraightLineANCFCable (#1670)

    • description: add GenerateStraightLineANCFCable for 3D cables and adjust 2D version

    • date resolved: 2023-10-16 08:31, date raised: 2023-10-16

  • 1.7.16 FIX NodePoint3DSlope (#1669)

    • description: adjust all test models and examples for new NodePointSlope… names

    • date resolved: 2023-10-16 08:02, date raised: 2023-10-16

  • 1.7.15 CHECK NodePoint3DSlope23 (#1663)

    • description: check d/dt(A) … computation of time derivative of rotation matrix, also check jacobians and angular velocities; add tests also for Slope12 node

    • date resolved: 2023-10-16 07:45, date raised: 2023-10-15

  • 1.7.14 CHANGE NodePoint3DSlope1 (#1666)

    • description: change to NodePointSlope1

    • date resolved: 2023-10-15 22:29, date raised: 2023-10-15

  • 1.7.13 CHANGE Point3DS23 (#1665)

    • description: remove Point3DS23 as its name is inconsistent with 3D convention and not really needed

    • date resolved: 2023-10-15 22:24, date raised: 2023-10-15

  • 1.7.12 CHANGE NodePoint3DSlope23 (#1664)

    • description: change to NodePointSlope23

    • date resolved: 2023-10-15 22:23, date raised: 2023-10-15

  • 1.7.11 EXTENSION ANCFCable (#1075)

    • description: add 3D version of cable element, not using BeamSection interface for compatibility with Cable2D

    • date resolved: 2023-10-15 14:45, date raised: 2022-05-06

  • 1.7.10 EXTENSION NodePoint3DSlope12 (#1661)

    • description: add ANCF node with slopes x/y for thin plate element

    • date resolved: 2023-10-15 14:21, date raised: 2023-10-15

  • 1.7.9 CHANGE HIGH Lie group nodes (#1403)

    • description: remove LieGroup node RigidBodyRotVecDataLG as it is not needed any more as it can be substituted with more efficient RigidBodyRotVecLG

    • notes: right now added comments in C++ files, not completely removed

    • date resolved: 2023-10-15 11:57, date raised: 2023-01-18

  • 1.7.8 CHANGE remove math.h (#1659)

    • description: change with <cmath> for C++ conformity

    • date resolved: 2023-10-12 17:04, date raised: 2023-10-12

  • 1.7.7 CHANGE switch to MSVC2022 (#1658)

    • description: change main_sln_Template.sln for 2022 update; use cl.exe from MSVC2022 for compilation of wheels; slightly increases performance

    • notes: compilation successful and TestSuite runs through

    • date resolved: 2023-10-12 17:04, date raised: 2023-10-12

  • 1.7.6 CHANGE plot (#1660)

    • description: change plt.tight_layout and plt.legend to fig. if possible to avoid warnings

    • date resolved: 2023-10-12 13:39, date raised: 2023-10-12

  • 1.7.5 FIX Docu (#1657)

    • description: latex errors in robotics mobile and ROS

    • date resolved: 2023-10-09 20:27, date raised: 2023-10-09

  • 1.7.4 EXTENSION resolved by: Martin Sereinig ROS rosInterface (#1656)

    • description: Created robotics.rosInterface and Python models in Examples: ROSMassPoint.py, ROSMobileManipulator.py, ROSTurtle.py with supplementary, see Examples/supplementary: ROSControlMobileManipulation.py, ROSControlTurtleVelocity.py, etc.

    • date resolved: 2023-09-15 15:50, date raised: 2023-09-15

  • 1.7.3 EXTENSION SolveStatic (#1655)

    • description: add option for static solver to handle ODE1 quantities; currently, the option is to set ODE1coordinates to initial values during static computation

    • date resolved: 2023-09-07 21:13, date raised: 2023-09-07

  • 1.7.2 CHANGE Python3.6 support (#1654)

    • description: discontinuing testing and creation of pip installers for Python3.6 in Windows, Linux and MacOS as Python3.6 had end-of-life 2021-12-23; Python 3.7 also had end-of-life recently, so please expect discontinued support soon

    • date resolved: 2023-09-03 16:03, date raised: 2023-09-03

  • 1.7.1 FIX rosInterface.py (#1652)

    • description: add (missing) file to DOCU

    • date resolved: 2023-08-08 17:53, date raised: 2023-08-08

  • 1.7.0 CHANGE release (#1649)

    • description: switch to new release 1.7

    • date resolved: 2023-07-19 16:07, date raised: 2023-07-19

Version 1.6

  • 1.6.189 FIX ReevingSystemSprings (#1648)

    • description: adjust test example for treating compression forces

    • date resolved: 2023-07-17 12:10, date raised: 2023-07-17

  • 1.6.188 EXTENSION sensorTraces (#1647)

    • description: add vectors and triads to position traces; show current vector or triad and add some further options for visualization, see visualizationSettings sensors.traces

    • notes: added triads and vectors, showing traces of motion at sensor points

    • date resolved: 2023-07-14 18:34, date raised: 2023-07-14

  • 1.6.187 EXTENSION visualization (#1640)

    • description: show trace of sensor positions (incl. frames) in render window; settings and list of sensors provided in visualizationSettings.sensors.traces with list of sensors, positionTrace, listOfPositionSensors=[] (empty means all position sensors, listOfVectorSensors=[] which can provide according vector quantities for positions; showVectors, vectorScaling=0.001, showPast=True, showFuture=False, showCurrent=True, lineWidth=2

    • date resolved: 2023-07-14 11:20, date raised: 2023-07-11

  • 1.6.186 EXTENSION ArrayFloat (#1646)

    • description: C++ add type

    • date resolved: 2023-07-13 16:27, date raised: 2023-07-13

  • 1.6.185 EXTENSION ReevingSystemSprings (#1645)

    • description: add way to remove compression forces in rope

    • notes: added parameter regularizationForce with tanh regularization for avoidance of compressive spring force

    • date resolved: 2023-07-12 16:05, date raised: 2023-07-12

  • 1.6.184 EXTENSION Minimize (#1644)

    • description: processing.Minimize: improve printout of current error of objective function=loss; only print every 1 second

    • date resolved: 2023-07-12 09:29, date raised: 2023-07-12

  • 1.6.183 BUG Minimize (#1643)

    • description: processing.Minimize function has an internal bug, such that it does not work with initialGuess=[]

    • date resolved: 2023-07-12 09:29, date raised: 2023-07-12

  • 1.6.182 BUG SolutionViewer (#1642)

    • description: record image not working with visualizationSettings useMultiThreadedRendering=True

    • date resolved: 2023-07-11 17:58, date raised: 2023-07-11

  • 1.6.181 FIX SolutionViewer (#1641)

    • description: github issue#51: graphicsDataUserFunction in SolutionViewer not called; add call to graphicsData user functions in redraw image loop

    • date resolved: 2023-07-11 17:16, date raised: 2023-07-11

  • 1.6.180 EXTENSION GeneticOptimization (#1638)

    • description: add argument parameterFunctionData to GeneticOptimization; same as in ParameterVariation, paramterFunctionData allows to pass additional data to the objective function

    • date resolved: 2023-07-09 09:15, date raised: 2023-07-09

  • 1.6.179 EXTENSION add ChatGPT update information (#1637)

    • description: create Python model Examples/chatGPTupdate.py which includes information that is used by ChatGPT4 to improve abilities to create simple models fully automatic

    • date resolved: 2023-06-30 15:01, date raised: 2023-06-30

  • 1.6.178 CHANGE CreateMassPoint (#1636)

    • description: change args referenceCoordinates to referencePosition, initialCoordinates to initialDisplacement, and initialVelocities to initialVelocity to be consistent with CreateRigidBody (but different from MassPoint itself)

    • date resolved: 2023-06-30 14:09, date raised: 2023-06-30

  • 1.6.177 EXTENSION SmartRound2String (#1635)

    • description: add function to basic utilities to enable simple printing of numbers with few digits, including comma dot and not eliminating small numbers, e.g., 1e-5 stays 1e-5

    • date resolved: 2023-06-30 09:22, date raised: 2023-06-30

  • 1.6.176 EXTENSION create directories (#1634)

    • description: add automatic creation of directories to FEM SaveToFile, plotting and ParameterVariation

    • date resolved: 2023-06-29 10:29, date raised: 2023-06-29

  • 1.6.175 BUG GetInterpolatedSignalValue (#1633)

    • description: timeArray needs to be replaced with timeArrayNew in case of 2D input array

    • date resolved: 2023-06-28 21:15, date raised: 2023-06-28

  • 1.6.174 FIX PlotFFT (#1632)

    • description: matplotlib >= 1.7 complains about ax.grid(b=…) as parameter b has been replaced by visible

    • date resolved: 2023-06-27 14:15, date raised: 2023-06-27

  • 1.6.173 FIX mutable args itemInterface (#1626)

    • description: also copy dictionaries, mainly for visualization (flat level, but this should be sufficient)

    • date resolved: 2023-06-21 10:40, date raised: 2023-06-21

  • 1.6.172 CHANGE mutable default args (#1627)

    • description: complete changes and adaptations for default args in Python functions and item interface; note individual adaptations for lists, vectors, matrices and special lists of lists or matrix containers; for itemInterface, anyway all data is copied into C++; for more information see issues 1536, 1540, 1612, 1624, 1625, 1626

    • date resolved: 2023-06-21 10:15, date raised: 2023-06-21

  • 1.6.171 CHANGE change to default arg None (#1625)

    • description: change default args for Vector2DList, Vector3DList, Vector6DList, Matrix3DList, to None; ArrayNodeIndex, ArrayMarkerIndex, ArraySensorIndex obtain copy method and are copied now; avoid problem of mutable default args

    • date resolved: 2023-06-21 00:26, date raised: 2023-06-20

  • 1.6.170 CHANGE MatrixContainer (#1624)

    • description: change default values for matrix container to None; avoid problem of mutable default args

    • date resolved: 2023-06-20 23:39, date raised: 2023-06-20

  • 1.6.169 CHECK mutable args itemInterface (#1540)

    • description: copy lists in itemInterface in order to avoid change of default args by user n=NodePoint();n.referenceCoordinates[0]=42;n1=NodePoint()

    • notes: simple vectors, matrices and lists are copied with np.array(…) while complex matrix and list of array types are now initialized with None

    • date resolved: 2023-06-20 22:13, date raised: 2023-04-28

  • 1.6.168 DOCU docu MainSystemExtensions (#1620)

    • description: reorder MainSystemExtensions with separate section for Create functions and one section for remaining functions

    • date resolved: 2023-06-19 22:14, date raised: 2023-06-13

  • 1.6.167 BUG mouse click (#1622)

    • description: fix crash on linux if left / right mouse click on render window (related to OpenGL select window)

    • notes: occurs on WSL with WSLg; using ‘export LIBGL_ALWAYS_SOFTWARE=1’ will resolve the problem; put this line into your .bashrc

    • date resolved: 2023-06-19 22:11, date raised: 2023-06-19

  • 1.6.166 BUG LinearSolverType (#1621)

    • description: fix crash on linux in function SetLinearSolverType

    • date resolved: 2023-06-19 20:27, date raised: 2023-06-19

  • 1.6.165 EXTENSION MouseSelectOpenGL (#1623)

    • description: add optional debbuging output

    • date resolved: 2023-06-19 19:56, date raised: 2023-06-19

  • 1.6.164 EXTENSION matrix inverse (#1267)

    • description: add pivot threshold to options, may improve redundant constraints problems

    • notes: only available for EigenDense with ignoreSingularJacobian and EXUdense linear solvers

    • date resolved: 2023-06-12 13:24, date raised: 2022-09-21

  • 1.6.163 CHECK eigen LU (#1616)

    • description: check fastest solver for regular and overdetermined systems

    • notes: Eigen::PartialPivLU 2.5 times faster for 65 DOF test in factorization, factor 3 faster for backsubst

    • date resolved: 2023-06-12 13:22, date raised: 2023-06-11

  • 1.6.162 TESTING Bricard mechanism (#1607)

    • description: add example and test ComputeSystemDegreesOfFreedom

    • date resolved: 2023-06-12 11:02, date raised: 2023-06-09

  • 1.6.161 FIX solver error message (#1617)

    • description: revise hint for ignoreSingularJacobian

    • date resolved: 2023-06-12 01:39, date raised: 2023-06-11

  • 1.6.160 FIX pivotThreshold (#1615)

    • description: add already existing parameter [which is currently not used in solver!] to solver interface add FactorizeNew arg

    • date resolved: 2023-06-12 01:39, date raised: 2023-06-11

  • 1.6.159 EXTENSION matrix inverse (#1266)

    • description: add full pivoting mode for matrix inverse, to resolve redundant constraints; consider Eigen FullPivotLU for dense matrices - see classEigen_1_1FullPivLU.html

    • notes: also added new LinearSolverType.EigenDense which allows to chose FullPivLU by settings ignoreSingularJacobian=True

    • date resolved: 2023-06-12 00:17, date raised: 2022-09-21

  • 1.6.158 CHANGE LinearSolverType (#1619)

    • description: switch to bit-wise numbering of solver types, in order to alleviate checks

    • date resolved: 2023-06-11 23:52, date raised: 2023-06-11

  • 1.6.157 CHANGE ignoreRedundantConstraints (#1618)

    • description: remove option ignoreRedundantConstraints as it cannot be applied with Eigen::FullPivLU; use ignoreSingularJacobian instead

    • date resolved: 2023-06-11 23:46, date raised: 2023-06-11

  • 1.6.156 EXTENSION Experimental (#1613)

    • description: add experimental class, which can be accessed in Python by exudyn.Experimental(); inside C++, just needs to be imported; allows simple testing without interference with main features

    • date resolved: 2023-06-11 19:56, date raised: 2023-06-11

  • 1.6.155 FIX mutable arguments (#1536)

    • description: check and fix Python functions with mutable arguments such as [] or {}, with potential risk of changing internally in function, leading to unexpected behavior in second call

    • notes: checked all default list and dict args

    • date resolved: 2023-06-11 00:24, date raised: 2023-04-27

  • 1.6.154 FIX mutable arguments (#1612)

    • description: check and fix problems in beams.py, FEM.py and graphicsDataUtilities.py

    • notes: see also issue 1536

    • date resolved: 2023-06-10 21:34, date raised: 2023-06-10

  • 1.6.153 EXTENSION AnimateModes (#1609)

    • description: extend for using a set of system eigenmodes

    • date resolved: 2023-06-10 20:25, date raised: 2023-06-10

  • 1.6.152 EXTENSION mainSystemExtensions (#1580)

    • description: add RigidBodySpringDamper

    • date resolved: 2023-06-10 20:25, date raised: 2023-05-21

  • 1.6.151 EXTENSION ComputeODE2Eigenvalues (#1606)

    • description: add eigenvector computation to constrained case

    • notes: needs further testing!

    • date resolved: 2023-06-10 19:11, date raised: 2023-06-08

  • 1.6.150 CHANGE SolutionViewer (#1611)

    • description: change internal variables from mbs.variables to mbs.sys

    • date resolved: 2023-06-10 17:48, date raised: 2023-06-10

  • 1.6.149 CHANGE AnimateModes (#1610)

    • description: change internal variables from mbs.variables to mbs.sys

    • date resolved: 2023-06-10 17:47, date raised: 2023-06-10

  • 1.6.148 BUG visualization zoom all (#1608)

    • description: when calling ComputeSystemDegreeOfFreedom, ComputeODE2Eigenvalues and similar functions, and StartRenderer is called right afterwards, zoom all does not work

    • notes: shall be resolved just by calling StartRenderer before first call to any solver functionality

    • date resolved: 2023-06-10 11:44, date raised: 2023-06-10

  • 1.6.147 EXTENSION HIGH solver (#1435)

    • description: add deriviative of loads to regular jacobian computation with flag (default=False); use numerical diff sim. to JacobianODE2

    • notes: already done earlier in #1546

    • date resolved: 2023-06-08 23:35, date raised: 2023-02-16

  • 1.6.146 FIX Command execute (#1597)

    • description: switch to grid method for placing widgets, tkinter does not allow pack and grid in different windows

    • date resolved: 2023-06-08 21:56, date raised: 2023-06-05

  • 1.6.145 BUG TemporaryComputationDataArray bug (#1593)

    • description: ERROR: “TemporaryComputationDataArray::operator[]: index out of range” is raised if single-threaded computation is run after multi-threaded simulation; requires restart of Python instance

    • date resolved: 2023-06-08 18:50, date raised: 2023-06-03

  • 1.6.144 EXTENSION ComputeODE2Eigenvalues (#1599)

    • description: compute eigenmodes in case of algebraic equations

    • date resolved: 2023-06-08 18:46, date raised: 2023-06-08

  • 1.6.143 EXTENSION AddSensor (#1603)

    • description: add check if no outputVariable is provided-> immediately raise error

    • notes: was already in system checks, which however were not called, see issue 1604

    • date resolved: 2023-06-08 18:45, date raised: 2023-06-08

  • 1.6.142 EXAMPLE eigenvalues constrained system (#1598)

    • description: add example for eigenvalue computation of constrained system

    • notes: added computeODE2AEeigenvaluesTest.py

    • date resolved: 2023-06-08 18:45, date raised: 2023-06-08

  • 1.6.141 CHANGE ComputeSystemDegreeOfFreedom (#1605)

    • description: change output to a dictionary in order to have readable results

    • date resolved: 2023-06-08 18:35, date raised: 2023-06-08

  • 1.6.140 FIX Sensors (#1604)

    • description: PreAssembleConsistencies not called in Assemble; thus, no checks are performed on sensor inputs

    • date resolved: 2023-06-08 18:24, date raised: 2023-06-08

  • 1.6.139 BUG MainSystem CreateRigidBody (#1602)

    • description: referenceRotationMatrix multiplied in wrong way with initialRotationMatrix

    • notes: also rotation parameters in initialVelocities were wrong for initialRotationMatrix!=np.eye(3); fixed, but more testing needed

    • date resolved: 2023-06-08 17:42, date raised: 2023-06-08

  • 1.6.138 EXTENSION stub files (.pyi) (#1600)

    • description: extend .pyi files for system structures functions, e.g., ComputeJacobianODE2RHS

    • date resolved: 2023-06-08 17:17, date raised: 2023-06-08

  • 1.6.137 CHANGE stub files (.pyi) (#1601)

    • description: merge .pyi files to have classes such as MainSystem only appearing once

    • date resolved: 2023-06-08 16:37, date raised: 2023-06-08

  • 1.6.136 EXTENSION resolved by: M. Pieber, JG ComputeODEEigenvalues (#746)

    • description: add possibility to eliminate coordinate constraints, possibly to use SVD/ null space matrix for projection

    • notes: algebraic constraints now considered automatically; algebraic constraints now considered automatically

    • date resolved: 2023-06-07 23:52, date raised: 2021-09-03

  • 1.6.135 EXTENSION ComputeODE2Eigenvalues (#743)

    • description: add vector of constrained coordinates which are eliminated; also add functionality for complex eigenvalues

    • notes: already done earlier

    • date resolved: 2023-06-07 23:09, date raised: 2021-08-20

  • 1.6.134 EXTENSION Command dialog (#1595)

    • description: extend to multi-line commands; execute code using CTRL-Return

    • notes: Behavior is now DIFFERENT, as variables are not printed automatically; write e.g. print(mbs) to see mbs representation; see section Execute Command and Help

    • date resolved: 2023-06-04 19:40, date raised: 2023-06-03

  • 1.6.133 EXTENSION linuxDisplayScaleFactor (#1596)

    • description: add scaling for fonts on linux, specifically for high resolution screens

    • date resolved: 2023-06-04 00:13, date raised: 2023-06-04

  • 1.6.132 FIX ParameterVariation, useMPI (#1588)

    • description: only accept useMPI if set True

    • date resolved: 2023-06-03 19:26, date raised: 2023-05-31

  • 1.6.131 EXTENSION mainSystemExtensions (#1579)

    • description: Add distance constraint and CartesianSpringDamper

    • date resolved: 2023-06-03 19:26, date raised: 2023-05-21

  • 1.6.130 CHANGE window closing, key Q (#1594)

    • description: slightly adapt behavior; fix some smaller issues with expected window behavior

    • date resolved: 2023-06-03 17:01, date raised: 2023-06-03

  • 1.6.129 EXTENSION CHECK (#1356)

    • description: Add security question on quit/escape if computation Renderer runs longer than 15 minutes

    • notes: added message in render window to click twice on exit window icon (X) after 15 minutes; key Q and escape get tkinter message box

    • date resolved: 2023-06-03 16:00, date raised: 2023-01-01

  • 1.6.128 FIX SolverBase it.endTime (#1592)

    • description: in dynamic solver it.endTime is overwritten with simulationSettings.timeIntegration.endTime; this is against the description and does not allow to change it.endTime in command window; remove overwritting to be consistent with description of Execute Command and Help section in EXUDYN Basics

    • date resolved: 2023-06-03 14:25, date raised: 2023-06-03

  • 1.6.127 FIX SphericalJoint (#1591)

    • description: causes memory allocation; check LinkedDataVector cast

    • date resolved: 2023-06-01 11:12, date raised: 2023-06-01

  • 1.6.126 FIX serialRobotKinematicTree.py (#1590)

    • description: fixed static torque compensation for kinematic tree and fixed sensor outputs

    • date resolved: 2023-05-31 13:07, date raised: 2023-05-31

  • 1.6.125 DOCU ObjectKinematicTree (#1589)

    • description: add description of SensorKinematicTree output variables per link

    • date resolved: 2023-05-31 12:42, date raised: 2023-05-31

  • 1.6.124 CHANGE solution file footer (#1587)

    • description: add comma after cpuTime=…

    • date resolved: 2023-05-30 23:52, date raised: 2023-05-30

  • 1.6.123 EXTENSION SetPreStepUserFunction, SetPostNewtonUserFunction (#1586)

    • description: add exception handling in set function

    • date resolved: 2023-05-26 19:52, date raised: 2023-05-26

  • 1.6.122 DOCU class name highlighting RTD (#1585)

    • description: fixed exporting class names from pythonUtilities

    • date resolved: 2023-05-25 15:19, date raised: 2023-05-25

  • 1.6.121 CHANGE MiniExamples (#1584)

    • description: remove import of itemInterface

    • date resolved: 2023-05-25 14:32, date raised: 2023-05-25

  • 1.6.120 BUG GeneticOptimization (#1583)

    • description: results are erroneous in case of crossoverProbability > 0

    • notes: fixed writing of output files which had mixed order due to parameter cross-over

    • date resolved: 2023-05-23 18:31, date raised: 2023-05-23

  • 1.6.119 FIX mainSystemExtensions (#1582)

    • description: remove import of tkinter and matplotlib to resolve errors when loading exudyn and these libs are not installed

    • date resolved: 2023-05-22 10:54, date raised: 2023-05-22

  • 1.6.118 FIX examples (#1577)

    • description: test if all Examples are still running

    • date resolved: 2023-05-20 22:23, date raised: 2023-05-20

  • 1.6.117 FIX ObjectConnectorCoordinateSpringDamper (#1578)

    • description: correct docu on object and user function description (still includes friction)

    • date resolved: 2023-05-20 21:13, date raised: 2023-05-20

  • 1.6.116 EXAMPLE mainSystemExtensions (#1569)

    • description: add mini-examples for extensions

    • notes: collected miniexamples in mainSystemExtensionsTests.py;

    • date resolved: 2023-05-20 21:05, date raised: 2023-05-15

  • 1.6.115 CHANGE mainSystemExtensions (#1571)

    • description: adapt Examples to Python extensions (SolveDynamic, CreateRigidBody, CreateGenericJoint, …)

    • date resolved: 2023-05-18 23:43, date raised: 2023-05-15

  • 1.6.114 CHANGE mainSystemExtensions (#1570)

    • description: adapt TestModels to Python extensions

    • date resolved: 2023-05-18 23:43, date raised: 2023-05-15

  • 1.6.113 BUG multithreading (#1576)

    • description: running laserScannerTest.py after a multithreaded contact computation raises the EXCEPTION: TemporaryComputationDataArray::operator[]: index out of range

    • date resolved: 2023-05-18 23:13, date raised: 2023-05-18

  • 1.6.112 CHANGE ConnectorDistance (#1575)

    • description: changed parameter distance to PReal, not allowing zero distance to be prescribed

    • date resolved: 2023-05-18 13:03, date raised: 2023-05-18

  • 1.6.111 DOCU mainSystemExtensions (#1573)

    • description: Adapt tutorials to new functionality

    • date resolved: 2023-05-18 12:19, date raised: 2023-05-16

  • 1.6.110 FIX Python utilities (#1574)

    • description: classes not appearing in table of contents on RTD

    • date resolved: 2023-05-17 20:21, date raised: 2023-05-16

  • 1.6.109 EXTENSION CreateRigidBody (#1572)

    • description: added to MainSystem to enable mbs.CreateRigidBody(…)

    • date resolved: 2023-05-16 11:54, date raised: 2023-05-16

  • 1.6.108 EXTENSION mainSystemExtensions (#1568)

    • description: create first sample of Python extensions for basic joints

    • date resolved: 2023-05-15 18:13, date raised: 2023-05-15

  • 1.6.107 CHANGE DrawSystemGraph (#1567)

    • description: in case of showItemNames, no item numbers are shown as they confuse with numbers used in names

    • date resolved: 2023-05-15 17:18, date raised: 2023-05-15

  • 1.6.106 CHANGE AddDistanceSensor(…) (#1566)

    • description: function RENAMED into CreateDistanceSensor(…) to be consistent with future naming; also renamed DistanceSensorSetupGeometry(…) into CreateDistanceSensorGeometry(…)

    • date resolved: 2023-05-15 11:34, date raised: 2023-05-15

  • 1.6.105 EXTENSION MainSystem Python extensions (#1563)

    • description: add Python utility functions for mbs, such as PlotSensor, SolveDynamic, …; use identical interfaces to alleviate creation of .pyi files and documentation; add new flag mbsFunction as hint to put docu to MainSystem and make .pyi extension

    • notes: see sec:mainsystem:pythonExtensions for extended functionality

    • date resolved: 2023-05-15 01:17, date raised: 2023-05-09

  • 1.6.104 DOCU Type definitions (#1564)

    • description: fix header structure in latex and RST for Type Definitions

    • date resolved: 2023-05-11 11:30, date raised: 2023-05-11

  • 1.6.103 EXTENSION stub files (.pyi) (#1561)

    • description: add .pyi files to setup_tools, copying them from autogenerate folder; use try catch to avoid problems at other platforms

    • date resolved: 2023-05-10 23:30, date raised: 2023-05-09

  • 1.6.102 EXTENSION stub files (.pyi) (#1560)

    • description: automatically create stub file for C++ classes such as MainSystem, SystemContainer, GeneralContact, … by adding return type information and creating .pyi file; use temporary .pyi files in autogenerate folder

    • date resolved: 2023-05-10 23:19, date raised: 2023-05-09

  • 1.6.101 EXTENSION stub files (.pyi) (#1562)

    • description: add .pyi files for enums from autoGeneratePyBindings

    • date resolved: 2023-05-10 20:43, date raised: 2023-05-09

  • 1.6.100 EXTENSION stub files (.pyi) (#1559)

    • description: automatically create stub file for settings to alleviate auto-completion; type completion now also works for functions, types and structures: tested in Spyder and Visual Studio Code

    • date resolved: 2023-05-10 08:39, date raised: 2023-05-09

  • 1.6.99 CHECK stub files (.pyi) (#1557)

    • description: test creating stub files (.pyi) which are needed for MainSystem Python extensions

    • notes: tested with Spyder 5.1.5 and Visual Studio Code 1.78

    • date resolved: 2023-05-10 08:39, date raised: 2023-05-07

  • 1.6.98 FIX enum in global scope (#1558)

    • description: pybind11 translates enums to global module scope, e.g. exudyn.ItemType.Marker is also available as exudyn.Marker; remove export_values() in pybind interface

    • notes: if you by occasion used e.g. exu.DisplacementLocal instead of exu.OutputVariableType.DisplacementLocal you need to adapt your code!

    • date resolved: 2023-05-09 18:30, date raised: 2023-05-09

  • 1.6.97 EXTENSION IsValidPRealPInt, IsValidURealPInt (#1556)

    • description: add functions to advancedUtilities for additional checks in Python functions

    • date resolved: 2023-05-07 20:33, date raised: 2023-05-07

  • 1.6.96 EXTENSION color4default (#1555)

    • description: add default color to graphicsDataUtilities as a default value for items

    • date resolved: 2023-05-07 18:12, date raised: 2023-05-07

  • 1.6.95 CHANGE NodePoint2D (#1554)

    • description: draw as sphere by default to improve visibility

    • date resolved: 2023-05-07 16:31, date raised: 2023-05-07

  • 1.6.94 CHANGE item names (#1539)

    • description: remove stored string and replace by empty string in case of default item name

    • notes: not changed: std::string has practically no effect on memory footprint of items; check memory footprint separately (LTG lists, etc.)!

    • date resolved: 2023-05-05 23:32, date raised: 2023-04-28

  • 1.6.93 FIX AccelerationLocal, AngularAccelerationLocal (#1553)

    • description: add missing values to Pybind interface

    • date resolved: 2023-05-02 17:41, date raised: 2023-05-02

  • 1.6.92 EXTENSION HydraulicActuator (#1552)

    • description: add VelocityLocal as output variable, which provides the time derivative of the distance, being the actuator velocity; updated docu and fixed description for outputvariable Velocity

    • date resolved: 2023-05-02 16:51, date raised: 2023-05-02

  • 1.6.91 CHANGE GeometricallyExactBeam (#1551)

    • description: evaluate rotation at midspan of beam

    • date resolved: 2023-05-02 15:02, date raised: 2023-05-02

  • 1.6.90 TESTING NORMAL ANCFBeam (#1502)

    • description: check for very large deformations

    • notes: poor performance for large deformations caused by missing load jacobian

    • date resolved: 2023-05-01 19:26, date raised: 2023-04-08

  • 1.6.89 TESTING NORMAL GeometricallyExactBeam (#1501)

    • description: check for very large deformations

    • notes: poor performance for large deformations caused by missing load jacobian

    • date resolved: 2023-05-01 19:26, date raised: 2023-04-08

  • 1.6.88 CHANGE computeLoadsJacobian (#1546)

    • description: add flag in timeIntegration and staticSolver settings to turn on/off jacobian of loads; will be by default turned on in static solver, turned off in time integration; adapt your models

    • date resolved: 2023-05-01 19:22, date raised: 2023-05-01

  • 1.6.87 EXTENSION ComputeSingleLoads (#1545)

    • description: adapt for Jacobian computation of loads

    • date resolved: 2023-05-01 19:22, date raised: 2023-05-01

  • 1.6.86 FIX GetMarkerOutput (#1547)

    • description: in case of OuputVariableType.Coordinates, add check if Marker is of type Coordinate or Coordinates

    • date resolved: 2023-05-01 16:17, date raised: 2023-05-01

  • 1.6.85 EXTENSION systemData.GetNodeLocalToGlobal (#1544)

    • description: add systemData access functions for LTG mappings of nodes, useful to check node coordinates; works for ODE2, ODE1, AE and Data coordinates; useful to create load dependencies

    • date resolved: 2023-04-29 22:03, date raised: 2023-04-29

  • 1.6.84 EXTENSION systemData (#1543)

    • description: add InfoLTG function which outputs LTG lists and load dependencies

    • date resolved: 2023-04-29 22:03, date raised: 2023-04-29

  • 1.6.82 CHANGE HydraulicsActuator (#1542)

    • description: changing referenceVolume0 and referenceVolume1 to hoseVolume0 and hoseVolume1 with different meaning according to referenced paper; adjust your models!

    • notes: thanks to Qasim Khadim for provigind the model

    • date resolved: 2023-04-29 01:11, date raised: 2023-04-29

  • 1.6.81 EXTENSION HydraulicsActuator (#1541)

    • description: extend model of effective bulk modulus acc. to paper https://doi.org/10.1007/s11044-019-09696-y

    • date resolved: 2023-04-29 01:10, date raised: 2023-04-28

  • 1.6.80 FIX taskmanager (#1538)

    • description: fix problem with taskmanager shutdown due to issue 1532

    • date resolved: 2023-04-27 15:35, date raised: 2023-04-27

  • 1.6.79 FIX output.multiThreadingMode (#1537)

    • description: has not been set correctly in solver so far; switch output.numberOfThreadsUsed and output.multiThreadingMode

    • date resolved: 2023-04-27 15:35, date raised: 2023-04-27

  • 1.6.78 EXTENSION writeSensors (#1535)

    • description: add global flag to deactivate sensor file creating/writing and sensor storing; set flag in solver functions such as ComputeLinearizedSystem, etc. to avoid erasing sensor files or sensor data

    • date resolved: 2023-04-27 11:34, date raised: 2023-04-26

  • 1.6.77 FIX FinalizeSolver (#1533)

    • description: call FinalizeSolver in ComputeLinearizedSystem, ComputeSystemDegreeOfFreedom, ComputeODE2Eigenvalues for consistency reason; also deactivate file writing and sensor writing and solverInformation writing

    • date resolved: 2023-04-26 19:25, date raised: 2023-04-26

  • 1.6.76 FIX CSolverBase.cpp (#1532)

    • description: close output and sensor files in destructor of CSolverBase

    • date resolved: 2023-04-26 19:24, date raised: 2023-04-26

  • 1.6.75 CHANGE EXUlie (#1534)

    • description: improve TExpSE3 and TExpSE3Inv regarding small values according to PhD thesis of Stefan Hante

    • notes: improves numerical behavior and convergence of GeometricallyExactBeam

    • date resolved: 2023-04-26 18:33, date raised: 2023-04-26

  • 1.6.74 FIX OpenVR (#1531)

    • description: change order of eye transformation and projection in OpenVRinterface GetCurrentViewProjectionMatrix to be consistent with master thesis

    • date resolved: 2023-04-26 16:49, date raised: 2023-04-26

  • 1.6.73 EXTENSION ComputeSystemDegreeOfFreedom (#1530)

    • description: add exudyn.solver function to numerically compute DOF of constrained mechanisms

    • date resolved: 2023-04-26 11:16, date raised: 2023-04-26

  • 1.6.72 DOCU structures and settings (#1528)

    • description: function arguments in RST / html are inappropriately noted; fix; replace true/false with True/False

    • date resolved: 2023-04-26 09:16, date raised: 2023-04-26

  • 1.6.71 EXTENSION GeneralContact (#1527)

    • description: add function UpdateContacts, which computes current bounding boxes and active contacts, to be used in access functions to GeneralContact if isActive=False (otherwise this is anyway done in contact computations of every computation step)

    • date resolved: 2023-04-23 20:15, date raised: 2023-04-23

  • 1.6.70 EXTENSION GeneralContact (#935)

    • description: add interface function to get contact pairs

    • notes: function GetActiveContacts added to GeneralContact, which returns all active global contact indices for selected contact type

    • date resolved: 2023-04-23 20:13, date raised: 2022-02-10

  • 1.6.69 EXTENSION solver failed function (#1516)

    • description: add function to check if solver failed, using stored solver structure as input; return True/False and string (optionally error code) describing failure

    • notes: added function SolverSuccess() to exudyn.solver; returns success and error string as created by solver internal function GetErrorString(…)

    • date resolved: 2023-04-23 18:43, date raised: 2023-04-19

  • 1.6.68 EXTENSION solver GetErrorString (#1526)

    • description: MainSolverStatic, MainSolverExplicit, MainSolverImplicit now get function GetErrorString to obtain error string set if SolveSteps or SolveSystem failed (returned false)

    • date resolved: 2023-04-23 11:46, date raised: 2023-04-23

  • 1.6.67 EXTENSION output.finishedSuccessfully (#1525)

    • description: flag is now set both in SolveSteps(…) as well in SolveSystem(…) to indicate if solver has been successful or failed; practical flag for lateron determination of solver errors

    • date resolved: 2023-04-23 11:46, date raised: 2023-04-23

  • 1.6.66 EXAMPLE netgen STL file (#1524)

    • description: add example with netgen and STL files with meshing

    • date resolved: 2023-04-21 17:51, date raised: 2023-04-21

  • 1.6.65 EXTENSION ObjectFFRFreducedOrderInterface (#1521)

    • description: add LoadFromFile/SaveToFile similar to FEMinterface

    • notes: this function should be used to store CMS data if FEM is too large to load/store; CMS data still stores all node positions, triangle list (for visualization) and modeBasis for computation tasks; may be still large e.g. for many nodes and large number of modes

    • date resolved: 2023-04-20 21:06, date raised: 2023-04-20

  • 1.6.64 CHANGE FEMinterface (#1519)

    • description: add version to LoadFromFile/SaveToFile function; store file version as first field to load/store in order to be able to load older data as well; use forceVersion=0 to load files in old format

    • notes: warning is printed if old file is loaded

    • date resolved: 2023-04-20 20:59, date raised: 2023-04-19

  • 1.6.63 EXTENSION StrNodeType2NodeType (#1523)

    • description: add function to rigidBodyUtilities in order to make str to type conversion

    • date resolved: 2023-04-20 18:34, date raised: 2023-04-20

  • 1.6.62 CHANGE ObjectFFRFreducedOrderInterface (#1522)

    • description: remove femInterface from internal variables, as it is only used for postProcessingModes; store postProcessingModes instead

    • date resolved: 2023-04-20 16:34, date raised: 2023-04-20

  • 1.6.61 CHANGE ImportFromAbaqusInputFile (#1520)

    • description: use VolumeToSurfaceElements for creating of surface elements; add option to automatically create surface triangles

    • notes: by default, only surface triangles are created!

    • date resolved: 2023-04-20 15:44, date raised: 2023-04-20

  • 1.6.60 FIX ObjectFFRFreducedOrderInterface (#1518)

    • description: roundMassMatrix and roundStiffnessMatrix are not used

    • notes: added as arguments in RoundMatrix

    • date resolved: 2023-04-19 19:08, date raised: 2023-04-19

  • 1.6.59 EXTENSION ImportFromAbaqusInputFile (#1517)

    • description: extended for Tet4 and Tet10 as well as C3D20R elements and added function ConvertTetToTrigs(…)

    • date resolved: 2023-04-19 18:14, date raised: 2023-04-19

  • 1.6.58 IMPROVEMENT unused header files (#1515)

    • description: remove unused header files for C, Main and Visu: JointPrismatic.h, JointRevolute.h

    • date resolved: 2023-04-16 13:03, date raised: 2023-04-16

  • 1.6.57 EXTENSION LaserSensor (#1269)

    • description: add advanced distance sensors replicating laser scanner (with axis, revolution speed and initial direction)

    • notes: added function AddLidar(…) into exudyn.robotics.utilities; see laserScannerTest.py

    • date resolved: 2023-04-15 15:33, date raised: 2022-09-21

  • 1.6.56 EXTENSION DistanceSensor (#1270)

    • description: add advanced distance sensor with possibility to use a set of beams and averaging or multiple output

    • notes: added DistanceSensorSetupGeometry in exudyn.utilities to set up contact geometry easily; see laserScannerTest.py

    • date resolved: 2023-04-15 15:32, date raised: 2022-09-21

  • 1.6.55 BUG GetInterpolatedSignalValue (#1514)

    • description: check for simple test, seems not to work

    • notes: changed order of args: dataArrayIndex and timeArrayIndex

    • date resolved: 2023-04-15 14:34, date raised: 2023-04-14

  • 1.6.54 FIX RevoluteJoint, PrismaticJoint (#1513)

    • description: both ObjectJointPrismaticX and ObjectJointRevoluteZ have wrong internal typename JointRevolute; change to correct names; when analyzing such objects, they will return wrong typenames

    • date resolved: 2023-04-14 14:36, date raised: 2023-04-14

  • 1.6.53 EXTENSION AddDistanceSensor (#1511)

    • description: add optional color for laser beam

    • date resolved: 2023-04-13 17:45, date raised: 2023-04-13

  • 1.6.52 BUG AddDistanceSensor (#1510)

    • description: checks performed with invalid marker number

    • date resolved: 2023-04-13 10:28, date raised: 2023-04-13

  • 1.6.51 EXTENSION object factory (#1141)

    • description: consider hash tables for object factory; check current performance?

    • notes: no changes; string comparison has no effect on performance as compared to new and pybind11 overheads for call to AddObject, etc.

    • date resolved: 2023-04-10 21:48, date raised: 2022-06-12

  • 1.6.50 FIX ODE2Size (#1506)

    • description: and other functions have additional ConfigurationType: remove

    • notes: kept the argument ConfigurationType; usually, all configuration types have same sizes but the call must be related to a speficic configuration

    • date resolved: 2023-04-10 21:42, date raised: 2023-04-08

  • 1.6.49 FIX SystemData (#1509)

    • description: prevent from creation of a pure SystemData in exudyn; check constructor used in SC.AddSystem and SystemData()

    • date resolved: 2023-04-10 21:37, date raised: 2023-04-10

  • 1.6.48 FIX MainSystem (#1508)

    • description: prevent from creation of a pure MainSystem in exudyn; check constructor used in SC.AddSystem and MainSystem()

    • date resolved: 2023-04-10 21:37, date raised: 2023-04-10

  • 1.6.47 DOCU SystemContainer (#1507)

    • description: add description for SystemContainer itself; sying that it behaves like a variable in Python

    • date resolved: 2023-04-10 21:36, date raised: 2023-04-10

  • 1.6.46 DOCU item description (#1503)

    • description: add general description to RST / sphinx

    • date resolved: 2023-04-08 19:04, date raised: 2023-04-08

  • 1.6.45 CHECK AddMainObjectPyClass (#1496)

    • description: C++: for adding objects, nodes, etc. currently py::object and py::dict is copied: check performance increase, if it is passed by reference

    • notes: tests show small performance improvements (<10 percent) for creation of items

    • date resolved: 2023-04-08 17:36, date raised: 2023-04-07

  • 1.6.44 CHECK NORMAL MarkerNodeRotationCoordinate (#1498)

    • description: check if Orientation type is correct, see docu

    • notes: removed Marker::Orientation from MarkerNodeRotationCoordinate as it is not provided

    • date resolved: 2023-04-08 17:30, date raised: 2023-04-08

  • 1.6.43 BUG PyBeamSection (#1497)

    • description: C++: segmentation fault in linux, caused by conversion from numpy array into std::array; use SetConstMatrixTemplateSafely for writing matrix or list

    • date resolved: 2023-04-07 19:05, date raised: 2023-04-07

  • 1.6.42 BUG BeamSection (#1495)

    • description: PyBeamSection does not call parent constructor (BeamSection); leads to seg fault in linux version

    • date resolved: 2023-04-07 13:32, date raised: 2023-04-07

  • 1.6.41 CHECK GeometricallyExactBeam (#1272)

    • description: check jacobian computation as numerical differentiation works better; similar to #1100

    • notes: fixed bug of GeometricallyExactBeam having wrong jacobian

    • date resolved: 2023-04-06 18:28, date raised: 2022-09-24

  • 1.6.40 DOCU Python utilities (#1492)

    • description: fix indentation of examples

    • date resolved: 2023-04-06 14:55, date raised: 2023-04-06

  • 1.6.39 FIX ProcessParameterList (#1491)

    • description: remove addComputationIndex, as it is unused

    • date resolved: 2023-04-06 14:35, date raised: 2023-04-06

  • 1.6.38 DOCU renderState (#1156)

    • description: add description of render state from C++ into theDoc

    • notes: added section Render State in section Graphics and Visualization (GUI)

    • date resolved: 2023-04-05 14:14, date raised: 2022-06-21

  • 1.6.37 DOCU sphinx (#1468)

    • description: add issue and bugs section with resolved issues and open issues table; resolved issues with version

    • notes: already done earlier

    • date resolved: 2023-04-05 14:08, date raised: 2023-03-22

  • 1.6.36 CHANGE ANCFBeam (#1490)

    • description: remove testBeamRectangularSize

    • date resolved: 2023-04-05 13:59, date raised: 2023-04-05

  • 1.6.35 EXTENSION ANCFBeam3D (#1088)

    • description: add test model, compare to 2013 paper

    • date resolved: 2023-04-04 20:59, date raised: 2022-05-16

  • 1.6.34 BUG CObjectANCFBeam (#1489)

    • description: Computation of elastic forces uses global instead of local twist-and-curvature vector

    • date resolved: 2023-04-04 20:04, date raised: 2023-04-04

  • 1.6.33 EXTENSION NodePoint3DSlope23 (#1488)

    • description: add full rigid body output values to node (e.g., Rotation missing)

    • date resolved: 2023-04-04 13:31, date raised: 2023-04-04

  • 1.6.32 EXTENSION Acceleration (#1487)

    • description: add GetAcceleration function to all nodes; add acceleration to all ODE2-based node output variables

    • date resolved: 2023-04-04 13:27, date raised: 2023-04-04

  • 1.6.31 CHANGE EnterTaskManager (#1482)

    • description: removed call to EnterTaskManager in serial mode as it causes large overhead; also removed large array for tracer

    • date resolved: 2023-03-28 18:47, date raised: 2023-03-28

  • 1.6.30 CHANGE InverseKinematicsNumerical (#1481)

    • description: changed SolveIKine to Solve and changed OutputVariable Rotation to RotationMatrix at tool

    • date resolved: 2023-03-28 16:30, date raised: 2023-03-28

  • 1.6.29 EXTENSION LogSE3 (#1480)

    • description: fixed according to LogSO3 and added efficient version with vectors in C++

    • date resolved: 2023-03-28 15:10, date raised: 2023-03-28

  • 1.6.28 FIX LogSO3 (#1478)

    • description: Add new LogSO3 C++ function, also to be used in LogSE3 which fully works for 0..pi rotation range; improved accuracy for very small rotations as well as rotations close to pi, e.g. 0.99999999*pi, where the standard approach fails

    • date resolved: 2023-03-28 15:09, date raised: 2023-03-27

  • 1.6.27 FIX NORMAL RotationMatrix2Rxyz (#1469)

    • description: extend implementation for rot[1]=pi/2

    • notes: resolved both in Python and C++; some simulation results may change, especially in output of Rotations in sensors

    • date resolved: 2023-03-28 14:46, date raised: 2023-03-22

  • 1.6.26 FIX LogSO3 (#1477)

    • description: Add new LogSO3 Python function, also to be used in LogSE3 which fully works for 0..pi rotation range; improved accuracy for very small rotations as well as rotations close to pi, e.g. 0.99999999*pi, where the standard approach fails

    • date resolved: 2023-03-27 20:16, date raised: 2023-03-27

  • 1.6.25 FIX RotationMatrix2… (#1476)

    • description: RotationMatrix2EulerParameters, RotationMatrix2RotXYZ, RotationMatrix2RotZYZ not working both with list of lists and np.arrays

    • date resolved: 2023-03-27 19:58, date raised: 2023-03-27

  • 1.6.23 EXTENSION Add all types to pybind (#312)

    • description: add remaining types to pybind - for user elements

    • notes: important types already added; further types currently not planned

    • date resolved: 2023-03-27 00:45, date raised: 2020-01-10

  • 1.6.22 DOCU add demos to github (#848)

    • description: add demo videos to github or to youtube

    • notes: already resolved earlier: added videos to youtube

    • date resolved: 2023-03-27 00:42, date raised: 2021-12-26

  • 1.6.21 EXTENSION connector jacobian springDamper (#843)

    • description: add analytic jacobian for SpringDamper connector

    • notes: already resolved earlier

    • date resolved: 2023-03-27 00:42, date raised: 2021-12-23

  • 1.6.20 EXTENSION ComputeObjectODE2LHS (#851)

    • description: add computation functions for bodies and connectors; for connectors, markerData is computed automatically

    • notes: already resolved earlier with precomputed lists

    • date resolved: 2023-03-27 00:40, date raised: 2022-01-08

  • 1.6.19 FIX MergeGraphicsDataTriangleList (#1325)

    • description: merging of edges erroneous or problems with GraphicsDataCylinder

    • date resolved: 2023-03-27 00:21, date raised: 2022-12-19

  • 1.6.18 EXTENSION GraphicsData (#1472)

    • description: add addEdges option to all GraphicsData Python functions

    • notes: added to sphere, cylinder, SolidOfRevolution, SolidOfExtrusion

    • date resolved: 2023-03-27 00:10, date raised: 2023-03-26

  • 1.6.17 CHANGE GraphicsData (#1473)

    • description: improve edges of cylinder and sphere by adding 6 lines along cylinder, some circles for sphere

    • date resolved: 2023-03-27 00:09, date raised: 2023-03-26

  • 1.6.16 DOCU mention papers (#1459)

    • description: add list of papers where exudyn has been used in theDoc and RTD

    • date resolved: 2023-03-26 15:04, date raised: 2023-03-10

  • 1.6.15 DOCU issues tracker (#1471)

    • description: remove html file from docs, use RSTfiles instead / move to readthedocs

    • date resolved: 2023-03-24 20:40, date raised: 2023-03-24

  • 1.6.14 EXTENSION GraphicsDataBasis (#1470)

    • description: add orientation and duplicate function with homogeneous transformation (HT) argument

    • notes: function called GraphicsDataFrame for Homogeneous transformation

    • date resolved: 2023-03-24 10:04, date raised: 2023-03-24

  • 1.6.13 FIX resolved by: P. Manzl InverseKinematicsNumerical (#1467)

    • description: fix success

    • date resolved: 2023-03-22 12:06, date raised: 2023-03-22

  • 1.6.12 CHANGE modKKDH (#1466)

    • description: consistently renamed into modDHKK in robotics module

    • date resolved: 2023-03-22 11:04, date raised: 2023-03-22

  • 1.6.11 CHANGE robotics.models (#1465)

    • description: adjust robot definitions, add dhMode to dictionary; fix LinkList2Robot

    • date resolved: 2023-03-22 10:39, date raised: 2023-03-22

  • 1.6.10 FIX resolved by: P. Manzl artificialIntelligence (#1464)

    • description: adapt to stable-baselines3 > 1.5.0; Class OpenAIGymInterfaceEnv does not support stable-baselines3 > 1.5.0 because OpenAIGymInterfaceEnv is not inherited from gym.Env

    • date resolved: 2023-03-20 12:54, date raised: 2023-03-20

  • 1.6.9 EXTENSION mpi4py (#1463)

    • description: add option to use MPI (message passing interface) for ProcessParameterList

    • notes: tests on supercomputer successful

    • date resolved: 2023-03-18 22:59, date raised: 2023-03-18

  • 1.6.8 DOCU minimum coordinates (#1462)

    • description: change consistently to minimal coordinates

    • date resolved: 2023-03-14 17:39, date raised: 2023-03-14

  • 1.6.7 BUG resolved by: P. Manzl isIntType check ParameterVariation (#1461)

    • description: In the ParameterVariation (part of the processing module) the integer type check failed when Variables of different types were used, now checking each variable independently

    • notes: added isIntType arrays

    • date resolved: 2023-03-14 12:50, date raised: 2023-03-14

  • 1.6.6 DOCU Newton (#1457)

    • description: fix steps and Newton iterations in description of Newton settings (thanks to Martin Arnold!)

    • date resolved: 2023-03-12 23:05, date raised: 2023-03-09

  • 1.6.5 DOCU sphinx/github pages (#1456)

    • description: add examples and test models for better search results

    • date resolved: 2023-03-12 23:05, date raised: 2023-03-09

  • 1.6.4 DOCU sphinx/github pages (#1445)

    • description: add solver description

    • date resolved: 2023-03-12 23:05, date raised: 2023-02-22

  • 1.6.3 DOCU sphinx/github pages (#1443)

    • description: add theory parts as far as possible

    • date resolved: 2023-03-12 23:05, date raised: 2023-02-22

  • 1.6.2 DOCU theDoc (#1460)

    • description: change structure: theory, notations earlier; remove duplicated MatrixContainer description

    • date resolved: 2023-03-12 16:20, date raised: 2023-03-12

  • 1.6.1 EXTENSION resolved by: P. Manzl artificialIntelligence nan test (#1458)

    • description: check for nan values in TestModel evaluation

    • notes: failed steps may lead to nan values when evaluating the TestModel in the artificialIntelligence module. When this is detected the flagNan is set and evaluation is stopped. Check for flagNan in the Evaluation should be implemented.

    • date resolved: 2023-03-10 15:59, date raised: 2023-03-10

  • 1.6.0 FIX cleanup howto files (#1426)

    • description: check if info is still valid (NGsolve, WSL, anaconda, …)

    • notes: removed outdated files

    • date resolved: 2023-03-08 16:58, date raised: 2023-02-11

Version 1.5

  • 1.5.118 DOCU julia (#1454)

    • description: add sub section on interoperability with julia in Overview on Exudyn / Advanced topics; add some relevant examples for usage

    • date resolved: 2023-03-05 16:40, date raised: 2023-03-05

  • 1.5.117 FIX __NOGLFW option not working (#1453)

    • description: exclude according functions in rendererPythonInterface

    • notes: added NOGLFW version to automatic build and testsuite

    • date resolved: 2023-02-28 15:18, date raised: 2023-02-28

  • 1.5.116 DOCU Single command (#1452)

    • description: add some more detailed description in theDoc after Visualization settings dialog

    • date resolved: 2023-02-26 00:40, date raised: 2023-02-26

  • 1.5.115 CHECK solver interface (#1451)

    • description: check modification of solver structures like it to be writable

    • notes: added now write functionality for solvers; use with care and only if you know what you do…

    • date resolved: 2023-02-26 00:12, date raised: 2023-02-25

  • 1.5.114 EXTENSION CSensorMarker (#1447)

    • description: add RotationMatrix as additional outputvariable type

    • notes: Coordinates also added as output variable

    • date resolved: 2023-02-24 15:46, date raised: 2023-02-23

  • 1.5.113 FIX CSensorMarker (#1446)

    • description: does not check types; Make GetOutputVariableTypes as in objects; orientation only for selected markers; check types in Assemble prechecks

    • date resolved: 2023-02-24 15:46, date raised: 2023-02-23

  • 1.5.112 BUG DOPRI5 (#1449)

    • description: small bug introduced in previous update: currentStepSize not updated any more

    • date resolved: 2023-02-24 15:45, date raised: 2023-02-24

  • 1.5.111 EXTENSION GenericJoint (#1448)

    • description: add experimental flag alternativeConstraints to switch to different constraint equations, e.g. for 3 constrained rotations; this resolves unphysical 180 degree flips especially in static cases; flag may be removed in future

    • notes: thanks for P. Manzl for raising this problem

    • date resolved: 2023-02-24 13:52, date raised: 2023-02-24

  • 1.5.110 DOCU sphinx/github pages (#1444)

    • description: fix equation references and figures

    • date resolved: 2023-02-24 13:50, date raised: 2023-02-22

  • 1.5.109 DOCU add readthedocs.io (#1442)

    • description: link github project to readthedocs.io site

    • date resolved: 2023-02-22 23:59, date raised: 2023-02-22

  • 1.5.108 DOCU sphinx/github pages (#1441)

    • description: add more parts on items (equations)

    • date resolved: 2023-02-22 23:57, date raised: 2023-02-22

  • 1.5.107 CHANGE resolved by: S. Holzinger ParameterVariation (#1440)

    • description: integer should be kept as integers, if they are provided as a list and if variation is only on integers

    • notes: integers are kept if either tuple(start, end, numberOfValues) with start/end and numberOfValues are all integer or list contains only integers

    • date resolved: 2023-02-22 13:46, date raised: 2023-02-22

  • 1.5.106 EXTENSION numpy dependency (#1439)

    • description: add install_requires to setup.py to force numpy to be installed; exudynCPP always requires now numpy

    • date resolved: 2023-02-21 18:11, date raised: 2023-02-21

  • 1.5.105 DOCU sphinx / github pages (#1438)

    • description: add input/output tables for items in RST files

    • date resolved: 2023-02-21 10:14, date raised: 2023-02-19

  • 1.5.104 DOCU sphinx / github pages (#1437)

    • description: add items to RST files/Sphinx to show up on github pages

    • date resolved: 2023-02-19 21:39, date raised: 2023-02-19

  • 1.5.103 DOCU sphinx / github pages (#1436)

    • description: add settings and structures; fix latex parts; fix links

    • date resolved: 2023-02-18 00:56, date raised: 2023-02-18

  • 1.5.102 BUG Lie group integration (#1433)

    • description: system with > 1 node raises LinkedDataVectorBases exception

    • date resolved: 2023-02-16 16:00, date raised: 2023-02-16

  • 1.5.101 FIX resolved by: P. Manzl artificialIntelligence module (#1432)

    • description: fix np.float64 not beeing detected as a scalar (float) for initializationValues of RL environment and possible waiting without activated renderer

    • date resolved: 2023-02-16 15:58, date raised: 2023-02-16

  • 1.5.100 EXTENSION make github pages (#1431)

    • description: install workflow for github pages to host pages for exudyn

    • notes: due to automatic conversion, there are many small errors (typos) remaining; for safety, check theDoc.pdf in any case

    • date resolved: 2023-02-16 00:01, date raised: 2023-02-16

  • 1.5.99 EXTENSION create rst docu files (#1430)

    • description: Create rst (markup language) files for C++ command interface and Python utilities

    • date resolved: 2023-02-16 00:00, date raised: 2023-02-15

  • 1.5.98 FIX revise docu creation (#1429)

    • description: revise several helper functions for docu creation to homogenize latex and rst output

    • date resolved: 2023-02-16 00:00, date raised: 2023-02-15

  • 1.5.97 CHANGE ParameterVariation (#1428)

    • description: add conversion of parameters which are numpy.float64 to float which simplifies checking agains type(float); computationIndex becomes int

    • date resolved: 2023-02-13 17:18, date raised: 2023-02-13

  • 1.5.96 EXTENSION IsReal(x) and IsInteger(x) (#1427)

    • description: add checks which allow to check versus any float / numpy.float resp. int / numpy.int values; added to advancedUtilities

    • date resolved: 2023-02-13 17:17, date raised: 2023-02-13

  • 1.5.95 EXTENSION sphinx (#1425)

    • description: add github pages at https://jgerstmayr.github.io/EXUDYN created with sphinx

    • date resolved: 2023-02-11 16:41, date raised: 2023-02-11

  • 1.5.94 CHANGE numerical Jacobians (#1423)

    • description: add variadic template to realize numerical differentiation for objects in a consistent way

    • date resolved: 2023-02-08 12:17, date raised: 2023-02-08

  • 1.5.93 FIX Lie group method (#1404)

    • description: add consistent numerical derivatives for Lie group nodes, needing the composition rule for incremental changes

    • date resolved: 2023-02-08 12:17, date raised: 2023-01-18

  • 1.5.92 CHANGE numerical Jacobians (#1422)

    • description: add variadic template to realize numerical differentiation in a consistent way

    • date resolved: 2023-02-08 00:16, date raised: 2023-02-07

  • 1.5.91 CHANGE LIE_GROUP_IMPLICIT_SOLVER (#1421)

    • description: remove preprocessor flag, as it is always set

    • date resolved: 2023-02-07 12:07, date raised: 2023-02-07

  • 1.5.90 EXTENSION setup.py (#1420)

    • description: reduce output of all compiler options with –quiet mode

    • date resolved: 2023-02-02 18:27, date raised: 2023-02-02

  • 1.5.89 EXTENSION window size (#1419)

    • description: window size currently limited to screen size and larger windows not accepted; override size limitations by using glfwSetWindowSize

    • notes: added flag window.limitWindowToScreenSize ; by default this is deactivated; added flag window.limitWindowToScreenSize ; by default this is deactivated; added flag window.limitWindowToScreenSize ; by default this is deactivated; added flag window.limitWindowToScreenSize ; by default this is deactivated; added flag window.limitWindowToScreenSize ; by default this is deactivated; added flag window.limitWindowToScreenSize ; by default this is deactivated

    • date resolved: 2023-02-02 10:31, date raised: 2023-02-02

  • 1.5.88 CHANGE OpenVR (#1418)

    • description: adapt projection for OpenVR compatibility; exchange multiplication of pose and eye to fulfill classic OpenGL needs

    • date resolved: 2023-02-01 10:30, date raised: 2023-02-01

  • 1.5.87 FIX ConnectorSpringDamperExt (#1417)

    • description: remove unintended output during Assemble()

    • date resolved: 2023-01-25 20:09, date raised: 2023-01-25

  • 1.5.86 EXTENSION AddDistanceSensor (#1405)

    • description: add rotation of Marker to ObjectGround in SensorUserFunction

    • notes: added option to draw displaced laser beam; rotation added, if rigid marker used

    • date resolved: 2023-01-23 10:05, date raised: 2023-01-19

  • 1.5.85 FIX AddDistanceSensor (#1416)

    • description: UFsensorDistance misses the rotation part in visualization of laser beam with ground object

    • date resolved: 2023-01-23 09:39, date raised: 2023-01-23

  • 1.5.84 CHANGE CoordinateSpringDamperExt (#1413)

    • description: change friction parameter dimensions to forces (because there is no normal force) and change parameter names

    • date resolved: 2023-01-22 23:43, date raised: 2023-01-21

  • 1.5.83 EXTENSION CoordinateSpringDamperExt (#1412)

    • description: finalize implementation for bristle friction model

    • date resolved: 2023-01-22 23:43, date raised: 2023-01-21

  • 1.5.82 EXTENSION CoordinateSpringDamperExt (#1411)

    • description: finalize implementation for limit stops

    • date resolved: 2023-01-22 23:43, date raised: 2023-01-21

  • 1.5.81 CHANGE examples (#1410)

    • description: adapt Examples/massSpringFrictionInteractive.py and Examples/lugreFrictionTest.py to new CoordinateSpringDamperExt

    • date resolved: 2023-01-21 22:04, date raised: 2023-01-21

  • 1.5.80 EXTENSION ConnectorsExt (#1136)

    • description: add extended Ext versions of connectors: CoordinateSpringDamperExt, TorsionalSpringDamperExt, LinearSpringDamperExt, which allow for friction, coordinate limitation (with other SD-values) and possibly future extensions

    • date resolved: 2023-01-21 21:29, date raised: 2022-06-10

  • 1.5.79 EXTENSION pause (#1407)

    • description: add option for pause by pressing space bar

    • date resolved: 2023-01-21 21:28, date raised: 2023-01-21

  • 1.5.78 CHANGE CoordinateSpringDamper (#1409)

    • description: remove dryFriction and dryFrictionProportionalZone; this functionality will be made available in CoordinateSpringDamperExt

    • notes: see CoordinateSpringDamper in theDoc.pdf how to convert old models using friction parameters to new ones; note user function interfaces have been changed!

    • date resolved: 2023-01-21 17:53, date raised: 2023-01-21

  • 1.5.77 EXTENSION WaitForUserToContinue (#1408)

    • description: add argument printMessage, which can be set false to avoid text output in console; default behavior preserved

    • date resolved: 2023-01-21 13:51, date raised: 2023-01-21

  • 1.5.76 EXTENSION git tags (#1406)

    • description: add git tags for every new version automatically

    • notes: now versions can be found easier in github and they match the version numbers in pypi with pip installer

    • date resolved: 2023-01-19 18:47, date raised: 2023-01-19

  • 1.5.75 CHECK Pybind11 (#1314)

    • description: test compilation with higher version of pybind11 (currently pybind11=2.6.0 in setup.py

    • notes: already done earlier; works well and allows compilation with Python3.11; added some switches in setup.py as not all Pybind11 versions work everywhere

    • date resolved: 2023-01-19 01:04, date raised: 2022-12-14

  • 1.5.74 EXAMPLE OpenVR (#1365)

    • description: add Python example with openVR

    • date resolved: 2023-01-19 01:02, date raised: 2023-01-03

  • 1.5.73 CHANGE OpenVR (#1326)

    • description: add OpenVR license and mention in getting started

    • date resolved: 2023-01-19 01:02, date raised: 2022-12-20

  • 1.5.72 EXTENSION openVR (#1402)

    • description: add flag to set compilation with openVR in setup.py; copy .dll in Windows case

    • date resolved: 2023-01-18 22:57, date raised: 2023-01-17

  • 1.5.71 EXTENSION resolved by: EXTENSION OpenVR (#1364)

    • description: test simple use case

    • notes: basic functionality added; enable compilation with openVR by setting ‘-D__EXUDYN_USE_OPENVR’ in cpp compiler flags of setup.py

    • date resolved: 2023-01-17 09:32, date raised: 2023-01-03

  • 1.5.70 EXTENSION lockModelView (#1401)

    • description: add flag which allows to fully lock rotation, zoom, etc.; in this case, only initial values in openGL settings are accepted for setup of view, but mouse or key input is ignored

    • date resolved: 2023-01-17 09:20, date raised: 2023-01-17

  • 1.5.69 CHECK test OpenVR with basic OpenGL (#1363)

    • description: check if current openGL is sufficient with textures

    • date resolved: 2023-01-16 23:11, date raised: 2023-01-03

  • 1.5.68 CHANGE renderState (#1400)

    • description: vectors and matrices are returned in numpy format; this allows simpler computation, but does not anymore allow to treat output as list (+ operator!)

    • date resolved: 2023-01-16 21:11, date raised: 2023-01-16

  • 1.5.67 CHANGE renderState (#1399)

    • description: initialization now done consistently for SC.AttachToRenderEngine() and exudyn.StartRenderer(); behavior should be as before

    • date resolved: 2023-01-16 21:10, date raised: 2023-01-16

  • 1.5.66 EXTENSION renderState (#1398)

    • description: add projectionMatrix containing the current projection usd (usually identity matrix)

    • date resolved: 2023-01-16 20:09, date raised: 2023-01-16

  • 1.5.65 FIX showFaceEdges, showMeshEdges (#1397)

    • description: wrong switching causing to show edges only if also some faces are activated

    • date resolved: 2023-01-12 22:32, date raised: 2023-01-12

  • 1.5.64 EXTENSION Get…Output (#1387)

    • description: add way to work for Reference configuration

    • notes: nodes, bodies and markers allow reference configuration; sensors also allow it for GetSensorValues

    • date resolved: 2023-01-12 22:14, date raised: 2023-01-12

  • 1.5.63 EXTENSION configuration checks (#1389)

    • description: check all systemData C++ interface functions regarding illegal configuration

    • date resolved: 2023-01-12 22:03, date raised: 2023-01-12

  • 1.5.62 EXTENSION configuration checks (#1388)

    • description: IsConfigurationInitialCurrentReferenceVisualization and IsConfigurationInitialCurrentVisualization shall be extended for StartOfStep; add hint that a calling function may have used an illegal configuration or None

    • date resolved: 2023-01-12 22:03, date raised: 2023-01-12

  • 1.5.61 EXTENSION Demo (#1396)

    • description: add a two demos included into the python module; put into exudyn.demos; add hint for larger examples; Demo1() = without graphics, just creating output file; Demo2() is rigid3Dexample with SolutionViewer

    • date resolved: 2023-01-12 18:51, date raised: 2023-01-12

  • 1.5.60 EXTENSION help (#1385)

    • description: add exudyn.help() function for short notes

    • date resolved: 2023-01-12 18:04, date raised: 2023-01-12

  • 1.5.59 BUG ComputeLinearizedSystem (#1390)

    • description: not working because of wrong interface to ComputeJacobianODE2RHS

    • date resolved: 2023-01-12 17:53, date raised: 2023-01-12

  • 1.5.58 TESTING eigenvalues test (#1394)

    • description: refine test model for ComputeODE2Eigenvalues

    • date resolved: 2023-01-12 17:44, date raised: 2023-01-12

  • 1.5.57 CHANGE ComputeJacobianAE (#1393)

    • description: change default values to fit to conventional tangential stiffness matrix computation

    • date resolved: 2023-01-12 17:00, date raised: 2023-01-12

  • 1.5.56 CHANGE ComputeJacobianODE1RHS (#1392)

    • description: change default values to fit to conventional tangential stiffness matrix computation

    • date resolved: 2023-01-12 17:00, date raised: 2023-01-12

  • 1.5.55 CHANGE ComputeJacobianODE2RHS (#1391)

    • description: change default values to fit to conventional tangential stiffness matrix computation

    • date resolved: 2023-01-12 17:00, date raised: 2023-01-12

  • 1.5.54 BUG GetMarkerOutput (#1386)

    • description: crashes if used with any configuration before Assemble(); add check that it may be only called after Assemble()

    • notes: add check and raise error

    • date resolved: 2023-01-12 14:15, date raised: 2023-01-12

  • 1.5.53 EXTENSION visualizationSettings (#1384)

    • description: add textOffsetFactor in general options to adjust text offset if not drawn always in front

    • notes: also adjusted some text appearance settings

    • date resolved: 2023-01-11 20:42, date raised: 2023-01-11

  • 1.5.52 DOCU visualizationSettings (#1383)

    • description: update docu of Visualization settings dialog in introduction

    • date resolved: 2023-01-11 17:41, date raised: 2023-01-11

  • 1.5.51 CHANGE visualizationSettings (#1382)

    • description: increase initial size of visualizations dialog for larger screens; see sec:overview:basics:visualizationsettings how to change to a smaller window size

    • date resolved: 2023-01-11 16:57, date raised: 2023-01-11

  • 1.5.50 CHANGE visualizationSettings (#1381)

    • description: change order of items to have easier access to each tree node

    • notes: dialogs.openTreeView=True can be used to switch to original behavior

    • date resolved: 2023-01-11 16:34, date raised: 2023-01-11

  • 1.5.49 CHANGE item text color (#1379)

    • description: draw colors in item texts (node numbers, etc.) different from item color to improve visibility

    • date resolved: 2023-01-11 16:28, date raised: 2023-01-11

  • 1.5.48 EXTENSION OpenGL texts (#1308)

    • description: add sub function for drawing text bitmaps; use different order of drawing for transparent and non-transparent triangles to get improved text drawing

    • notes: now having possibility to draw item texts in front or transparent

    • date resolved: 2023-01-11 16:28, date raised: 2022-12-08

  • 1.5.47 CHANGE loads (#1380)

    • description: draw load numbers at end of load vectors

    • notes: made Force consistent with Torque and LoadMassProportional

    • date resolved: 2023-01-11 14:43, date raised: 2023-01-11

  • 1.5.46 EXTENSION font drawing (#1378)

    • description: add visualizationSettings.general for textDrawInFront and textHasBackGround for having a (currently) white background color

    • date resolved: 2023-01-11 09:46, date raised: 2023-01-11

  • 1.5.45 CHANGE openvr (#1377)

    • description: not compatible right now with Exudyn under Windows while linux seems to work

    • date resolved: 2023-01-09 21:11, date raised: 2023-01-09

  • 1.5.44 EXTENSION advancedUtilities (#1370)

    • description: add advanced utilities depnding on numpy and math; functions not suitable for exudyn.basicUtilities or exudyn.utilities

    • date resolved: 2023-01-07 01:57, date raised: 2023-01-06

  • 1.5.43 EXTENSION initial accelerations (#1375)

    • description: add flag to decide whether initial accelerations are erased at beginning of simulation; the background is that they should not be erased, if they are prolonged for subsequent simulation; check if this changes behavior, as ODE2_tt coordinates are anyway resetted at Assemble()

    • date resolved: 2023-01-07 01:56, date raised: 2023-01-06

  • 1.5.42 CHANGE advancedUtilities (#1376)

    • description: move functions exudyn.utilities from to exudyn.advancedUtilities; still included in exudyn.utilities

    • date resolved: 2023-01-06 22:54, date raised: 2023-01-06

  • 1.5.41 BUG InteractiveDialog (#1374)

    • description: accelerations are not reused from last period; need to copy current accelerations into initial accelerations

    • date resolved: 2023-01-06 21:21, date raised: 2023-01-06

  • 1.5.40 CHANGE GraphicsData (#1373)

    • description: add option to add edges in GraphicsData…Cube… functions; switch some order of options

    • date resolved: 2023-01-06 19:25, date raised: 2023-01-06

  • 1.5.39 FIX utilities (#1372)

    • description: ComputeSkewMatrix: remove duplicate (with less functionality) from utilities and put into rigidBodyUtilities; correct import in FEM

    • date resolved: 2023-01-06 19:19, date raised: 2023-01-06

  • 1.5.38 CHANGE exudyn.utilities (#1371)

    • description: remove functions CheckInputVector and CheckInputIndexArray as they are unused and replaced with improved functions in advancedUtilities

    • date resolved: 2023-01-06 17:46, date raised: 2023-01-06

  • 1.5.37 EXTENSION add sub-module machines (#1369)

    • description: will include mechanical engineering and machine element relevant topics, such as bearings, gears, mechanisms, etc.

    • date resolved: 2023-01-06 11:47, date raised: 2023-01-06

  • 1.5.36 EXTENSION GraphicsDataCylinder (#1368)

    • description: new option to only add edges without faces

    • date resolved: 2023-01-05 23:03, date raised: 2023-01-05

  • 1.5.35 EXTENSION GraphicsDataSolidExtrusion (#1367)

    • description: add edges and normals for smoothening

    • date resolved: 2023-01-05 23:03, date raised: 2023-01-05

  • 1.5.34 EXTENSION GraphicsData (#1366)

    • description: add functionality for GraphicsDataSolidExtrusion to include circles: CirclePointsAndSegments() and to manipulate point lists defining geometries: SegmentsFromPoints()

    • date resolved: 2023-01-05 18:15, date raised: 2023-01-05

  • 1.5.33 EXTENSION add OpenVR interface (#1362)

    • description: add interface, but by default not compiled

    • date resolved: 2023-01-03 23:00, date raised: 2023-01-03

  • 1.5.32 EXTENSION Python 3.11 (#1361)

    • description: create first development wheels for Python 3.11; Windows+Linux

    • notes: problems to get conda with Python3.11 running, especially on ubuntu

    • date resolved: 2023-01-03 18:48, date raised: 2023-01-03

  • 1.5.31 EXTENSION Python 3.11 (#1360)

    • description: adjust setup.py to support Python 3.11; requires Pybind11 2.10

    • date resolved: 2023-01-03 14:37, date raised: 2023-01-03

  • 1.5.30 EXTENSION RollingDiscPenalty (#1335)

    • description: add test example for ground moving (rotating table

    • date resolved: 2023-01-02 19:07, date raised: 2022-12-25

  • 1.5.29 EXTENSION ObjectGround (#1359)

    • description: extend for referenceRotation to allow rotation of ground objects (especially for visualization and contact)

    • date resolved: 2023-01-02 11:49, date raised: 2023-01-02

  • 1.5.28 EXTENSION multithreaded jacobian (#839)

    • description: add functionality for multithreaded jacobian and mass matrix

    • notes: mass matrix resolved; other is redundant with #1203

    • date resolved: 2023-01-02 01:04, date raised: 2021-12-19

  • 1.5.27 EXTENSION MT integration2 (#828)

    • description: add multithreading to mass matrix and jacobian; add multithreaded adding of vector with special templated functions to allow special (templated) solver functions

    • notes: redundant with #839

    • date resolved: 2023-01-02 01:02, date raised: 2021-12-09

  • 1.5.26 EXTENSION test Eigen SimplicialLDLT (#791)

    • description: use systemMatricesArePD to enable LDLT solver

    • notes: tested earlier; does not work in most cases

    • date resolved: 2023-01-02 01:01, date raised: 2021-11-02

  • 1.5.25 CHANGE solvercontainer+ systemcontainer (#437)

    • description: remove SolverContainer and SystemContainer from systemStructuresDefinition and work manually

    • notes: already done much earlier

    • date resolved: 2023-01-02 00:59, date raised: 2020-07-21

  • 1.5.24 EXTENSION Add user object (#315)

    • description: add user object

    • notes: done with GenericODE2 and CoordinateVectorConstraint

    • date resolved: 2023-01-02 00:57, date raised: 2020-01-10

  • 1.5.23 EXTENSION MarkerDataJacobians (#261)

    • description: Add access functions for jacobians and other marker data: SetPositionJacobian, GetPositionJacobian, etc.; add jacobian types = markertypes, which check if wrong jacobian is accessed

    • notes: not suitable anymore

    • date resolved: 2023-01-02 00:56, date raised: 2019-09-11

  • 1.5.21 EXTENSION AVX2 (#1323)

    • description: update documentation for improved functionality with AVX2 code

    • notes: already done when resolving #1330

    • date resolved: 2023-01-02 00:50, date raised: 2022-12-17

  • 1.5.20 CHECK visualizationSettings (#1355)

    • description: check possibility for update loop to continue simulation

    • notes: not feasible now, as it requires to modify time integration loop

    • date resolved: 2023-01-02 00:48, date raised: 2022-12-31

  • 1.5.19 EXTENSION visualizationSettings (#1353)

    • description: add KEY Q shortcut to close dialog

    • date resolved: 2023-01-02 00:48, date raised: 2022-12-31

  • 1.5.18 CHANGE DictionariesGetSet (#1358)

    • description: add new types VectorFloat and MatrixFloat in order to distinguish from double values

    • notes: also fixed matrix conversion in visualizationSettings

    • date resolved: 2023-01-02 00:47, date raised: 2023-01-02

  • 1.5.17 EXTENSION visualizationSettings (#1357)

    • description: add single click edit event

    • date resolved: 2023-01-01 23:27, date raised: 2023-01-01

  • 1.5.16 EXTENSION visualizationSettings (#1354)

    • description: double click on bool variables changes state

    • date resolved: 2023-01-01 23:22, date raised: 2022-12-31

  • 1.5.15 FIX tkinter dialogs (#1352)

    • description: add option for transparency to dialogs

    • notes: visualizationSettings.dialogs.transparency

    • date resolved: 2022-12-31 11:01, date raised: 2022-12-31

  • 1.5.14 FIX tkinter MacOS (#1351)

    • description: adjust font size and row size in ttk right mouse dialog

    • notes: visualizationSettings.dialogs.fontScalingMacOS

    • date resolved: 2022-12-31 11:00, date raised: 2022-12-31

  • 1.5.13 FIX tkinter MacOS (#1350)

    • description: adjust font size and row size in ttk visualizationSettings dialog

    • notes: visualizationSettings.dialogs.fontScalingMacOS

    • date resolved: 2022-12-31 11:00, date raised: 2022-12-31

  • 1.5.12 BUG tkinter MacOS (#752)

    • description: tkinter fails when loaded inside interactive.py; early call to Tk() inside an example works and seems to help; check options to correctly load tkinter in MacOS (Rosetta 2, on M1)

    • notes: problem fixed with single threaded renderer, doing illegal operations in glfw callbacks

    • date resolved: 2022-12-31 01:01, date raised: 2021-09-20

  • 1.5.11 FIX RequireVersion (#1349)

    • description: some bugs including exu.GetVersionString and not raising exception

    • date resolved: 2022-12-30 15:03, date raised: 2022-12-30

  • 1.5.10 DOCU tkinter in exudyn (#1343)

    • description: add comment in FAQ on potential problems with tkinter; add option to let exudyn know if tkinter is already running

    • date resolved: 2022-12-28 23:39, date raised: 2022-12-27

  • 1.5.9 EXTENSION visualizationSettings (#1347)

    • description: add flag visualizationSettings.dialog.multiThreadedDialogs to turn on/off immediate apply of visualizationSettings changes; extend exudyn.GUI and rendererPythonInterface.h accordingly

    • notes: NOTE that this flag should be turned off in case of crashes during/after dialogs; could make problems on special platforms such as MacOS

    • date resolved: 2022-12-28 23:05, date raised: 2022-12-28

  • 1.5.8 CHANGE EditDictionaryWithTypeInfo (#1348)

    • description: change interface to pass directly visualizationSettings, allowing to update data

    • date resolved: 2022-12-28 21:50, date raised: 2022-12-28

  • 1.5.7 CHECK visualizationSettings (#1346)

    • description: check if visualiuation settings dialog can be installed such that updating of data immediately affects renderer window

    • date resolved: 2022-12-28 16:53, date raised: 2022-12-28

  • 1.5.6 FIX tkinter MacOS (#1339)

    • description: add tkinter.Tk() into exudyn.sys[“tkinterRoot”] before call to StartRenderer(); check for tkinterRoot in exudyn.sys on startup of interactive dialog; resolves crash on MacOS for SolutionViewer

    • date resolved: 2022-12-27 23:50, date raised: 2022-12-26

  • 1.5.5 FIX interface default args (#1345)

    • description: change true/false to True/False in theDoc for PYthon command interface

    • date resolved: 2022-12-27 23:24, date raised: 2022-12-27

  • 1.5.4 EXTENSION exudyn (#1344)

    • description: add function IsRendererRunning(), to avoid Warnings when renderer is restarted

    • date resolved: 2022-12-27 23:23, date raised: 2022-12-27

  • 1.5.3 FIX MacOS (#1338)

    • description: DoRendererIdleTasks() crashes if no Renderer is active; add check in python call to avoid crash

    • notes: crash resolved on Windows; MacOS test still open

    • date resolved: 2022-12-27 17:36, date raised: 2022-12-26

  • 1.5.2 CHANGE MacOS multithreading (#1340)

    • description: activate simplified multithreading by switching to TinyThreading in case of MacOS

    • date resolved: 2022-12-27 17:19, date raised: 2022-12-26

  • 1.5.1 EXTENSION MacOS M1 (#1342)

    • description: add string ARM to Platform string, e.g., used in solution and sensor files

    • date resolved: 2022-12-27 17:03, date raised: 2022-12-27

  • 1.5.0 FIX test suite (#1336)

    • description: resolve linux problem with RigidBodySpringDamper.py MiniExample

    • notes: problem in testsuite due to AVX differences, causing all non-AVX cases to fail (also linux); fixed with special case in reference solutions

    • date resolved: 2022-12-25 20:10, date raised: 2022-12-25

Version 1.4

  • 1.4.65 EXTENSION RollingDiscPenalty (#1264)

    • description: correct torque on ground, which currently has no effect, but will be used for moving ground

    • notes: resolved earlier

    • date resolved: 2022-12-25 12:15, date raised: 2022-09-17

  • 1.4.64 TESTING ReevingSystemLinear (#1298)

    • description: add test model to test suite

    • date resolved: 2022-12-25 12:11, date raised: 2022-12-01

  • 1.4.63 CHANGE gcc linux (#1333)

    • description: adjust -march compilation options for improved performance on linux; try -march=skylake for AVX2 optimization

    • notes: did not work: either gives compilation errors or segmentation faults

    • date resolved: 2022-12-25 00:45, date raised: 2022-12-24

  • 1.4.62 CHANGE NOGLFW (#1334)

    • description: remove SystemContainer constructor warning for AttachToRenderEngine in case of NOGLFW

    • notes: also done for DetachFromRenderEngine

    • date resolved: 2022-12-25 00:06, date raised: 2022-12-25

  • 1.4.61 FIX MacOS (#1332)

    • description: compilation does not finish due to -framework Cocoa, etc. errors

    • notes: changed -framework library lists by separating commands into two separate strings; compilation now runs through for Python 3.8-3.10 on MacOS with M1 and 3.7.-3.10 on _x86 emulation

    • date resolved: 2022-12-24 22:20, date raised: 2022-12-24

  • 1.4.60 FIX AVX2 (#1330)

    • description: fix check for AVX and AVX2 on module import

    • date resolved: 2022-12-21 19:33, date raised: 2022-12-21

  • 1.4.59 EXAMPLE SolutionViewer (#1329)

    • description: add example for SolutionViewer with multiple static simulations performed, writing results into single file; see Examples/solutionViewerMultipleSimulations.py

    • date resolved: 2022-12-21 18:05, date raised: 2022-12-21

  • 1.4.58 EXTENSION simulationSettings.solutionSettings (#1328)

    • description: add option writeInitialValues in order to turn on/off writing of initial values for coordinatesSolution and sensors; by default turned on as was done so far

    • date resolved: 2022-12-21 14:07, date raised: 2022-12-21

  • 1.4.57 EXTENSION sensor files (#1037)

    • description: add file footer information same as in coordinatesSolutionFile including CPUtimeElapsed with 3 digits

    • notes: turned on by default, but should be switched off if it causes compatibility problems for your postprocessing tool

    • date resolved: 2022-12-21 12:09, date raised: 2022-04-07

  • 1.4.56 FIX sensorsWriteFileHeader (#1327)

    • description: not working

    • notes: added option into solver, now turning on/off as desired; added option into solver, now turning on/off as desired; added option into solver, now turning on/off as desired

    • date resolved: 2022-12-21 12:06, date raised: 2022-12-21

  • 1.4.55 EXAMPLE DistanceSensor (#1317)

    • description: Add example with distance sensor

    • date resolved: 2022-12-20 13:49, date raised: 2022-12-16

  • 1.4.54 EXTENSION DistanceSensor (#1318)

    • description: Add measurement for GeneralContact trigsRigidBody

    • date resolved: 2022-12-19 21:49, date raised: 2022-12-16

  • 1.4.53 EXTENSION DistanceSensor (#1316)

    • description: add utilities function to create DistanceSensor based on general contact

    • notes: added AddDistanceSensor to exudyn utilities.py

    • date resolved: 2022-12-19 01:09, date raised: 2022-12-16

  • 1.4.52 EXTENSION DistanceSensor (#1324)

    • description: utilities function AddDistanceSensor extended for measureVelocity to measure velocity similar as in a laser Doppler vibrometer (LDV)

    • date resolved: 2022-12-18 20:59, date raised: 2022-12-18

  • 1.4.51 EXTENSION GeneralContact (#1320)

    • description: add binary contact types to pybind interface; add conversion of binary types to type indices

    • notes: only TypeIndex added which is sufficient for DistanceSensor

    • date resolved: 2022-12-17 00:32, date raised: 2022-12-16

  • 1.4.50 EXTENSION DistanceSensor (#1319)

    • description: Add radius for option to measure with cylinder with given radius instead of line; useful for particles

    • date resolved: 2022-12-17 00:32, date raised: 2022-12-16

  • 1.4.49 EXTENSION DistanceSensor (#1321)

    • description: Add option to select which contact types are considered

    • date resolved: 2022-12-17 00:31, date raised: 2022-12-16

  • 1.4.48 EXTENSION AVX2 import (#1322)

    • description: add checks based on numpy.core._multiarray_umath to find if CPU has AVX2 support; in release, user may directly import noAVX version by setting sys.exudynCPUhasAVX2=False

    • date resolved: 2022-12-16 23:42, date raised: 2022-12-16

  • 1.4.47 BUG SetSearchTreeBox (#1315)

    • description: has no effect, and searchTree is always computed automatically

    • notes: now search tree can be initialized smaller or larger than initial geometry in order to optimize for specific problem

    • date resolved: 2022-12-15 21:20, date raised: 2022-12-15

  • 1.4.46 EXTENSION DistanceSensor (#1268)

    • description: add simple distance sensor

    • notes: can be realized with GeneralContact and SensorUserFunction

    • date resolved: 2022-12-15 20:23, date raised: 2022-09-21

  • 1.4.45 EXTENSION GeneralContact (#1271)

    • description: Add interface functions for GeneralContact: allowing to measure distance along a line; get markers/spheres in box; get beams in box; etc.

    • date resolved: 2022-12-15 20:20, date raised: 2022-09-21

  • 1.4.44 EXTENSION AVX2 (#1313)

    • description: add additional library without AVX and use try/except to import exudynCPPnoAVX in case that AVX2 is not available

    • date resolved: 2022-12-14 20:27, date raised: 2022-12-14

  • 1.4.43 EXTENSION SolveDynamic (#1312)

    • description: add flag computeMassMatrixInversePerBody for explicit time integration to compute mass matrix inverse per body; read theDoc and use with care!

    • notes: check your models! ComputeMassMatrix has been adapted for every body!!!

    • date resolved: 2022-12-13 21:00, date raised: 2022-12-13

  • 1.4.42 FIX DynamicSolver (#1311)

    • description: include flag timeIntegration.reuseConstantMassMatrix into explicit solver; up to now, this option was always turned on

    • date resolved: 2022-12-13 18:51, date raised: 2022-12-13

  • 1.4.41 FIX searchTreeUpdateCounter (#1310)

    • description: needs reset to 0 after reaching limit

    • date resolved: 2022-12-13 17:58, date raised: 2022-12-13

  • 1.4.40 EXTENSION GeneralContact searchtree (#847)

    • description: add options to recompute searchtree size if particles are moving out of region; add option to flush all dynamical arrays (searchtree, allActiveContacts, etc.) after certain time

    • notes: added option resetSearchTreeInterval into GeneralContact settings

    • date resolved: 2022-12-12 10:40, date raised: 2021-12-23

  • 1.4.39 EXTENSION rigidBodyUtilities (#1309)

    • description: AddRigidBody: add default argument for nodeType as RotationEulerParameters; simplifies creation of rigid bodies

    • date resolved: 2022-12-08 18:16, date raised: 2022-12-08

  • 1.4.38 FIX GL_POLYGON_OFFSET_FILL (#1302)

    • description: correct polygon offset setting for regular faces/lines and add adjustable parameter in visualizationSettings

    • date resolved: 2022-12-08 01:50, date raised: 2022-12-06

  • 1.4.37 CHANGE OpenGL (#1307)

    • description: change line and polygon drawing in order to avoid line artifacts; newly introduced polygon offset may cause problems: check your visualization, send reports if problems and set polygonOffset=0 in severe cases

    • date resolved: 2022-12-08 01:06, date raised: 2022-12-08

  • 1.4.36 DOCU ConnectorRollingDiscPenalty (#1304)

    • description: extend docu for arbitrary planeNormal and moving ground

    • date resolved: 2022-12-07 21:57, date raised: 2022-12-07

  • 1.4.35 EXTENSION ObjectJointRollingDisc (#1306)

    • description: add discAxis to object parameters, being able to change from default x-axis

    • date resolved: 2022-12-07 20:18, date raised: 2022-12-07

  • 1.4.34 CHANGE ObjectJointRollingDisc (#1305)

    • description: change computation of trail, generalized for two bodies moving relative to each other (needs further testing)

    • date resolved: 2022-12-07 20:18, date raised: 2022-12-07

  • 1.4.33 EXTENSION ConnectorRollingDiscPenalty (#1303)

    • description: extended formulation for arbitrary planeNormal; ground body can now also move in space (testing needed)

    • date resolved: 2022-12-07 17:49, date raised: 2022-12-07

  • 1.4.32 FIX graphicsDataUtilities (#1301)

    • description: AddEdgesAndSmoothenNormals fixed to process colors

    • date resolved: 2022-12-06 12:37, date raised: 2022-12-06

  • 1.4.31 EXTENSION graphicsDataUtilities (#1300)

    • description: GraphicsDataFromPointsAndTrigs extended to accept color per point or 4 RGBA values

    • date resolved: 2022-12-06 12:37, date raised: 2022-12-06

  • 1.4.30 BUG GeneralContact (#1299)

    • description: searchTreeBox not computed automatically (must be set manually)

    • notes: computation of searchtree performed automatically now if no search tree box is specified; output message written in case of verboseMode=1

    • date resolved: 2022-12-02 12:51, date raised: 2022-12-02

  • 1.4.29 EXTENSION ConnectorSpringDamper (#1297)

    • description: return scalar spring-damper force with OutputVariableType ForceLocal

    • date resolved: 2022-12-01 16:31, date raised: 2022-12-01

  • 1.4.28 CHECK dynamic solver (#1296)

    • description: add check that useIndex2=True is consistent with useNewmark=True

    • date resolved: 2022-11-30 14:12, date raised: 2022-11-29

  • 1.4.27 EXTENSION ReevingSystemSprings (#925)

    • description: create reeving system along points defined by markers, using massless springs and one total length; add rigid body markers for position of sheaves; use coordinate markers for prescribed change of length at end of reeving system

    • notes: see new ObjectConnectorReevingSystemSprings

    • date resolved: 2022-11-19 01:11, date raised: 2022-02-03

  • 1.4.26 EXTENSION BeamGeometricallyExact2D (#1295)

    • description: add damping terms for bending, axial and shear deformation

    • date resolved: 2022-11-17 15:59, date raised: 2022-11-17

  • 1.4.25 EXTENSION BeamGeometricallyExact2D (#1294)

    • description: add reference strain/curvature

    • date resolved: 2022-11-17 15:59, date raised: 2022-11-17

  • 1.4.24 EXTENSION MarkerDataStructure (#1293)

    • description: extend for more than 2 MarkerData; adjust caller functions

    • date resolved: 2022-11-13 16:53, date raised: 2022-11-13

  • 1.4.23 FIX Lie Group integration (#1291)

    • description: CompositionRule in LieGroup nodes does not consider reference position; add reference configuration in composition rule (and subtract afterwards)

    • date resolved: 2022-11-09 15:00, date raised: 2022-11-09

  • 1.4.22 BUG visualizationSettings (#1289)

    • description: interactive.trackMarker has wrong type leading to crash when closing visualizationSettings

    • date resolved: 2022-11-05 14:15, date raised: 2022-11-05

  • 1.4.21 FIX trackMarker (#1286)

    • description: selection of objects wrong / check mouse selection procedure

    • date resolved: 2022-11-04 20:46, date raised: 2022-11-02

  • 1.4.20 EXTENSION ConnectorRollingDiscPenalty (#1288)

    • description: add useLinearProportionalZone which performs better in implicit time integration

    • date resolved: 2022-11-04 17:16, date raised: 2022-11-04

  • 1.4.19 EXTENSION ConnectorRollingDiscPenalty (#1287)

    • description: add viscousFriction, using separate values for local X/Y coordinates

    • date resolved: 2022-11-04 17:16, date raised: 2022-11-04

  • 1.4.18 EXTENSION Renderer: marker tracking (#1276)

    • description: add option to track markers in renderer

    • notes: see visualizationSettings.interactive for several trackMarker… options

    • date resolved: 2022-11-02 17:13, date raised: 2022-10-12

  • 1.4.17 CHANGE release_assert (#1279)

    • description: remove all asserts (in automatic code generation)

    • date resolved: 2022-11-02 17:10, date raised: 2022-10-13

  • 1.4.16 FIX Lobatto, LobattoIntegrate (#1285)

    • description: order nomenclature is wrong. Lobatto2 needs to be renamed into Lobatto1 and so on

    • date resolved: 2022-11-02 16:43, date raised: 2022-11-02

  • 1.4.15 EXTENSION extend ALEANCF beam (#1284)

    • description: add effects due to axial and bending viscous damping in case of movingMassFactor==1

    • notes: new damping terms for axially moving beams implemented according to 2022 Paper of Pieber, Ntarladima, Gerstmayr only for case movingMassFactor=1

    • date resolved: 2022-10-31 15:43, date raised: 2022-10-25

  • 1.4.14 BUG ProcessParameterList (#1283)

    • description: in case useMultiProcessing=False the output file does not contain correct ranges

    • date resolved: 2022-10-20 21:59, date raised: 2022-10-20

  • 1.4.13 EXTENSION PlotSensor (#1282)

    • description: added return value including [plt, fig, ax, line] to be used for subsequent operations

    • date resolved: 2022-10-19 20:30, date raised: 2022-10-19

  • 1.4.12 EXTENSION results monitor (#1281)

    • description: extend results monitor for viewing more detailed results of ParameterVariation with colorVariations option; add function SingleIndex2SubIndices

    • date resolved: 2022-10-17 07:30, date raised: 2022-10-17

  • 1.4.11 BUG ParameterVariation (#1280)

    • description: resultsFile not working (problem with ProcessParameterList

    • date resolved: 2022-10-14 08:22, date raised: 2022-10-14

  • 1.4.10 FIX center point (#1278)

    • description: add key O to change center of rotation; resolve finally original issue 1155

    • date resolved: 2022-10-12 22:37, date raised: 2022-10-12

  • 1.4.9 CHANGE shadowPolygonOffset (#1277)

    • description: decrease default value from 10 to 0.1; adjust in your models

    • date resolved: 2022-10-12 20:27, date raised: 2022-10-12

  • 1.4.8 EXTENSION GetMarkerOutput (#1275)

    • description: add function mbs.GetMarkerOutput() to return position, velocitiy, rotation matrix and angular velocity for markers if available

    • date resolved: 2022-10-12 09:18, date raised: 2022-10-12

  • 1.4.7 BUG ALECable2D (#1274)

    • description: missing term L in preComputedB terms in C++ implementation

    • date resolved: 2022-09-25 14:17, date raised: 2022-09-25

  • 1.4.6 CHANGE Beam3D (#1242)

    • description: rename ANCFBeam3D to ANCFBeam and GeometricallyExactBeam3D in same way for consistency reasons

    • date resolved: 2022-09-24 19:35, date raised: 2022-08-24

  • 1.4.5 FIX RollingDisc (#1265)

    • description: correct description of coordinate systems in RollingDisc and RollingDiscPenalty; remove wrong transposed sign

    • date resolved: 2022-09-19 17:46, date raised: 2022-09-19

  • 1.4.4 EXTENSION RollingDiscPenalty (#1263)

    • description: add arbitrary local wheel axis (discAxis) instead of x-axis only

    • date resolved: 2022-09-17 10:42, date raised: 2022-09-17

  • 1.4.3 EXTENSION RigidBodyInertia (#1262)

    • description: add += operator

    • date resolved: 2022-09-17 08:23, date raised: 2022-09-17

  • 1.4.2 EXTENSION Lie group integration (#1261)

    • description: improve implicit Lie group integration, adapt old rotation vector approach, add tangent operator

    • date resolved: 2022-09-16 18:14, date raised: 2022-09-16

  • 1.4.1 BUG MacOS (#1260)

    • description: compilation not working on MacOS with taskmanager adaptions

    • date resolved: 2022-09-15 11:14, date raised: 2022-09-15

  • 1.4.0 EXTENSION SparseVectorDomain (#860)

    • description: ?NEEDED (see 0862): create templated SparseVector with IndexValue+domain, having C-array of ResizableArray<IndexValue>, used for multithreaded creation of sparse vectors, associated indices for lateron fill into system vectors

    • notes: done in TemporaryComputationData now

    • date resolved: 2022-09-15 08:50, date raised: 2022-01-13

Version 1.3

  • 1.3.105 EXTENSION SparseVectorParallel (#861)

    • description: create SparseVector with: mainSparseVector + ArrayIndex2 with per-thread max index and current index; SparseTriplets exceeding the index go into ResizableArray<SparseVector*> threadSparseVector; Function to finally fill all triplets into main vector

    • notes: done in TemporaryComputationData now

    • date resolved: 2022-09-15 08:49, date raised: 2022-01-13

  • 1.3.104 EXTENSION MarkerSuperElementRigid (#1259)

    • description: extend offset for case that it is large

    • date resolved: 2022-09-14 15:18, date raised: 2022-09-14

  • 1.3.103 EXTENSION AnimateModes (#1258)

    • description: add option to change sign of mode

    • date resolved: 2022-09-14 08:51, date raised: 2022-09-14

  • 1.3.102 BUG AnimateModes (#1257)

    • description: button for “Faces only” not working due to new way edges are turned on / off; workaround by pressing T in render window

    • notes: buttons now affect the mesh faces / edges instead of regular edges / faces

    • date resolved: 2022-09-14 08:28, date raised: 2022-09-13

  • 1.3.101 EXTENSION GUI (#1256)

    • description: added some variables in exudyn.GUI which may be used to adjust appearance of dialogs, specifically for extreme display scaling

    • date resolved: 2022-09-13 16:42, date raised: 2022-09-13

  • 1.3.100 EXTENSION use display scaling in GUI (#1252)

    • description: use display scaling in visualizationSettings, etc.

    • date resolved: 2022-09-13 16:42, date raised: 2022-09-13

  • 1.3.99 CHANGE tkinter (#1255)

    • description: put root calls into try-except clause in order to preserve operation on special systems like MacOS or Linux

    • date resolved: 2022-09-13 14:49, date raised: 2022-09-13

  • 1.3.98 EXTENSION SolutionViewer, AnimateModes (#1254)

    • description: add font size and title; this allows to scale fonts as monitor scaling is not active here

    • date resolved: 2022-09-13 14:13, date raised: 2022-09-13

  • 1.3.97 DOCU renderState (#1253)

    • description: add description into theDoc, in section 3D graphics visualization

    • date resolved: 2022-09-13 11:12, date raised: 2022-09-13

  • 1.3.96 CHANGE useWindowsDisplayScaleFactor (#1251)

    • description: changed visualizationsSettings.general option name from useWindowsMonitorScaleFactor to useWindowsDisplayScaleFactor

    • date resolved: 2022-09-13 10:33, date raised: 2022-09-13

  • 1.3.95 EXTENSION displayScaling (#538)

    • description: add displayScaling to renderState and use this value for GUI.py in visualizationSettings

    • notes: added displayScaling and automatic updating when Windows display scaling is changed or window is moved to other display

    • date resolved: 2022-09-13 10:19, date raised: 2021-01-06

  • 1.3.94 EXTENSION FEM HurtyCraigBampton (#1250)

    • description: ComputeHurtyCraigBamptonModes now includes option to compute RBE3 case; adds optional boundary node weights

    • date resolved: 2022-09-07 12:33, date raised: 2022-09-06

  • 1.3.93 EXTENSION FEM interface (#1249)

    • description: add function GetNodeWeightsFromSurfaceAreas which computes correct weights for linear finite elements (tested for tetrahedrals); this weighting can now reduce erroneous offset in MarkerSuperElementRigid significantly; also used for RBE3 mode computation

    • date resolved: 2022-09-07 12:33, date raised: 2022-09-06

  • 1.3.92 FIX AddObjectFFRFreducedOrderWithUserFunctions (#1248)

    • description: wrong description of user functions; add missing itemIndex in description

    • date resolved: 2022-09-05 18:39, date raised: 2022-09-05

  • 1.3.91 EXTENSION DrawSystemGraph (#1246)

    • description: add option to create multi-line graphs; improving appearance and readability

    • date resolved: 2022-09-02 09:05, date raised: 2022-09-02

  • 1.3.90 EXTENSION pre-compiled linux (#1244)

    • description: add all Python 3.6 - 3.10 linux 64 bit versions to pypi with pip installer

    • date resolved: 2022-09-01 10:02, date raised: 2022-08-25

  • 1.3.89 EXTENSION Gen alpha Lie (#562)

    • description: add Lie groups to new generalized alpha integrator

    • date resolved: 2022-08-26 14:09, date raised: 2021-01-26

  • 1.3.88 CHANGE Rotation output variable (#1245)

    • description: changed/fixed OutputVariableType.Rotation for NodeRigidBodyRotVecLG to output Tait-Bryan rotations instead of rotation parameters; corrected description for NodeRigidBodyRxyz: returns rotation parameters directly, NOT recomputed from RotationMatrix

    • date resolved: 2022-08-26 10:25, date raised: 2022-08-26

  • 1.3.87 EXTENSION raised by: S. Holzinger resolved by: S. Holzinger Lie group integration (#1243)

    • description: add new functions for implicit Lie group integration (FIRST TESTS)

    • date resolved: 2022-08-24 17:13, date raised: 2022-08-24

  • 1.3.86 BUG Timer registration (#1239)

    • description: self-registration of Timers fails on Linux and may lead to crashes; depends on order of initialization of global variables

    • notes: changed timer registration to suggested way with scalar variables, guaranteeing initialization

    • date resolved: 2022-08-24 15:10, date raised: 2022-08-24

  • 1.3.85 BUG Linux TestSuite (#1225)

    • description: segmentation fault when running ANCFgeneralContactCircle.py

    • date resolved: 2022-08-24 09:13, date raised: 2022-08-11

  • 1.3.84 CHANGE visualization dialog (#1238)

    • description: resort options, such that contour options are on top

    • date resolved: 2022-08-23 15:19, date raised: 2022-08-23

  • 1.3.83 EXTENSION Beams (#1237)

    • description: add option for drawing filled cross-sections (or alternatively wire frames)

    • date resolved: 2022-08-23 15:19, date raised: 2022-08-23

  • 1.3.82 FIX GeometricallyExactBeam (#1236)

    • description: GeometricallyExactBeam2D and GeometricallyExactBeam3D do not show values in contour plot

    • date resolved: 2022-08-23 14:15, date raised: 2022-08-23

  • 1.3.81 FIX GeometricallyExactBeam2D (#1235)

    • description: add missing output variables (strain, curvatureLocal, forces,torques)

    • date resolved: 2022-08-23 12:02, date raised: 2022-08-23

  • 1.3.80 BUG KinematicTree (#1233)

    • description: Jacobian in KinematicTree has too many approximations: either missing velocity terms have large influence or double entries for connectors on single KinematicTree; check stiffFlyballGovernor w/o systemWideDifferentiation

    • notes: fixed JacobianODE2 for duplicate global indices, e.g., in case that Connector is attached with two markers to same object (kinematic tree)

    • date resolved: 2022-08-23 11:41, date raised: 2022-08-22

  • 1.3.79 EXTENSION Newton / Jacobian (#1234)

    • description: add new Newton / numericalDifferentiation setting jacobianConnectorDerivative for faster Jacobian computations

    • date resolved: 2022-08-23 10:15, date raised: 2022-08-23

  • 1.3.78 CHECK KinematicTree (#1224)

    • description: visulization problems with kinematicTreeConstraintTest.py with 10 links and more; may be caused by wrong states in visualization or possible bug in KinematicTreeMarker

    • notes: resolved with issue 1232 by adding additional temporary variables for visualization

    • date resolved: 2022-08-22 23:26, date raised: 2022-08-07

  • 1.3.77 BUG KinematicTree (#1232)

    • description: visualization of joints uses illegal temporary data; leads to data race and erroneous results

    • date resolved: 2022-08-22 23:23, date raised: 2022-08-22

  • 1.3.76 BUG BasicDefinitions (#1231)

    • description: C++: definition of MAXREAL wrong; affects searchtree and contact

    • date resolved: 2022-08-22 21:33, date raised: 2022-08-22

  • 1.3.75 CHANGE GetInitialVector (#1230)

    • description: change GetInitialVector into GetInitialCoordinateVector for consistency reasons; samge for GetInitialVector_t, SetInitialVector, SetInitialVector_t

    • date resolved: 2022-08-17 17:53, date raised: 2022-08-17

  • 1.3.74 BUG CMarkerBodyCable2DShape (#1229)

    • description: system error due to incorrect initialization of matrix

    • date resolved: 2022-08-15 15:31, date raised: 2022-08-15

  • 1.3.73 EXTENSION add LieGroup node with data coordinates (#1228)

    • description: add special Lie group node for implicit integration, containing the start-of-step configuration in data coordinates and additionally use regular ODE2 coordinates for the incremental motion

    • date resolved: 2022-08-12 19:35, date raised: 2022-08-12

  • 1.3.72 CHANGE CNode.cpp (#1227)

    • description: C++: remove exceptions for illegal index access in GetCurrentCoordinate(…)

    • date resolved: 2022-08-12 19:18, date raised: 2022-08-12

  • 1.3.71 EXTENSION initial coordinates (#1226)

    • description: C++: nodes get a separate SetInitialCoordinateVector() function; used for special nodes with mixed coordinates

    • date resolved: 2022-08-12 19:17, date raised: 2022-08-12

  • 1.3.70 EXTENSION KinematicTree (#1115)

    • description: C++ implement efficient T66 transformations

    • notes: stable implementation, with formulas different to Featherstone formulas, but in line with 6D matrix manipulations; further tests and documentation needed

    • date resolved: 2022-08-07 22:55, date raised: 2022-05-29

  • 1.3.69 BUG T66MotionInverse (#1223)

    • description: C++: RigidBodyMath implementation of T66 inverse is wrong, could affect special KinematicTree force reaction

    • date resolved: 2022-08-05 21:45, date raised: 2022-08-05

  • 1.3.68 CHANGE KinematicTree (#1222)

    • description: remove some temporary variables from interface as new efficient transformations cannot be converted to Python easily

    • date resolved: 2022-08-04 16:28, date raised: 2022-08-04

  • 1.3.67 CHANGE Transformations66List (#1221)

    • description: C++: rename into Transformation66List

    • date resolved: 2022-08-04 16:27, date raised: 2022-08-04

  • 1.3.66 EXTENSION PlotImage (#1220)

    • description: add options for orthogonal projection and removing axes and background

    • date resolved: 2022-07-26 09:34, date raised: 2022-07-26

  • 1.3.65 CHECK LinkedDataVectorParallel (#1205)

    • description: C++: check if LinkedDataVector can obtain performance mode from ResizableVectorParallel

    • date resolved: 2022-07-22 20:45, date raised: 2022-07-12

  • 1.3.64 EXTENSION parallel (#1206)

    • description: C++: parallelize important vector-vector and matrix-vector (MultMatrix, MultAdd, …) operations with optional commands

    • notes: already done in ResizableVectorParallel, but extensions in LinkedDataVector needed

    • date resolved: 2022-07-22 19:49, date raised: 2022-07-12

  • 1.3.63 EXTENSION SolverExplicit (#1218)

    • description: parallelize Lie group updates in explicit solver

    • date resolved: 2022-07-22 19:26, date raised: 2022-07-22

  • 1.3.62 CHANGE SolverExplicit (#1219)

    • description: turn off Lie group integration if no Lie group nodes available

    • date resolved: 2022-07-22 18:15, date raised: 2022-07-22

  • 1.3.61 CHANGE numpy arrays (#1160)

    • description: change conversion behavior for Vector3D and Matrix3D, automatically transformed into numpy arrays instead of std::vector which gives a list right now

    • notes: for items containing VectorXD or MatrixXD, the parameter returned in GetObject() and similar functions is now giving numpy arrays; for system structures, this is anyway already implemented; specifically, the changed behaviour can be used for referenceCoordinates in user functions; BEHAVIOUR CHANGED: check your models!

    • date resolved: 2022-07-21 19:33, date raised: 2022-06-26

  • 1.3.60 EXTENSION parallel (#1209)

    • description: C++: add multithreaded parallelization for PostNewton

    • date resolved: 2022-07-21 10:02, date raised: 2022-07-14

  • 1.3.59 CHANGE TestModels (#1035)

    • description: change modelUnitTests imports in TestModels such that they also work in case that example is run outside TestModels directory

    • notes: done earlier

    • date resolved: 2022-07-20 14:33, date raised: 2022-04-07

  • 1.3.58 TESTING TestSuite (#1016)

    • description: add example of reeving system

    • notes: done earlier

    • date resolved: 2022-07-20 14:33, date raised: 2022-03-28

  • 1.3.57 EXTENSION GraphicsData (#1217)

    • description: add functions for drawing text, line and circle: GraphicsDataLine, GraphicsDataText, GraphicsDataCircle

    • date resolved: 2022-07-20 09:45, date raised: 2022-07-20

  • 1.3.56 BUG renderer: Circle (#1216)

    • description: circles drawn wrongly, not closed for circleTiling <= 6 and producing overly many lines

    • date resolved: 2022-07-19 20:11, date raised: 2022-07-19

  • 1.3.55 EXTENSION Export lines (#1214)

    • description: add option to export all lines from renderer similar to RenderImage, however, just exporting the raw line information (2 points, RGBA color)

    • date resolved: 2022-07-19 18:39, date raised: 2022-07-19

  • 1.3.54 FIX GraphicsData addEdges (#1215)

    • description: some examples still in a previous state expecting wrong GraphicsData format

    • date resolved: 2022-07-19 12:14, date raised: 2022-07-19

  • 1.3.53 BUG mbs.systemData.Info() (#1213)

    • description: mbs.systemData.Info() gives error for KinematicTree

    • date resolved: 2022-07-15 15:34, date raised: 2022-07-15

  • 1.3.52 FIX DynamicSolverType::RK67 (#1212)

    • description: shows DynamicSolverType::invalid

    • date resolved: 2022-07-15 15:00, date raised: 2022-07-15

  • 1.3.51 EXTENSION PlotSensor (#1211)

    • description: add listMarkerStyles and listMarkerStylesFilled to exudyn.plot for use in loops

    • date resolved: 2022-07-15 09:28, date raised: 2022-07-15

  • 1.3.50 CHECK microThread (#1210)

    • description: check if threading can be optimized by only using sync atomic variables

    • notes: no big improvement found, also using bit-wise thread communication and saving some atomic operations

    • date resolved: 2022-07-14 20:40, date raised: 2022-07-14

  • 1.3.49 EXTENSION timer PostNewton (#1208)

    • description: add timer for PostNewtonStep

    • date resolved: 2022-07-14 00:15, date raised: 2022-07-14

  • 1.3.48 EXTENSION microThreading (#1207)

    • description: add micro threading library which already takes effect for small systems (10-20 3D rigid bodies); currently included with separate compile option in BasicDefinitions.h

    • date resolved: 2022-07-13 13:43, date raised: 2022-07-13

  • 1.3.47 TESTING adjust testSuite (#1199)

    • description: due to change of state vector to ResizableVectorParallel with AVX arithmetic, minor changes in reference solutions happened

    • date resolved: 2022-07-12 17:06, date raised: 2022-07-11

  • 1.3.46 EXTENSION SparseSolver analyzePattern (#1193)

    • description: add option to reuse result of analyzePattern() for successive computations; especially in time integration, using the number of non-zeros as indicator is something has changed; add some initializationFunctions to reset, especially after non-convergence

    • date resolved: 2022-07-12 17:06, date raised: 2022-07-10

  • 1.3.45 EXTENSION parallel / multithreaded (#1204)

    • description: C++: add multithreading for AlgebraicEquations

    • date resolved: 2022-07-12 15:03, date raised: 2022-07-12

  • 1.3.44 EXTENSION parallel / multithreaded (#1201)

    • description: C++: add multithreading for ProjectedReactionForces

    • date resolved: 2022-07-12 13:04, date raised: 2022-07-12

  • 1.3.43 CHANGE CSystem::Jacobians (#1200)

    • description: C++: removed single flags for jacobians and replaced by JacobianType; check your results (bugs may happen)

    • date resolved: 2022-07-12 10:55, date raised: 2022-07-12

  • 1.3.42 EXTENSION parallel MassMatrix (#1198)

    • description: use multithreading to compute mass matrix; treat objects with user functions separately

    • date resolved: 2022-07-11 23:18, date raised: 2022-07-11

  • 1.3.41 BUG ResizableArray (#1197)

    • description: C++: copy of illegal parts of memory when enlarging array

    • date resolved: 2022-07-11 22:58, date raised: 2022-07-11

  • 1.3.40 CHANGE remove openmp (#1195)

    • description: remove openmp compile options from setup.py as it is not used for now

    • date resolved: 2022-07-11 19:02, date raised: 2022-07-11

  • 1.3.39 CHANGE SystemState (#1191)

    • description: C++: replace Vector state with ResizableVector(Parallel)

    • date resolved: 2022-07-10 14:50, date raised: 2022-07-10

  • 1.3.38 EXTENSION ALEANCFCable2D (#1186)

    • description: add missing terms related to curvature and strain coupling with delta qALE

    • date resolved: 2022-07-09 21:25, date raised: 2022-07-06

  • 1.3.37 EXTENSION ContactFrictionCircleCable2D (#1190)

    • description: now adapted to work in general with ALECable2D, however, only for tangential frictionStiffness=0

    • date resolved: 2022-07-09 14:33, date raised: 2022-07-09

  • 1.3.36 BUG beam.py (#1188)

    • description: missing eii structure before Point2DS1

    • date resolved: 2022-07-08 16:22, date raised: 2022-07-08

  • 1.3.35 EXTENSION ContactFrictionCircleCable2D (#1185)

    • description: add ALE term to marker and contact element

    • date resolved: 2022-07-06 15:30, date raised: 2022-07-06

  • 1.3.34 CHANGE star imports (#1183)

    • description: remove * imports from all .py modules except utilities.py

    • notes: also fixed some undetected bugs in unused functions in exudyn.* utilities

    • date resolved: 2022-07-06 11:56, date raised: 2022-07-06

  • 1.3.33 CHANGE exudyn.utilities (#1184)

    • description: remove import of time and copy; needs to be included separately into models

    • notes: check your models!

    • date resolved: 2022-07-06 11:55, date raised: 2022-07-06

  • 1.3.32 CHANGE roboticsCore.py (#1182)

    • description: remove * import of many exudyn packages

    • date resolved: 2022-07-06 10:58, date raised: 2022-07-06

  • 1.3.31 CHANGE setup.py (#1181)

    • description: due to deprecation warning, use namespace_packages instead of packages in setup(…); remove include_package_data=True

    • date resolved: 2022-07-06 09:43, date raised: 2022-07-06

  • 1.3.30 EXTENSION ObjectContactFrictionCircleCable2D (#954)

    • description: Add exception in PreAssembleChecks if marker is not a MarkerBody, as implementation only works for MarkerBody but not for MarkerNode

    • notes: resolved, as now a MarkerNodeRigid may also be used

    • date resolved: 2022-07-05 21:18, date raised: 2022-02-27

  • 1.3.29 EXTENSION AddEdgesAndSmoothenNormals (#1180)

    • description: specialized function for STL file enhancement

    • date resolved: 2022-07-05 20:51, date raised: 2022-07-05

  • 1.3.28 EXTENSION show lines (#1179)

    • description: add separate visualization.openGL flag for showing/hiding lines

    • date resolved: 2022-07-05 11:20, date raised: 2022-07-05

  • 1.3.27 EXTENSION STL import/export (#1178)

    • description: add option to invert triangles and/or normls on import or export of STL meshes

    • date resolved: 2022-07-05 08:38, date raised: 2022-07-05

  • 1.3.26 EXTENSION selection right mouse (#1177)

    • description: now also showing GraphicsData optionally with visualizationSettings.interactive.selectionRightMouseGraphicsData

    • date resolved: 2022-07-05 08:38, date raised: 2022-07-05

  • 1.3.25 EXTENSION TriangleList (#1099)

    • description: extend GraphicsData TriangleList with two optional lists (which may be empty) containing edges (tuples of point numbers) as well as edgeColors; allows to easily add edges to graphics representation

    • date resolved: 2022-07-05 00:04, date raised: 2022-05-22

  • 1.3.24 EXTENSION mbs.GetObject (#1174)

    • description: add option to receive graphicsData (or not)

    • notes: default behavior kept same, not returning graphicsData in dict

    • date resolved: 2022-07-04 23:59, date raised: 2022-07-04

  • 1.3.23 EXTENSION BodyGraphicsData (#1159)

    • description: add method to convert bodyGraphicsData into dictionary; add flag to GetObject to by default not show graphicsData

    • date resolved: 2022-07-04 23:59, date raised: 2022-06-26

  • 1.3.22 CHANGE GraphicsDataCylinder…() (#1176)

    • description: returns always a GraphicsData dictionary, independently of addEdges is True or False

    • date resolved: 2022-07-04 23:33, date raised: 2022-07-04

  • 1.3.21 CHANGE GraphicsDataOrthoCube…() (#1175)

    • description: returns always a GraphicsData dictionary, independently of adding edges or not

    • date resolved: 2022-07-04 23:33, date raised: 2022-07-04

  • 1.3.20 EXTENSION conversion to STL (#1169)

    • description: add function to convert graphicsData triangle meshes into STL; allows import into other tools

    • date resolved: 2022-07-04 20:55, date raised: 2022-07-03

  • 1.3.19 EXTENSION include numpy-stl (#821)

    • description: include library to import stl files; add Warning to GraphicsDataFromSTLfileTxt for large file sizes and check if is ascii; in binary case, try switching to numpy-stl; add example to load binary files; add example to convert stl ascii to binary files

    • notes: example for stl import added: Examples/stlFileImport.py

    • date resolved: 2022-07-04 20:55, date raised: 2021-12-06

  • 1.3.18 CHANGE GetObjectOutputBody (#1173)

    • description: add default argument localPosition=[0,0,0]

    • date resolved: 2022-07-04 11:45, date raised: 2022-07-04

  • 1.3.17 CHANGE GetObjectOutput (#1172)

    • description: include configurationType in interface (default: Current); not available in connectors; add objectNumber in C++ interface

    • date resolved: 2022-07-04 11:43, date raised: 2022-07-04

  • 1.3.16 BUG MarkerKinematicTreeRigid (#1171)

    • description: incorrect GetPosition, GetVelocity, GetAngularVelocity, …

    • date resolved: 2022-07-04 11:43, date raised: 2022-07-03

  • 1.3.15 CHANGE KinematicTree (#1161)

    • description: change GetObjectOutputBody to GetObjectOutput as localPosition does not make sense here

    • date resolved: 2022-07-04 11:39, date raised: 2022-06-27

  • 1.3.14 EXTENSION MarkerKinematicTreeRigid (#1170)

    • description: add visualization

    • date resolved: 2022-07-03 20:23, date raised: 2022-07-03

  • 1.3.13 CHANGE left mouse (#1168)

    • description: deactivate mouse select if renderer is showing mouse coordinates (and doing measuring)

    • date resolved: 2022-07-02 11:29, date raised: 2022-07-02

  • 1.3.12 EXTENSION InteractiveDialog (#1166)

    • description: In all interactive dialogs, especially the SolutionViewer now stopping the render window (with Q or Escape) also stops the interactive dialog; behavior changed with checkRenderEngineStopFlag

    • date resolved: 2022-06-29 10:15, date raised: 2022-06-29

  • 1.3.11 CHANGE class Robot (#1165)

    • description: drawing of cylinder for first body in robot removed; this part must be drawn manually at base (or not drawn)

    • date resolved: 2022-06-29 10:02, date raised: 2022-06-29

  • 1.3.10 EXTENSION AddObjectFFRFreducedOrder (#720)

    • description: add gravity as with user functions version, similar to AddRigidBody

    • date resolved: 2022-06-29 09:27, date raised: 2021-07-12

  • 1.3.9 CHANGE MacOS (#1018)

    • description: adjust mouse scroll factor in case of Apple/Mac OS compilation (e.g. multiply with 0.05 by default)

    • notes: changed way to compute zoomFactor for larger yOffsets in scroll callback

    • date resolved: 2022-06-28 15:30, date raised: 2022-03-29

  • 1.3.8 FIX OpenGL shadow (#1164)

    • description: resolve issues with shadows drawing of many objects; added _WRAP to stencil INCR and DECR operations to resolve overflows

    • date resolved: 2022-06-27 19:20, date raised: 2022-06-27

  • 1.3.7 FIX OpenGL normals (#1163)

    • description: correct orientation of triangles and normals in GraphicsData functions

    • date resolved: 2022-06-27 16:22, date raised: 2022-06-27

  • 1.3.6 CHANGE OpenGL normals (#1162)

    • description: correct normals in GraphicsDataSphere, GraphicsDataCylinder and GraphicsDataSolidOfRevolution to point outwards; turn off GL_LIGHT_MODEL_TWO_SIDE by default

    • date resolved: 2022-06-27 14:12, date raised: 2022-06-27

  • 1.3.5 EXTENSION RigidBodyInertia (#1158)

    • description: add Transformed() function to return rigid body inertia transformed by homogeneous transformation; used in class Robot for certain transformations of link frame

    • date resolved: 2022-06-27 01:20, date raised: 2022-06-26

  • 1.3.4 EXTENSION class Robot (#1072)

    • description: extend KinematicTree export in order to be able to create robots with localHT!=HT0()

    • date resolved: 2022-06-27 00:41, date raised: 2022-05-06

  • 1.3.3 EXTENSION class Robot (#1131)

    • description: add list of graphicsDataLists to each body for individual graphics of links allowing also graphics for tools

    • date resolved: 2022-06-26 23:46, date raised: 2022-06-03

  • 1.3.2 DOCU add links to other github repos (#1094)

    • description: link more directly to ngsolve and openAI / stable_baslines3 / etc.; refer to openAI in github links and add ref to theDoc.pdf ; add example/teaser?

    • date resolved: 2022-06-24 09:20, date raised: 2022-05-21

  • 1.3.1 TESTING C++ user functions (#1157)

    • description: check if linking C++ user functions directly boosts performance

    • notes: C++ functions are translated by including pybind11/functional.h; workaround would be two user functions, one without MainSystem and without including functional.h; C++ functions could then be compiled in a very simple manner

    • date resolved: 2022-06-23 16:57, date raised: 2022-06-23

  • 1.3.0 BUG single threaded renderer (#677)

    • description: correct crash with visualization dialog (MacOS)

    • notes: not resolved, but it is an issue of missing tkinter capabilities in MacOS

    • date resolved: 2022-06-22 07:59, date raised: 2021-05-12

Version 1.2

  • 1.2.146 CHECK parallel build (#735)

    • description: check parallel build with MSbuild to reduce compilation times

    • notes: already done earlier

    • date resolved: 2022-06-22 07:58, date raised: 2021-08-12

  • 1.2.145 EXTENSION RaspberryPi (#863)

    • description: check compilation on Raspi, make adaptation of ngsolve includes to run

    • notes: already done earlier

    • date resolved: 2022-06-22 07:48, date raised: 2022-01-14

  • 1.2.144 EXTENSION MarkerBodyCable2DShape (#968)

    • description: add offset from beam axis, to compute position, velocity and jacobians at contact surface

    • notes: already done earlier

    • date resolved: 2022-06-22 07:46, date raised: 2022-03-03

  • 1.2.143 DOCU ContactFrictionCircleCable2D (#972)

    • description: add / extend description

    • date resolved: 2022-06-22 07:44, date raised: 2022-03-09

  • 1.2.142 EXTENSION center point (#1155)

    • description: add key “o” option to set center point to current center point of view; this allows to rotate around the current center point of the view

    • notes: currently deactivated due to transformation of coordinates issue

    • date resolved: 2022-06-21 18:16, date raised: 2022-06-21

  • 1.2.141 EXTENSION Renderer (#1152)

    • description: add separate function to compute accurate scene size, store as 3D vector and as norm

    • date resolved: 2022-06-21 17:56, date raised: 2022-06-20

  • 1.2.140 CHANGE Zoom all (#1154)

    • description: change procedures for zoom all and for computation of maximum scene coordinates; may affect appearance of your models; necessary for consistently computing perspective and shadow parameters

    • date resolved: 2022-06-21 08:38, date raised: 2022-06-21

  • 1.2.139 CHECK noglfw (#1153)

    • description: check compilation without GLFW

    • date resolved: 2022-06-20 10:58, date raised: 2022-06-20

  • 1.2.138 EXTENSION OpenGL (#1150)

    • description: add shadows (simple)

    • notes: activate with SC.VisualizationSettings().openGL.shadow, chosing a value between 0. and 1; good results obtained with 0.5

    • date resolved: 2022-06-20 01:49, date raised: 2022-06-18

  • 1.2.137 CHANGE linux builds (#1151)

    • description: remove -g flag from linux builds, leading to 2.6MB instead of 38MB binaries; to enable debug information (e.g. to detect origin of some crashes, remove the -g0 flag in setup.py)

    • date resolved: 2022-06-19 18:34, date raised: 2022-06-19

  • 1.2.136 EXTENSION OpenGL (#1149)

    • description: add perspective

    • notes: added openGL option perspective; EXPERIMENTAL!

    • date resolved: 2022-06-19 01:59, date raised: 2022-06-18

  • 1.2.135 FIX jacobian ODE1 ODE2 (#1148)

    • description: fix jacobian computations for mixed ODE1-ODE2 components; check with HydraulicActuatorSimple (lower number of jacobians and iterations)

    • date resolved: 2022-06-18 23:38, date raised: 2022-06-18

  • 1.2.134 EXTENSION ODE1Coordinates_t (#1147)

    • description: add missing function SetODE1Coordinates_t and GetODE1Coordinates_t into Python interface

    • date resolved: 2022-06-17 01:14, date raised: 2022-06-17

  • 1.2.133 EXAMPLE hydraulics (#1096)

    • description: add hydraulic actuator with new element HydraulicActuatorSimple

    • date resolved: 2022-06-17 00:06, date raised: 2022-05-22

  • 1.2.132 EXTENSION solver jacobians (#1146)

    • description: extended jacobians for ODE1 and ODE2 residuals for ODE1-ODE2 coupling in ComputeJacobianODE2RHS, ComputeJacobianODE1RHS, and ComputeJacobianAE; changed default values as well; check your code if you used these functions in Python user functions

    • date resolved: 2022-06-16 19:35, date raised: 2022-06-16

  • 1.2.131 EXTENSION static solver (#1145)

    • description: add check if system contains ODE1 variables

    • date resolved: 2022-06-16 18:52, date raised: 2022-06-16

  • 1.2.130 EXTENSION PlotSensor (#1144)

    • description: added option to allow components=[plot.componentNorm] for displaying norm of sensors

    • date resolved: 2022-06-16 17:32, date raised: 2022-06-16

  • 1.2.129 EXAMPLE numba jit (#1143)

    • description: add example for numba jit speedup of Python user functions

    • notes: added Example springDamperUserFunctionNumbaJIT.py showing speedup of 4 for simple Python function; note that mbs functions cannot be processed by numba

    • date resolved: 2022-06-16 17:01, date raised: 2022-06-16

  • 1.2.128 EXTENSION HydraulicsActuator (#1106)

    • description: add HydraulicsActuator as object, containing pressure equations

    • notes: added new double acting HydraulicActuatorSimple with internal pressure equations and possibility to modify valves by user functions

    • date resolved: 2022-06-16 12:00, date raised: 2022-05-23

  • 1.2.127 EXTENSION artificialIntelligence (#1138)

    • description: OpenAIGymInterfaceEnv obtained additional member variable randomInitializationValue which may be adapted; in future, this may be done in a separate function

    • date resolved: 2022-06-10 12:26, date raised: 2022-06-10

  • 1.2.126 CHANGE exudynFast (#1137)

    • description: for linux builds, do not activate exudynFast, only for noglfw

    • date resolved: 2022-06-10 12:16, date raised: 2022-06-10

  • 1.2.125 BUG KinematicTree (#1135)

    • description: linux version of KinematicTree gives significantly (6e-7) different results, check initialization

    • notes: resulted due to high sensitivity to disturbances (1e-15), especially in acceleration sensors, and ONLY for mbs results!

    • date resolved: 2022-06-09 20:32, date raised: 2022-06-09

  • 1.2.124 EXTENSION KinematicTree (#1134)

    • description: add Jacobian computation according to class Robot in order to realize AccessFunction needed from MarkerKinematicTreeRigid; uses special access function because the SuperElement interface does not provide link number

    • date resolved: 2022-06-08 18:30, date raised: 2022-06-06

  • 1.2.123 EXTENSION KinematicTree (#1071)

    • description: add special MarkerKinematicTreeRigidBody with link number and local position

    • date resolved: 2022-06-08 18:30, date raised: 2022-05-05

  • 1.2.122 CHANGE class Robot (#1130)

    • description: tool only working for serial robots; in case of tree structure, tool should not be used as it is attached only to last link

    • notes: added warning to class Robot.AddLink(…) which raises Warning if tool is defined and tree structure is generated

    • date resolved: 2022-06-06 00:32, date raised: 2022-06-03

  • 1.2.121 EXTENSION class Robot (#1132)

    • description: extend Jacobian, LinkHT and JointHT functions for tree structure; check StaticTorques

    • notes: added comparison for class Robot functions in kinematicTreeAndMBStest.py

    • date resolved: 2022-06-06 00:31, date raised: 2022-06-03

  • 1.2.120 EXTENSION SolutionViewer (#1133)

    • description: bind additional Button “Q” in interactive dialogs for quit (in addition to Escape)

    • date resolved: 2022-06-05 18:25, date raised: 2022-06-05

  • 1.2.119 TESTING class Robot (#1114)

    • description: create new example(s) comparing CreateKinematicTree and CreateRedundantCoordinateMBS with control and prismatic joints

    • date resolved: 2022-06-05 14:33, date raised: 2022-05-29

  • 1.2.118 BUG class Robot (#1127)

    • description: CreateKinematicTree not working for tree structure

    • date resolved: 2022-06-03 00:28, date raised: 2022-06-03

  • 1.2.117 BUG class Robot (#1129)

    • description: GetParentIndex(…), HasParent(…) not working for tree structure

    • date resolved: 2022-06-03 00:19, date raised: 2022-06-03

  • 1.2.116 BUG class Robot (#1128)

    • description: CreateRedundantCoordinateMBS not working for tree structure

    • date resolved: 2022-06-03 00:19, date raised: 2022-06-03

  • 1.2.115 BUG KinematicTree (#1126)

    • description: wrong formula in computation of acceleration

    • date resolved: 2022-06-02 22:41, date raised: 2022-06-02

  • 1.2.114 EXTENSION class Robot (#1123)

    • description: extend CreateRedundantCoordinateMBS for jointSpringDamperUserFunctionList with prismatic joints

    • date resolved: 2022-06-01 23:44, date raised: 2022-06-01

  • 1.2.113 EXTENSION class Robot (#1125)

    • description: extend CreateRedundantCoordinateMBS for control of PrsimaticJoints with new LinearSpringDamper

    • date resolved: 2022-06-01 23:43, date raised: 2022-06-01

  • 1.2.112 EXTENSION LinearSpringDamper (#1124)

    • description: add LinearSpringDamper which is the corresponding spring damper/actuator for prismatic joints (like TorsionalSpringDamper for revolute joints), being aligned with a rigid marker, having no limits compared to regular (distance based) SpringDamper

    • date resolved: 2022-06-01 23:43, date raised: 2022-06-01

  • 1.2.111 EXTENSION serialrobot (#503)

    • description: adapt serial robot for prismatic joints

    • notes: functionality with Prismatic joints now included into class Robot, converting to mbs with CreateRedundantCoordinateMBS or CreateKinematicTree, see issue

    • date resolved: 2022-06-01 20:38, date raised: 2020-12-16

  • 1.2.110 CHANGE AnimateSolution (#1121)

    • description: mark as deprecated, use SolutionViewer instead

    • date resolved: 2022-06-01 20:25, date raised: 2022-05-31

  • 1.2.109 BUG GraphicsDataBasis (#1122)

    • description: kwargs argument radius not working

    • date resolved: 2022-05-31 15:32, date raised: 2022-05-31

  • 1.2.108 CHECK KinematicTree (#1108)

    • description: check OutputVariable functions and compare with redundant-MBS based bodies

    • date resolved: 2022-05-30 21:06, date raised: 2022-05-27

  • 1.2.107 EXAMPLE hydraulics (#1095)

    • description: add hydraulic actuator with user function

    • notes: example HydraulicsUserFunction.py added already 5 days earlier

    • date resolved: 2022-05-30 20:06, date raised: 2022-05-22

  • 1.2.106 EXTENSION class Robot (#1109)

    • description: CreateRedundantCoordinateMBS: jointLoadUserFunctionList and createJointTorqueLoads marked as deprecated; use NEW jointSpringDamperUserFunctionList which allows to directly actuate at revolute/prismatic joints

    • date resolved: 2022-05-30 20:05, date raised: 2022-05-29

  • 1.2.105 BUG KinematicTree (#1120)

    • description: composite inertia contains wrong index in calculation

    • date resolved: 2022-05-30 20:04, date raised: 2022-05-30

  • 1.2.104 TESTING KinematicTree (#1113)

    • description: test for prismatic joint

    • date resolved: 2022-05-30 20:04, date raised: 2022-05-29

  • 1.2.103 BUG KinematicTree (#1119)

    • description: wrong signs (missing inverse) of prismatic joints in C++ and Python implementation of KinematicTree

    • date resolved: 2022-05-30 17:55, date raised: 2022-05-30

  • 1.2.102 BUG ObjectKinematicTree (#1118)

    • description: conversion to dict in mbs.GetObject(…) does not work for Matrix3D

    • date resolved: 2022-05-30 16:02, date raised: 2022-05-30

  • 1.2.101 CHANGE Python3.8 (#1117)

    • description: the exudyn version for Python3.8 now includes range checks (and is slower than before); for fast version of exudyn without range checks, check issues 1116 and section ‘Performance and ways to speed up computations’ in theDoc

    • date resolved: 2022-05-30 00:34, date raised: 2022-05-30

  • 1.2.100 EXTENSION exudynFast (#1116)

    • description: add separate track for fast exudyn versions; the compiler flag _FAST_EXUDYN_LINALG, previously only activated in Python 3.8, is now used for Python 3.7 and Python 3.8 versions ONLY if according import flags are set by doing the following 3 steps: import sys; sys.exudynFast=True; import exudyn

    • date resolved: 2022-05-30 00:34, date raised: 2022-05-29

  • 1.2.99 CHANGE class Robot (#1112)

    • description: CreateKinematicTree: jointForceVector, jointPositionOffsetVector, jointVelocityOffsetVector, jointPControlVector, jointDControlVector removed and replaced by PDcontrol structure in RobotLink; forceUserFunction kept as is; return value slightly changed

    • date resolved: 2022-05-29 19:10, date raised: 2022-05-29

  • 1.2.98 EXTENSION class Robot (#1111)

    • description: RobotLink adds feature to define PDcontrol, used in robots for joint control of link

    • date resolved: 2022-05-29 19:10, date raised: 2022-05-29

  • 1.2.97 EXTENSION class Robot (#1110)

    • description: CreateRedundantCoordinateMBS: returns additional list springDamperList, which contains more efficient spring dampers for joint control

    • date resolved: 2022-05-29 17:05, date raised: 2022-05-29

  • 1.2.96 EXTENSION KinematicTree (#1070)

    • description: add SensorSuperElement (BUT call it SensorKinematicTree!) functionality for Position, Velocity, Acceleration, RotationMatrix, AngularVelocity, …

    • notes: created new SensorKinematicTree; tests not done yet

    • date resolved: 2022-05-27 23:43, date raised: 2022-05-05

  • 1.2.95 CHANGE Sensors (#1107)

    • description: C++: move sensor-specific consistency tests from CSystem to CheckPreAssembleConsistency

    • date resolved: 2022-05-27 23:41, date raised: 2022-05-26

  • 1.2.94 EXTENSION Object (#1103)

    • description: C++: enable objects to be mixed of ODE2, ODE1 and AE variables (most general case); add jacobian_ODE1ODE2 flags and functions in case of ODE1

    • notes: NumericalJacobianODE1RHS modified accordingly

    • date resolved: 2022-05-23 23:06, date raised: 2022-05-23

  • 1.2.93 EXAMPLE HydraulicActuator (#1101)

    • description: add HydraulicActuator with user function example

    • notes: Duplicate of issue 1102

    • date resolved: 2022-05-23 22:10, date raised: 2022-05-23

  • 1.2.92 EXTENSION NodeGenericAE (#1105)

    • description: add node with algebraic variables

    • date resolved: 2022-05-23 22:02, date raised: 2022-05-23

  • 1.2.91 EXTENSION GetNodeODE1Index, GetNodeAEIndex (#850)

    • description: add missing access functions

    • date resolved: 2022-05-23 21:48, date raised: 2022-01-08

  • 1.2.90 EXAMPLE HydraulicActuator (#1102)

    • description: add HydraulicActuator with user function example

    • notes: Examples/HydraulicsUserFunction.py

    • date resolved: 2022-05-23 19:53, date raised: 2022-05-23

  • 1.2.89 EXTENSION GraphicsDataCylinder (#1098)

    • description: add option addEdges which in addition returns GraphicsData for edges; returns then list of dictionaries

    • date resolved: 2022-05-22 20:54, date raised: 2022-05-22

  • 1.2.88 EXTENSION GraphicsDataOrthoCubePoint (#1097)

    • description: add option addEdges which in addition returns GraphicsData for edges; returns then list of dictionaries

    • date resolved: 2022-05-22 20:54, date raised: 2022-05-22

  • 1.2.87 BUG ANCFBeam3D (#1093)

    • description: giving wrong results because of error in template<class TMatrix> ConstSizeMatrixBase& operator+= (const TMatrix& matrix); leading to twice the mass matrix

    • date resolved: 2022-05-20 16:07, date raised: 2022-05-20

  • 1.2.86 EXTENSION openAI gym (#1092)

    • description: add example for interface with openAI gym using cart-pole model

    • notes: see Examples/testGymCartpole.py

    • date resolved: 2022-05-18 09:47, date raised: 2022-05-18

  • 1.2.85 BUG ComputeODE2Eigenvalues (#1091)

    • description: eigenvectors sorting is not according to eigenvalues sorting

    • date resolved: 2022-05-17 10:00, date raised: 2022-05-17

  • 1.2.84 EXTENSION ComputeODE2Eigenvalues (#1090)

    • description: solver.ComputeODE2Eigenvalues gets additional flag constrainedCoordinates to specify list of constrained coordinates in system for eigenvalue computation

    • date resolved: 2022-05-16 23:01, date raised: 2022-05-16

  • 1.2.83 BUG ComputeODE2Eigenvalues (#1089)

    • description: setInitialValues has no effect

    • notes: flag erased

    • date resolved: 2022-05-16 22:03, date raised: 2022-05-16

  • 1.2.82 BUG ParameterVariation (#1086)

    • description: numberOfThreads cannot be passed to parameter variation as it is duplicated by **args

    • notes: numberOfThreads is now a named argument

    • date resolved: 2022-05-16 16:34, date raised: 2022-05-16

  • 1.2.81 EXTENSION Beam drawing (#1079)

    • description: add generic drawing function for beams, especially for contour plot

    • date resolved: 2022-05-15 23:24, date raised: 2022-05-09

  • 1.2.80 EXTENSION ANCFBeam3D (#1076)

    • description: add shear deformable 3D ANCF beam according to Nachbagauer Gerstmayr Pechstein using structural mechanics formulation

    • date resolved: 2022-05-15 23:24, date raised: 2022-05-06

  • 1.2.79 CHECK linux testSuite (#1081)

    • description: check failed tests under linux; see tests for 1.2.75 linux

    • notes: resolved issues related to initial accelerations; still deviation in test generalContactFrictionTests.py

    • date resolved: 2022-05-11 18:54, date raised: 2022-05-11

  • 1.2.78 BUG node frame drawing (#1084)

    • description: node frames shows letter N unintended

    • date resolved: 2022-05-11 18:23, date raised: 2022-05-11

  • 1.2.77 BUG initial accelerations (#1083)

    • description: not correctly handled in linux build (and probably also on MacOS

    • date resolved: 2022-05-11 16:18, date raised: 2022-05-11

  • 1.2.76 EXTENSION testsuite linux (#1082)

    • description: extend test suite to run always for linux and add file ending for linux and MacOS

    • date resolved: 2022-05-11 12:51, date raised: 2022-05-11

  • 1.2.75 BUG gcc compile (#1080)

    • description: errors when compiling PyVectorLists and PyMatrixLists on gcc

    • date resolved: 2022-05-11 09:27, date raised: 2022-05-11

  • 1.2.74 EXTENSION geometrically exact beam3D (#471)

    • description: add to CPP

    • notes: added first version based on conventional parameterization of nodes, but using Lie groups for beam section forces in ode2LHS

    • date resolved: 2022-05-09 21:24, date raised: 2020-11-21

  • 1.2.73 CHANGE TExpSO3(Omega) (#1077)

    • description: reduce number of terms in termExpanded; only up to x**4 needed for 16 digits

    • date resolved: 2022-05-09 21:22, date raised: 2022-05-07

  • 1.2.72 EXTENSION BeamSection (#1074)

    • description: add new structure (cpp+Python) for beam cross section as well as BeamSectionGeometry for geometrical representation

    • date resolved: 2022-05-09 21:22, date raised: 2022-05-06

  • 1.2.71 EXTENSION structures description (#1073)

    • description: add description for simulationSettings, visualizationSettings, solver structures, etc. in Python bindings

    • date resolved: 2022-05-06 13:54, date raised: 2022-05-06

  • 1.2.70 EXTENSION KinematicTree (#1069)

    • description: add interface to class Robot, to create either redundant or minimal coordinates kinematic tree

    • notes: however, is not capable of creating robots with localHT!=HT0()

    • date resolved: 2022-05-06 00:07, date raised: 2022-05-05

  • 1.2.69 DOCU KinematicTree (#1064)

    • description: add basic description (equations)

    • date resolved: 2022-05-05 22:14, date raised: 2022-05-05

  • 1.2.68 EXTENSION KinematicTree (#1067)

    • description: add standalone example

    • notes: see TestModels/kinematicTreeTest.py

    • date resolved: 2022-05-05 20:00, date raised: 2022-05-05

  • 1.2.67 DOCU KinematicTree (#1065)

    • description: add user function description

    • date resolved: 2022-05-05 20:00, date raised: 2022-05-05

  • 1.2.66 EXTENSION KinematicTree (#1068)

    • description: add test

    • notes: added test and MiniExample

    • date resolved: 2022-05-05 19:59, date raised: 2022-05-05

  • 1.2.65 BUG KinematicTree (#1063)

    • description: cpp version gives wrong results as compared to MBS

    • notes: corrected inertia - must be w.r.t. COM

    • date resolved: 2022-05-05 16:14, date raised: 2022-05-05

  • 1.2.64 EXTENSION BodyGraphicsDataList (#1066)

    • description: new interface used in Kinematic tree which holds a list of GraphicsData lists

    • date resolved: 2022-05-05 11:32, date raised: 2022-05-05

  • 1.2.63 EXTENSION add KinematicTree (#655)

    • description: ObjectKinematicTree (minimal coordinates)

    • notes: this is a first version, but tests and validation are necessary!

    • date resolved: 2022-05-05 10:27, date raised: 2021-05-01

  • 1.2.62 EXTENSION KinematicTree (#913)

    • description: add efficient C++ functionality for operating on 6D vectors and matrices for kinematics/dynamics

    • date resolved: 2022-05-05 10:23, date raised: 2022-02-02

  • 1.2.61 CHANGE RigidBodyMath.h (#1062)

    • description: remove duplicate from src/Utilities

    • date resolved: 2022-05-03 11:33, date raised: 2022-05-03

  • 1.2.60 EXTENSION Matrix3DList (#1047)

    • description: add new structure Matrix3DList; used to create list of 3D matrices and transfer into MainSystem mbs, e.g. in KinematicTree

    • date resolved: 2022-05-01 00:47, date raised: 2022-04-25

  • 1.2.59 EXTENSION simulateInRealtime (#1038)

    • description: put waitMicroSeconds into settings

    • date resolved: 2022-04-30 20:41, date raised: 2022-04-07

  • 1.2.58 CHECK MacOS (#1049)

    • description: check if flag -mmacosx-version-min=11.0 is needed in setup.py and if this causes problems on older pre-AppleM1 which needs wheel version 10.9

    • notes: x86 compilation requires 11.0, otherwise it fails; need to find another way for compilation

    • date resolved: 2022-04-29 09:59, date raised: 2022-04-25

  • 1.2.57 CHANGE buildDate.tex (#1060)

    • description: remove by default change of buildDate.tex in setup.py

    • date resolved: 2022-04-29 08:20, date raised: 2022-04-28

  • 1.2.56 BUG MacOS compile (#1059)

    • description: sse2neon.h not found

    • notes: exclude parallel threads from MacOS version until resolving compilation problem

    • date resolved: 2022-04-28 11:58, date raised: 2022-04-28

  • 1.2.55 DOCU Add description of Pybind11 interaction (#905)

    • description: add some description of C++-Python interaction and entry points into C++

    • date resolved: 2022-04-27 20:37, date raised: 2022-02-01

  • 1.2.54 DOCU TestSuite (#1015)

    • description: add notes in Exudyn on testsuite (add remark: in many cases for tracking of changes, not for validation)

    • date resolved: 2022-04-27 20:21, date raised: 2022-03-28

  • 1.2.53 CHANGE ClearWorkspace (#1058)

    • description: also close open matplotlib figures before they are lost

    • date resolved: 2022-04-27 19:47, date raised: 2022-04-27

  • 1.2.52 BUG ClearWorkspace (#1052)

    • description: has no effect on global variables

    • notes: NOTE: matplotlib looses figures which cannot be closed with closeAll in PlotSensor

    • date resolved: 2022-04-27 19:03, date raised: 2022-04-25

  • 1.2.51 BUG coordinatesSolution (#1053)

    • description: coordinatesSolutionFile is corrupted for ACF test in text mode

    • notes: not repeatable; may have been caused by iPython crash

    • date resolved: 2022-04-27 10:29, date raised: 2022-04-26

  • 1.2.50 TESTING CreateNonlinearFEMObjectGenericODE2NGsolve (#1051)

    • description: test FEM.CreateNonlinearFEMObjectGenericODE2NGsolve with simple example

    • notes: included in ACFtest.py

    • date resolved: 2022-04-27 10:23, date raised: 2022-04-25

  • 1.2.49 EXTENSION solutionInformation (#1057)

    • description: replace new lines in solutionInformation when writing into coordinatesSolution file in order to preserve readable file structure

    • date resolved: 2022-04-27 10:22, date raised: 2022-04-27

  • 1.2.48 EXTENSION MarkerSuperElementRigid (#1056)

    • description: add check for node sizes used in marker

    • date resolved: 2022-04-26 22:29, date raised: 2022-04-26

  • 1.2.47 BUG NodeGenericODE2 error (#1055)

    • description: NodeGenericODE2 raises system error CNodeODE2::GetVelocity: call illegal during solver initialize

    • notes: added GetVelocity and GetAcceleration to NodeGenericODE2, with risk that these functions are used unintended

    • date resolved: 2022-04-26 22:29, date raised: 2022-04-26

  • 1.2.46 EXTENSION NodeIndex, … (#1054)

    • description: add possibility to allow simple arithmetic operations +,-,*,-() for NodeIndex, MarkerIndex, etc.

    • date resolved: 2022-04-26 22:29, date raised: 2022-04-26

  • 1.2.45 BUG CreateLinearFEMObjectGenericODE2 (#1050)

    • description: FEM.CreateLinearFEMObjectGenericODE2 not working

    • date resolved: 2022-04-25 17:34, date raised: 2022-04-25

  • 1.2.44 EXTENSION Vector3DList (#1046)

    • description: add new structure Vector3DList; used to create list of 3D vectors and transfer into MainSystem mbs, e.g. in KinematicTree

    • date resolved: 2022-04-25 08:40, date raised: 2022-04-25

  • 1.2.43 EXTENSION dispy cluster (#1045)

    • description: fixed some bugs in ProcessParameterList (http_server) ; added some checks (if dispy is installed); cluster is used now iff clusterHostNames != []) and useMultiProcessing==True

    • date resolved: 2022-04-23 17:09, date raised: 2022-04-23

  • 1.2.42 BUG GetNodesOnLine (#1044)

    • description: FEM.GetNodesOnLine raises exception

    • date resolved: 2022-04-22 18:28, date raised: 2022-04-22

  • 1.2.41 BUG serialRobotTest.py (#1043)

    • description: class robotics.Robot computes wrong static torque compensation in function StaticTorques(HT)

    • notes: due to #0744 this bug has been magically resolved!

    • date resolved: 2022-04-21 15:15, date raised: 2022-04-21

  • 1.2.40 EXTENSION multithreaded compilation (#1042)

    • description: enable setup.py with multithreaded compilation, using Monkey patch for compiler with multithreading library; enable parallel build with: python setup.py install –parallel

    • date resolved: 2022-04-21 02:00, date raised: 2022-04-21

  • 1.2.39 CHANGE CreateRedundantCoordinateMBS (#744)

    • description: interchange joint markers, affecting the sign of the measured joint rotation angle, being now consistent with minimal coordinate formulations / kinematicTree; also interchange jointTorque0List/1List to be consistent with marker list

    • notes: adapted SerialRobotTestDH2.py and SerialRobotTSD.py in Example folders for corrected signs

    • date resolved: 2022-04-20 00:37, date raised: 2021-09-01

  • 1.2.38 CHANGE Pluecker transforms (#1041)

    • description: correct Pluecker transform T66 functions, such as RotationTranslation2T66, etc. and introduce inverse functions for usage in Featherstone algorithm

    • notes: note that rotations in RotationX2T66, RotationY2T66, RotationZ2T66 are transposed/CHANGED as compared to previous version; T66toRotationTranslation is corrected/CHANGED and now is consistent with the backtransformation; InverseT66toRotationTranslation does the inverse operation (but also for rotation); RotationTranslation2T66 corrected/CHANGED; HT2T66 is corrected/CHANGED with inverse version HT2T66Inverse; rotations in Exudyn now consistent between T66, HT and other rotation matrices

    • date resolved: 2022-04-19 16:16, date raised: 2022-04-19

  • 1.2.37 EXTENSION twitter (#1021)

    • description: add twitter account for exudyn: https://twitter.com/RExudyn

    • notes: Follow me!

    • date resolved: 2022-04-12 16:28, date raised: 2022-03-31

  • 1.2.36 EXTENSION contour bodies (#1040)

    • description: show contour colors for GraphicsData added to bodies

    • notes: option turned on by default, but may slow down visualization for larger models; turn off in case of problems…

    • date resolved: 2022-04-10 17:21, date raised: 2022-04-10

  • 1.2.35 EXTENSION mesh edges (#1039)

    • description: show mesh edges independently of visualization mode (edges on/off) - allowing to show mesh edges but not other graphics edges

    • date resolved: 2022-04-10 11:42, date raised: 2022-04-10

  • 1.2.34 CHANGE solution file (#1036)

    • description: fixed inconsistent information in line 3 of coordinatesSolutionFile: ODE2 coordinates

    • date resolved: 2022-04-07 20:30, date raised: 2022-04-07

  • 1.2.33 EXTENSION solution and sensor files (#1034)

    • description: add Python version to e.g. Exudyn version = 1.x.y Python3.9 / Python3.6(32bits) in coordinatesSolutionFile and sensor output files to identify exactly the versions and platform used for computation; check also Parameter and optimization output files for updated information

    • date resolved: 2022-04-07 12:02, date raised: 2022-04-07

  • 1.2.32 EXTENSION InteractiveDialog (#1033)

    • description: also add tkInter DoubleVar for sliders to make bi-directional interaction simpler (but not needed)

    • date resolved: 2022-04-04 21:26, date raised: 2022-04-04

  • 1.2.31 EXTENSION InteractiveDialog (#1031)

    • description: extended with option addLabelStringVariables to be able to modify strings in text labels

    • date resolved: 2022-04-04 17:20, date raised: 2022-04-04

  • 1.2.30 CHANGE AVX2 (#1030)

    • description: change both Python 3.6 32bit/46bit versions to compilation without AVX

    • date resolved: 2022-04-04 15:39, date raised: 2022-04-04

  • 1.2.29 CHANGE PERFORM_UNIT_TESTS (#1024)

    • description: set PERFORM_UNIT_TESTS for P3.7 instead of P3.6

    • date resolved: 2022-04-04 15:38, date raised: 2022-03-31

  • 1.2.28 BUG ContactFrictionCircleCable2D (#1029)

    • description: computes wrong segment length internally, leading to wrong sticking position

    • date resolved: 2022-04-04 12:14, date raised: 2022-04-04

  • 1.2.27 BUG cnt in Render window (#1028)

    • description: debug information cnt=.. shown in Render window

    • date resolved: 2022-04-04 11:50, date raised: 2022-04-04

  • 1.2.26 CHANGE RotationMatrix2EulerParameters (#1027)

    • description: RotationMatrix2EulerParameters computes Euler parameters with large deviations from unit norm in case of inaccurate rotation matrices; this may lead to failure of CheckPreAssembleConsistencies; resolved by adding normalization before returning Euler parameters

    • date resolved: 2022-04-03 00:24, date raised: 2022-04-03

  • 1.2.25 EXTENSION build venv (#1025)

    • description: switch to building windows purely on virtual conda environments, allowing to build all windows and linux versions in parallel

    • date resolved: 2022-04-02 00:28, date raised: 2022-04-02

  • 1.2.24 CHANGE virtual environments (#1022)

    • description: switch to virtual environments in anaconda for compilation on different platforms

    • date resolved: 2022-04-02 00:28, date raised: 2022-03-31

  • 1.2.23 CHANGE remove /Zi in MSVC (#1023)

    • description: remove compilation flag /Zi in setup.py which prevents from parallel runs of MSVC cl.exe

    • date resolved: 2022-03-31 11:28, date raised: 2022-03-31

  • 1.2.22 DOCU robotics links (#1020)

    • description: links to github are not resolved correctly for robotics module

    • date resolved: 2022-03-30 10:47, date raised: 2022-03-30

  • 1.2.21 EXTENSION SpaceMouse (#1019)

    • description: add functionality for 3D mouse / spacemouse by reading joystick inputs and interpret as 3D position and rotation data; add visualization flag interactive.useJoystickInput (default=True); deactivate this flag if your external device makes problems

    • date resolved: 2022-03-29 14:37, date raised: 2022-03-29

  • 1.2.20 TESTING ContactFrictionCircleCable2D (#1017)

    • description: check and test computation of sticking position segment length: undeformed versus deformed

    • notes: switched to reference length in computation of relative sticking position as given in theDoc; leads to improved results

    • date resolved: 2022-03-28 20:33, date raised: 2022-03-28

  • 1.2.19 CHANGE SaveImage (#1014)

    • description: make window height divisible by 2 (skip one line if necessary)

    • notes: added alignment option for width and height; default options work well for ffmpeg conversion

    • date resolved: 2022-03-28 14:25, date raised: 2022-03-28

  • 1.2.18 CHANGE TGA output (#1013)

    • description: switch from TGA to .png output using stb_image_write.h in GLFW

    • notes: added mode exportImages.saveImageFormat to chose between PNG and TGA - PNG with much smaller files!

    • date resolved: 2022-03-28 14:24, date raised: 2022-03-28

  • 1.2.17 CHANGE GLFW (#1012)

    • description: switch to GLFW3.3.6 includes in order to be in line with AppleM1 version

    • date resolved: 2022-03-28 12:03, date raised: 2022-03-28

  • 1.2.16 CHANGE Apple M1 (#1011)

    • description: use universal glfw libs for both Apple x86 and Apple arm M1

    • date resolved: 2022-03-28 12:03, date raised: 2022-03-28

  • 1.2.15 CHANGE autodiff (#1010)

    • description: extract autodiff as separate module

    • notes: now using AutomaticDifferentiation.h in Utilities

    • date resolved: 2022-03-28 11:56, date raised: 2022-03-28

  • 1.2.14 BUG solutionViewer (#1009)

    • description: does not load automatically due to change of coordinatesSolution filename ending

    • notes: changed loading of default file in SolutionViewer

    • date resolved: 2022-03-28 09:11, date raised: 2022-03-28

  • 1.2.13 BUG sensor double values (#1007)

    • description: sensor outputs two times for a single time step

    • notes: error occured due to automaticStepSize activated and call to ReduceStepSize even in case adaptiveStep=0; automaticStepSize now deactivated for solvers without step size control

    • date resolved: 2022-03-27 19:31, date raised: 2022-03-24

  • 1.2.12 CHANGE ContactFrictionCircleCable2D (#1006)

    • description: LHS computation: exclude undefined state from sticking position computation

    • date resolved: 2022-03-22 12:43, date raised: 2022-03-22

  • 1.2.11 CHANGE PostNewton timer (#1005)

    • description: remove timer from timer structures and activate as special timer

    • date resolved: 2022-03-22 12:30, date raised: 2022-03-22

  • 1.2.10 EXTENSION ContactFrictionCircleCable2D (#1004)

    • description: add option usePointWiseNormals flag as an additional option to control the way forces are applied to cable

    • date resolved: 2022-03-21 10:12, date raised: 2022-03-21

  • 1.2.9 EXTENSION setup.py (#1003)

    • description: include manifest.in and readme.md in main

    • date resolved: 2022-03-20 11:47, date raised: 2022-03-20

  • 1.2.8 CHANGE pypi problems (#1002)

    • description: previous version marked beta

    • date resolved: 2022-03-19 10:54, date raised: 2022-03-19

  • 1.2.7 DOCU ANCFCable2D (#986)

    • description: extend/finalize description - specifically for integration points and OutputVariable functions

    • date resolved: 2022-03-18 23:09, date raised: 2022-03-15

  • 1.2.6 CHANGE pypi (#1001)

    • description: finalized conversion of markup file for description at pypi.org: use only links to github, as pypi does not recognize .rst file in github format

    • date resolved: 2022-03-18 20:54, date raised: 2022-03-18

  • 1.2.5 DOCU adjust version in docu (#1000)

    • description: recompile

    • date resolved: 2022-03-18 19:07, date raised: 2022-03-18

  • 1.2.4 EXTENSION pypi (#999)

    • description: improved versioning

    • date resolved: 2022-03-18 18:28, date raised: 2022-03-18

  • 1.2.3 EXTENSION pypi (#998)

    • description: add description and tags

    • date resolved: 2022-03-18 18:09, date raised: 2022-03-18

  • 1.2.2 EXTENSION pre-release version (#997)

    • description: add “.dev” tag in version and wheel name for pre-releases, allowing to distinguish on pypi for different versions

    • date resolved: 2022-03-18 17:02, date raised: 2022-03-18

  • 1.2.1 EXTENSION pre-release (#996)

    • description: allow pre-releases to be uploaded on pypi, fetched with “pip install exudyn –pre”

    • date resolved: 2022-03-18 15:52, date raised: 2022-03-18

  • 1.2.0 EXTENSION add to pypi index (#995)

    • description: add exudyn to pypi index; allows to use “pip install exudyn”

    • date resolved: 2022-03-18 10:44, date raised: 2022-03-18

Version 1.1

  • 1.1.177 BUG ObjectContactFrictionCircleCable2D (#994)

    • description: forces on circle added up twice, because weighting factor not considered

    • notes: tested force on circle with static computation in belt drive

    • date resolved: 2022-03-18 08:30, date raised: 2022-03-18

  • 1.1.176 EXTENSION User function for ConnectorCoordinateVector (#880)

    • description: add user function for constraint and for jacobian; test with double pendulum made of masses

    • date resolved: 2022-03-17 18:14, date raised: 2022-01-24

  • 1.1.175 BUG ObjectConnectorDistance (#993)

    • description: activeConnector=False produces wrong jacobian

    • date resolved: 2022-03-17 17:52, date raised: 2022-03-17

  • 1.1.174 EXTENSION PlotSensor (#992)

    • description: add PlotSensorDefaults function which allows to set default values for all subsequent PlotSensor calls

    • notes: use e.g. PlotSensorDefaults().fontSize=16 to change fontSize for all subsequent calls

    • date resolved: 2022-03-17 17:28, date raised: 2022-03-17

  • 1.1.173 EXTENSION velocityOffset (#991)

    • description: add velocity offset for SpringDamper and TorsionalSpringDamper, allowing simple controllers using offset and velocityOffset in preStepUser functions

    • date resolved: 2022-03-16 23:51, date raised: 2022-03-16

  • 1.1.172 DOCU convergence problems (#989)

    • description: add specific section in theDoc - Exudyn Basics related to ways for resolving convergence problems

    • date resolved: 2022-03-16 18:59, date raised: 2022-03-16

  • 1.1.171 EXTENSION ANCFCable2D (#938)

    • description: add drawing function for forces in normal direction with factor

    • date resolved: 2022-03-15 20:33, date raised: 2022-02-10

  • 1.1.170 EXTENSION RigidBody (#933)

    • description: add accelerationLocal and angularAccelerationLocal output

    • notes: added to ObjectRigidBody and ObjectRigidBody2D

    • date resolved: 2022-03-15 20:14, date raised: 2022-02-07

  • 1.1.169 EXTENSION ANCFCable2D (#967)

    • description: add OutputVariables RotationMatrix, Rotation, AngularVelocity(Local) and AngularAcceleration

    • notes: Acceleration, AngularVelocity and AngularAcceleration currently only implemented for ANCFCable2D but not for ALEANCFCable2D

    • date resolved: 2022-03-15 20:01, date raised: 2022-03-03

  • 1.1.168 EXTENSION ANCFCable2D (#966)

    • description: add missing terms for OutputVariables and AccessFunctions to allow constraints that are at local position y!=0

    • date resolved: 2022-03-15 19:54, date raised: 2022-03-03

  • 1.1.167 EXTENSION plot (#983)

    • description: add function to create plot-ready data from mbs.GetObjectOutputBody for a list of consecutive beams, e.g., axial force, displacement or curvature along axial reference coordinate

    • notes: added function DataArrayFromSensorList which allows to create data from a list of sensors

    • date resolved: 2022-03-14 20:41, date raised: 2022-03-11

  • 1.1.166 EXTENSION PlotSensor (#982)

    • description: add option to plot 2D arrays

    • notes: numpy arrays are used instead of sensorNumbers; these arrays must have the same format as data stored in sensor files; this data format does not create any labels

    • date resolved: 2022-03-14 16:24, date raised: 2022-03-11

  • 1.1.165 EXTENSION startOfStepState (#985)

    • description: initialize startOfStepState together with currentState in InitializeSolverInitialConditions(…) in order to be valid when sensors are written in initialization

    • date resolved: 2022-03-14 13:07, date raised: 2022-03-14

  • 1.1.164 EXTENSION ObjectContactFrictionCircleCable2D (#981)

    • description: add OutputVariable functions for Coordinates (gap, slip), Coordinates_t (gap_t, slip_t), and contact and friction forces per segment (ForceLocal)

    • date resolved: 2022-03-14 12:58, date raised: 2022-03-11

  • 1.1.163 EXTENSION renderer precision (#980)

    • description: add options for general precision in renderer: general.rendererPrecision as well as precision for colorbars in contour: contour.colorBarPrecision

    • date resolved: 2022-03-11 14:05, date raised: 2022-03-11

  • 1.1.162 EXTENSION VisualizationSettings (#979)

    • description: VisualizationSettings.showContactForcesValues is added to show numerical values for contact forces

    • date resolved: 2022-03-11 10:19, date raised: 2022-03-11

  • 1.1.161 EXTENSION ObjectANCFCable2D (#978)

    • description: add improved axial strain computation for reduced order integration

    • notes: works for axial strain and axial force if reducedAxialInterploation=True

    • date resolved: 2022-03-10 20:36, date raised: 2022-03-10

  • 1.1.160 EXTENSION ObjectANCFCable2D (#977)

    • description: add new mode useReducedOrderIntegration=2 with good performance/accuracy and exceptional representation of axial strains

    • date resolved: 2022-03-10 20:08, date raised: 2022-03-10

  • 1.1.159 EXTENSION ContactCircleCable2D (#976)

    • description: add visualization flag showContactCircle; uses circleTiling*4 for tiling (from VisualizationSettings.general)!

    • date resolved: 2022-03-10 14:15, date raised: 2022-03-10

  • 1.1.158 EXTENSION VisualizationSettings (#975)

    • description: added showContactForces and contactForcesFactor in contact; this flag is currently only available in ContactCircleCable2D

    • date resolved: 2022-03-10 13:52, date raised: 2022-03-10

  • 1.1.157 CHANGE VisualizationSettings (#974)

    • description: moved contactPointsDefaultSize from connectors to contact; connectors.contactPointsDefaultSize is inactive from now!

    • date resolved: 2022-03-10 13:50, date raised: 2022-03-10

  • 1.1.156 EXTENSION ContactFrictionCircleCable2D (#953)

    • description: add improved (static) friction model

    • notes: also added improved PostNewton switching strategies and changed initial values for NodeGenericData

    • date resolved: 2022-03-09 21:42, date raised: 2022-02-25

  • 1.1.155 EXTENSION ANCFCable2D (#932)

    • description: add velocityLocal + accelerationLocal output in axial/normal direction

    • notes: only velocityLocal added

    • date resolved: 2022-03-06 18:24, date raised: 2022-02-07

  • 1.1.154 EXTENSION ANCFCable2D (#931)

    • description: add acceleration as output variable

    • notes: only added for ANCF, but not for ALEANCF due to coupling terms with vALE

    • date resolved: 2022-03-06 18:24, date raised: 2022-02-07

  • 1.1.153 EXTENSION PlotSensor (#970)

    • description: PlotSensor allows to set fileCommentChar and fileDelimiterChar

    • date resolved: 2022-03-04 13:27, date raised: 2022-03-04

  • 1.1.152 EXTENSION exudyn.plot (#969)

    • description: added method to convert output files from other codes; in particular plot.FileStripSpaces(…) can be used to strip leading / trailing spaces and remove double spaces

    • date resolved: 2022-03-04 13:27, date raised: 2022-03-04

  • 1.1.151 EXTENSION ANCFCable2D (#965)

    • description: add option for strainIsRelativeToReference, which if set to 1. accounts for the reference geometry as the stress-free configuration; also works for ALE Cable2D

    • date resolved: 2022-03-03 08:13, date raised: 2022-03-03

  • 1.1.150 CHANGE CreateReevingCurve (#964)

    • description: corrected sign of returned curvatures, now can be directly used for beam elements

    • date resolved: 2022-03-02 17:20, date raised: 2022-03-02

  • 1.1.149 BUG CreateReevingCurve (#963)

    • description: removeFirstLine=True not working: wrong case i==0 needs to be changed to i==1

    • date resolved: 2022-03-02 15:25, date raised: 2022-03-02

  • 1.1.148 CHANGE CreateReevingCurve (#962)

    • description: adjust number of nodes in case of closed Curve (numberOfANCFnodes=20 gives 20 elements in this case)

    • date resolved: 2022-03-02 15:25, date raised: 2022-03-02

  • 1.1.147 CHANGE stepInformation (#961)

    • description: changed flags in timeIntegration and staticSolver stepInformation: value of 1024 now causes output at every step; all values > 16 have been divided by two; 255=detailed overall output, 2047=detailed output every step; see SimulationSettings in theDoc

    • date resolved: 2022-03-02 10:33, date raised: 2022-03-02

  • 1.1.146 CHANGE coordinatesSolution (#959)

    • description: change ending of coordinates solution files from .txt to .sol in case of binary files

    • date resolved: 2022-03-02 10:14, date raised: 2022-03-02

  • 1.1.145 CHANGE ObjectContactFrictionCircleCable2D (#960)

    • description: move to ObjectContactFrictionCircleCable2DOld and improve new version

    • date resolved: 2022-03-02 09:50, date raised: 2022-03-02

  • 1.1.144 DOCU LoadForceVector (#958)

    • description: add note to description in forces that user function values are available in sensors, but they are not updated during drawing

    • date resolved: 2022-03-01 19:40, date raised: 2022-02-28

  • 1.1.143 EXTENSION rolling joints (#952)

    • description: ConnectorRollingDiscPenalty and JointRollingDisc now add a OutputVariable RotationMatrix, containing the J1 to global transformation

    • date resolved: 2022-03-01 19:35, date raised: 2022-02-25

  • 1.1.142 TESTING Friction (#951)

    • description: test LuGre friction model as ODE1 model versus position/history based model

    • notes: added lugreFrictionODE1.py as a demo showing the LuGre model based on a ODE1 user function

    • date resolved: 2022-03-01 19:34, date raised: 2022-02-24

  • 1.1.141 EXTENSION ProfileLinearAccelerationsList (#956)

    • description: add linear acceleration profile to robotics.motion, currently only allowing to create profile directly from accelerations

    • date resolved: 2022-02-28 19:05, date raised: 2022-02-28

  • 1.1.140 CHANGE robotics.motion (#955)

    • description: change PTPprofile to BasicProfile

    • date resolved: 2022-02-28 09:59, date raised: 2022-02-28

  • 1.1.139 BUG JointRollingDisc (#950)

    • description: OutputVariable VelocityLocal is returned in global coordinates; description in theDoc is wrong; will be changed to outputVariable Velocity; local velocity will represent the slippage in special local joint J1 coordinates; see theDoc for updated functionality and outputs

    • date resolved: 2022-02-25 14:32, date raised: 2022-02-22

  • 1.1.138 BUG ConnectorRollingDiscPenalty (#949)

    • description: OutputVariable VelocityLocal local is returned in global coordinates; description in theDoc is wrong; will be changed to outputVariable Velocity; see theDoc for updated functionality and outputs

    • date resolved: 2022-02-25 14:32, date raised: 2022-02-22

  • 1.1.137 EXTENSION sensors storeInternal (#946)

    • description: adapt most TestModels to store sensordata internally

    • date resolved: 2022-02-21 00:43, date raised: 2022-02-20

  • 1.1.136 CHANGE TestModels (#947)

    • description: change most test models to use Sensors storeInternal mode; this avoids creating many files during TestSuite runs

    • date resolved: 2022-02-20 20:40, date raised: 2022-02-20

  • 1.1.135 EXTENSION PlotSensor (#921)

    • description: add option to add subplots

    • notes: allows to create subplots, adjusting also the plot size using sizeInches; for examples see Examples/plotSensorExamples.py

    • date resolved: 2022-02-19 22:45, date raised: 2022-02-02

  • 1.1.134 EXTENSION PlotSensor (#922)

    • description: add option to add linewidth, markersize, markerStyles=[“o”,…], markerSizes=[], lineStyles=[“-“,…], colors=[..], markerDensity=…; lineWidths=[] allowing to plot a reduced number of markers on top of a line

    • notes: added many options for line and marker styles, check: colors, lineStyles, lineWidths, markerStyles, markerSizes, markerDensity

    • date resolved: 2022-02-19 22:41, date raised: 2022-02-02

  • 1.1.133 EXTENSION PlotSensor (#920)

    • description: add x-range and y-range for zoom

    • notes: added rangeX and rangeY options to specify range

    • date resolved: 2022-02-19 16:59, date raised: 2022-02-02

  • 1.1.132 EXTENSION PlotSensor (#945)

    • description: extend option for offsets, allowing sensor data to use as offset (e.g., loaded from file or from internal sensor data)

    • notes: see plotSensorExamples for some particular usage

    • date resolved: 2022-02-19 16:45, date raised: 2022-02-19

  • 1.1.131 EXTENSION PlotSensor (#944)

    • description: add argument labels, which can be string (for one sensor) or list of strings (according to number of sensors resp. components) representing the labels used in legend; if not provided, automatically generated legend is used

    • date resolved: 2022-02-19 15:47, date raised: 2022-02-19

  • 1.1.130 EXTENSION Sensors store values internally (#918)

    • description: add option to store sensor values internally; using ResizableMatrix internally; rows added and matrix is automatically resized

    • notes: storeInternal boost the speed of writing sensor values, however, most of time is spent on computing sensor values, which typically about 2 seconds for 1e6 time steps per sensor; file write adds usually 3 seconds extra on that bill

    • date resolved: 2022-02-19 00:13, date raised: 2022-02-02

  • 1.1.129 EXTENSION mbs.GetSensorStoredData() (#943)

    • description: add MainSystem functionality to retrieve internally stored data in sensor; used, e.g., for PlotSensor to plot data without storing in files

    • date resolved: 2022-02-19 00:10, date raised: 2022-02-18

  • 1.1.128 BUG sensorsAppendToFile (#942)

    • description: appendToFile is used instead of sensorsAppendToFile for switching between append and replace operations for files

    • date resolved: 2022-02-18 20:54, date raised: 2022-02-18

  • 1.1.127 EXTENSION SimulationSettings (#901)

    • description: improve type completion by adding py::init<…> functions for all subclasses

    • notes: not solvable in this simple way as type completion is not improved when adding this information

    • date resolved: 2022-02-18 20:30, date raised: 2022-01-31

  • 1.1.126 EXTENSION MotionInterpolator (#941)

    • description: mark as deprecated; instead, created motion submodule in robotics with class Trajectory; uses classes ProfileConstantAcceleration and ProfilePTP to construct piecewise profiles for trajectory; precomputes acceleration profiles in first step and thus is several factors faster in Python implementation; Trajectory converts to dict and can be printed in order to obtain key values of computed trajectories

    • date resolved: 2022-02-18 16:31, date raised: 2022-02-15

  • 1.1.125 EXTENSION MotionInterpolator (#940)

    • description: add option to add trajectories defined by duration as well as by maxVelocity and maxAcceleration using synchronous PTP trajectory generation

    • date resolved: 2022-02-15 12:38, date raised: 2022-02-15

  • 1.1.124 BUG NodeRigidBody2D (#939)

    • description: does not correctly measure rotations (returns x-coordinate instead of angle)

    • date resolved: 2022-02-15 09:58, date raised: 2022-02-15

  • 1.1.123 EXTENSION resolved by: P. Manzl SensitivityAnalysis() (#745)

    • description: add functionality to processing, evaluating the sensitivities of certain sensor values w.r.t. parameters; same interface as ParameterVariation

    • notes: see processing.ComputeSensitivities(…)

    • date resolved: 2022-02-14 09:50, date raised: 2021-09-03

  • 1.1.122 BUG exudyn.signal (#934)

    • description: conflicts with Python 3.8.8 and Python 3.9.7 (and possibly other) with internal Python signal package; change exudyn.signal to exudyn.signalProcessing

    • date resolved: 2022-02-10 09:23, date raised: 2022-02-10

  • 1.1.121 EXTENSION binary output (#870)

    • description: add option to create binary solution files

    • notes: notes: use outputPrecision to switch between float and double - see there; speeds up file writing considerably and reduces file sizes; Integrated into LoadSolutionFile

    • date resolved: 2022-02-09 08:45, date raised: 2022-01-18

  • 1.1.120 EXTENSION LoadSolutionFile (#930)

    • description: extend function to check if binary file; if yes, switches to binary mode

    • date resolved: 2022-02-09 08:44, date raised: 2022-02-07

  • 1.1.119 CHANGE coordinatesSolution, sensors (#929)

    • description: add version to coordinatesSolutionFile and sensor output files; should not affect current parsing of output files

    • date resolved: 2022-02-07 00:02, date raised: 2022-02-07

  • 1.1.118 DOCU sort settings options (#878)

    • description: sort settings representation in Python by sorting dictionaries prior to writing inteface files; keep current sorting (grouping) in latex documentation

    • notes: type completion may change sorting afterwards

    • date resolved: 2022-02-06 21:57, date raised: 2022-01-24

  • 1.1.117 TESTING CPP UNIT TESTS (#928)

    • description: fail because of change of ConstSizeVector to use move assignment and move constructor

    • notes: adapted test to avoid move assignment

    • date resolved: 2022-02-06 00:04, date raised: 2022-02-06

  • 1.1.116 EXTENSION resolved by: S. Holzinger Minimize (#919)

    • description: add optimization with same interface as GenticOptimization but based on scipy.minimize

    • notes: added Minimize to processing; usage is nearly same as GeneticOptimization(…); example under Examples/minimizeExample.py

    • date resolved: 2022-02-04 15:45, date raised: 2022-02-02

  • 1.1.115 BUG GeneralContact (#924)

    • description: WARNING message raised in ANCF contact

    • date resolved: 2022-02-03 12:01, date raised: 2022-02-03

  • 1.1.114 EXTENSION CreateReevingCurve (#923)

    • description: add function CreateReevingCurve(…) in exudyn.beams to create reeving system along circles, allows to create curve and nodes for ANCFCable2D elements created with PointsAndSlopes2ANCFCable2D(…); see Examples/reevingSystem.py

    • date resolved: 2022-02-03 12:00, date raised: 2022-02-02

  • 1.1.113 CHECK PostNewton (#803)

    • description: Check discontinuous iterations in combination with adaptive step (immediately reduces step size even if ignoreMaxSteps=True)

    • notes: did not further show up; possibly due to non-convergence

    • date resolved: 2022-02-02 08:20, date raised: 2021-11-25

  • 1.1.112 EXTENSION PlotSensor (#906)

    • description: add option componentsX to add x-components for figures, e.g., to plot y over x position, instead over time

    • date resolved: 2022-02-01 18:34, date raised: 2022-02-01

  • 1.1.111 FIX automatic example referencing (#864)

    • description: fix searching for examples, e.g., NodePoint as NodePoint( in order no to find NodePoint2D examples

    • date resolved: 2022-01-31 23:01, date raised: 2022-01-14

  • 1.1.110 BUG GeneralContact (#903)

    • description: autocomputed searchTree gives very large values and visualization not working

    • notes: ANCFCable2D bounding box computation had 1 wrong else case

    • date resolved: 2022-01-31 21:34, date raised: 2022-01-31

  • 1.1.109 EXTENSION GenerateCircularArcANCFCable2D (#899)

    • description: add function to create beams along circular arc

    • date resolved: 2022-01-31 14:20, date raised: 2022-01-30

  • 1.1.108 BUG GenerateStraightLineANCFCable2D (#902)

    • description: cableNodePositionList does not returns 3D vectors for nodes except first node

    • date resolved: 2022-01-31 14:19, date raised: 2022-01-31

  • 1.1.107 EXTENSION GenerateStraightLineANCFCable2D (#898)

    • description: add option to use existing nodes in generation of beams

    • date resolved: 2022-01-31 10:11, date raised: 2022-01-30

  • 1.1.106 EXTENSION add Python utility beams (#897)

    • description: add exudyn.beams utility module, containing helper functions for creating beams, etc.; move existing functions to this module

    • date resolved: 2022-01-31 10:11, date raised: 2022-01-30

  • 1.1.105 BUG GenerateStraightLineANCFCable2D (#900)

    • description: arguments vALE and ConstrainAleCoordinate are not implemented and need to be removed

    • date resolved: 2022-01-30 23:32, date raised: 2022-01-30

  • 1.1.104 DOCU theDoc objects (#896)

    • description: sort objects into bodies, basic connectors, constraints and joints

    • date resolved: 2022-01-30 23:12, date raised: 2022-01-30

  • 1.1.103 EXTENSION ConnectorGravity (#895)

    • description: add connector representing gravitational forces between heavy masses (planet, satellite, etc.)

    • date resolved: 2022-01-30 19:05, date raised: 2022-01-30

  • 1.1.102 EXTENSION colors (#894)

    • description: added several colors in graphicsDataUtilities, added color4black, extended color4list to 16 colors

    • date resolved: 2022-01-30 18:10, date raised: 2022-01-30

  • 1.1.101 CHANGE GeneralContact (#893)

    • description: changed flag introSpheresContact to sphereSphereContact; added flag for special mode to recycle last Post Newton step friction force

    • date resolved: 2022-01-28 18:55, date raised: 2022-01-28

  • 1.1.100 EXTENSION adapt to Python3.9 (#891)

    • description: make wheels and installers for Python3.9, running on Anaconda3-2021-11 Windows-x86_64

    • date resolved: 2022-01-25 23:31, date raised: 2022-01-25

  • 1.1.99 TESTING PlotSensor (#889)

    • description: add test for PlotSensor, returning 1 if all plotting runs without crashing

    • date resolved: 2022-01-25 19:03, date raised: 2022-01-25

  • 1.1.98 EXTENSION PlotSensor (#890)

    • description: add possibility to use filenames instead of sensor numbers, automatically loading these files

    • date resolved: 2022-01-25 18:00, date raised: 2022-01-25

  • 1.1.97 BUG iPython output stops (#887)

    • description: after a solver error, output of iPython stops

    • notes: changed to correct catching/throwing of Python and C++ exception types; outpur continues after solver error

    • date resolved: 2022-01-25 14:25, date raised: 2022-01-25

  • 1.1.96 EXTENSION GetInterpolatedSignalValue (#885)

    • description: add check in case that time values are distributed non-uniform; add tolerance as option

    • date resolved: 2022-01-25 12:10, date raised: 2022-01-25

  • 1.1.95 EXTENSION PlotSensor (#884)

    • description: add optional title to plot

    • date resolved: 2022-01-25 11:52, date raised: 2022-01-25

  • 1.1.94 EXTENSION PlotSensor (#883)

    • description: if sensorNumbers is scalar, components is a list, sensorNumbers is automatically adjusted; accepts now e.g. PlotSensor(mbs, 0, components=[0,1,2])

    • date resolved: 2022-01-25 11:36, date raised: 2022-01-25

  • 1.1.93 EXTENSION PlotSensor (#881)

    • description: add option to apply factors and offsets to plotted signals; add option to add labels which appears at legend

    • date resolved: 2022-01-25 11:36, date raised: 2022-01-25

  • 1.1.92 CHANGE PlotSensor (#882)

    • description: add option to use X, Y and Z components instead of 0, 1, 2 for Position, Displacement etc.; this option is enabled by default and changes the appearance -> set False, to preserve the old mode; component now also shown if only one curve plotted

    • date resolved: 2022-01-25 11:19, date raised: 2022-01-25

  • 1.1.91 EXTENSION LoadSolutionFile (#879)

    • description: changed safeMode to loading sinle lines, which saves memory enormously, and added new options for loading huge files

    • date resolved: 2022-01-24 14:53, date raised: 2022-01-24

  • 1.1.90 BUG AddSensorRecorder (#877)

    • description: fails for scalar Sensors OutputVariableTypes (e.g. when measuring Rotation of TorsionalSpringDamper)

    • notes: added special scalar case

    • date resolved: 2022-01-21 09:17, date raised: 2022-01-21

  • 1.1.89 EXTENSION flush files (#876)

    • description: add option to flush solution and sensor files immediately after writing, simplifying the readout process; add option for large scale simulations, which are always flushed - helping for continuation of computations on supercomputers

    • date resolved: 2022-01-20 14:01, date raised: 2022-01-20

  • 1.1.88 EXTENSION PlotSensor (#875)

    • description: fixed fontSize option and add options for minor/major ticks and SAVE figure to PlotSensor(…) using fileName=…

    • date resolved: 2022-01-19 11:08, date raised: 2022-01-19

  • 1.1.87 EXTENSION GeneralContact ANCFCable (#800)

    • description: add ANCFCable2D to GeneralContact, enabling contact with planar spheres (cylinders)

    • date resolved: 2022-01-18 18:54, date raised: 2021-11-19

  • 1.1.86 EXTENSION numberOfThreads (#866)

    • description: move simulationSettings.numberOfThreads into new section parallel in simulationSettings; remove comment [not implemented]

    • date resolved: 2022-01-18 17:43, date raised: 2022-01-15

  • 1.1.85 CHANGE preStepPyExecute (#872)

    • description: remove preStepPyExecute from docu, time integration / static solver interface and from CSolverBase

    • date resolved: 2022-01-18 16:57, date raised: 2022-01-18

  • 1.1.84 CHANGE improved Newton restart (#874)

    • description: added an additional Newton iteration after restarting modified Newton or when switching to full Newton; this reduces effects in generalized alpha and may improve behaviour with severe nonlinearities

    • date resolved: 2022-01-18 13:44, date raised: 2022-01-18

  • 1.1.83 CHANGE adaptiveStepRecoveryIterations (#869)

    • description: add option to static and dynamic solvers to adjust max. Newton+disc. iterations prior to increase of step size; changed (previous internal) default value from 5 to 7

    • date resolved: 2022-01-17 19:54, date raised: 2022-01-17

  • 1.1.82 EXTENSION solverSettings.stepInformation (#868)

    • description: change modes to add up binary flags; ADD several new options to show Newton iterations, jacobians, discontinuous iterations, per step or period; also add option to show output at every step

    • date resolved: 2022-01-17 12:11, date raised: 2022-01-17

  • 1.1.81 EXTENSION GetInterpolatedSignalValue (#857)

    • description: new function to interpolate a numeric signal with time/data vectors at a certain time point

    • date resolved: 2022-01-11 15:41, date raised: 2022-01-11

  • 1.1.80 EXTENSION IndexFromValue (#856)

    • description: function got faster mode in case of constant sampling rate

    • date resolved: 2022-01-11 14:39, date raised: 2022-01-11

  • 1.1.79 DOCU Add LTG description (#854)

    • description: add section on local-to-global mapping of coordinates sec:overview:ltgmapping

    • date resolved: 2022-01-08 12:09, date raised: 2022-01-08

  • 1.1.78 DOCU publications directory (#849)

    • description: create separate directory Examples/publications/ for publication data, Python files of numerical examples, etc.

    • date resolved: 2022-01-06 16:32, date raised: 2022-01-06

  • 1.1.77 EXTENSION analytic jacobians (#846)

    • description: add analytic jacobians general functionality, realized for CartesianSpringDamper and CoordinateSpringDamper; deactivate with newton.numericalDifferentiation.forODE2connectors = False

    • date resolved: 2021-12-23 11:07, date raised: 2021-12-23

  • 1.1.76 EXTENSION Marker jacobian derivative2 (#770)

    • description: add jacobian derivative to most important connector markers

    • notes: implemented for markers except MarkerSuperElement; only MarkerPosition and MarkerRigidBody affected mostly; first tests show that jacobianDerivative agrees with numerical differentiation, BUT even increases iteration numbers

    • date resolved: 2021-12-22 21:21, date raised: 2021-09-28

  • 1.1.75 EXTENSION implement AccessFunctionType::JacobianTtimesVector_q (#842)

    • description: implement function needed for MarkerBody for objects ANCFCable, ObjectFFRF and ObjectFFRFreducedOrder; currently raising exception if used in this setup!

    • date resolved: 2021-12-22 21:18, date raised: 2021-12-22

  • 1.1.74 CHANGE Explicit solvers (#831)

    • description: remove second ComputeODE2Acceleration() call and copy solutionODE2_tt from beginning of time step rk.stageDerivODE2_t[0], same for ODE1 variables; add flag but change that by default as it speeds up 2x; could also use information from previous step …?

    • date resolved: 2021-12-20 13:09, date raised: 2021-12-15

  • 1.1.73 EXTENSION explicit integrator (#832)

    • description: add flag timeintegration.explicitIntegration.computeEndOfStepAccelerations to compute end-of-step accelerations; this computation doubles the effort of explicit one-step-methods, particularly relevant in particles or contact simulations

    • date resolved: 2021-12-17 12:38, date raised: 2021-12-17

  • 1.1.72 EXTENSION MT integration (#450)

    • description: fully integrate multithreading into system.cpp, vector.cpp and dense solver

    • notes: integrated into system, missing mass matrix and jacobian

    • date resolved: 2021-12-09 18:17, date raised: 2020-09-16

  • 1.1.71 DOCU GeneralContact description (#799)

    • description: add general section in theDoc for description of GeneralContact

    • date resolved: 2021-12-09 12:36, date raised: 2021-11-19

  • 1.1.70 DOCU performance section (#793)

    • description: add performance and speedup section to theDoc, explaining most useful settings like modifiedNewton, EigenSparse, writeToFile, step size, numberOfThreads, constant mass matrix, etc.

    • date resolved: 2021-12-09 12:36, date raised: 2021-11-02

  • 1.1.69 EXTENSION add trig-sphere friction tests (#823)

    • description: add simple test cases to check friction implementation

    • date resolved: 2021-12-09 08:28, date raised: 2021-12-06

  • 1.1.68 EXTENSION shrink mesh (#822)

    • description: add method to shrink meshes using max distance to surface with normals; used for contact trig-sphere implementation

    • notes: currently slows down for larger meshes due to elimination of duplicate points!

    • date resolved: 2021-12-09 08:28, date raised: 2021-12-06

  • 1.1.67 BUG GraphicsData cube (#827)

    • description: cubes has wrong numbering of nodes

    • notes: FIXED numbering in order to allow for correct normals needed in contact computation

    • date resolved: 2021-12-07 17:14, date raised: 2021-12-07

  • 1.1.66 EXTENSION GraphicsData normals (#826)

    • description: add normals to some GraphicsData cube objects

    • date resolved: 2021-12-07 16:27, date raised: 2021-12-07

  • 1.1.65 EXTENSION GraphicsData add defaults (#825)

    • description: add some default values, especially to (center)point of GraphicsDataSphere, GraphicsDataCylinder, GraphicsDataOrthoCube, etc. in order to reduce interface sizes for objects added in the centerpoint [0,0,0]; thus some defaults were also necessary for radius or sizes!

    • date resolved: 2021-12-07 14:41, date raised: 2021-12-07

  • 1.1.64 CHANGE PlotSensor (#824)

    • description: added serval NEW options, including: newFigure, colorCodeOffset, figureName and closeAll; NOTE that now PlotSensor by default opens a new figure!

    • date resolved: 2021-12-07 12:11, date raised: 2021-12-07

  • 1.1.63 BUG RigidBody visualization (#820)

    • description: normals in rigid body visualization transformed wrongly

    • notes: before, rotating bodies may have shown shading, now resolved

    • date resolved: 2021-12-05 17:32, date raised: 2021-12-05

  • 1.1.62 EXTENSION GraphicsData convert (#816)

    • description: add function GraphicsData2TrigsAndPoints(…) to convert graphicsData into triangles and points

    • date resolved: 2021-12-05 15:43, date raised: 2021-12-02

  • 1.1.61 EXTENSION robotics.future, robotics.utilities, robotics.mobile (#814)

    • description: add special submodules for robotics functions; future contains currently developed submodules that will be available in future at a different location in robotics

    • date resolved: 2021-12-05 15:43, date raised: 2021-12-02

  • 1.1.60 CHANGE ObjectRigidBody (#819)

    • description: correct HasConstantMassMatrix for Lie group nodes and COM=0

    • date resolved: 2021-12-05 11:19, date raised: 2021-12-05

  • 1.1.59 EXTENSION GeneralContact TriangleMesh (#804)

    • description: Add rigid-body-marker based triangle mesh to GeneralContact

    • date resolved: 2021-12-04 10:08, date raised: 2021-11-25

  • 1.1.58 EXTENSION MergeGraphicsDataTriangleList (#818)

    • description: now works if either both lists contain normals or both do not

    • date resolved: 2021-12-03 20:15, date raised: 2021-12-03

  • 1.1.57 EXTENSION NodePointGround (#817)

    • description: add Node::Orientation to NodeType, such that it can also be used as a rigidBody node

    • date resolved: 2021-12-03 14:34, date raised: 2021-12-03

  • 1.1.56 CHANGE tCPU showing wrong time (#815)

    • description: minor bug; time shown is since starting of iPython

    • date resolved: 2021-12-02 17:48, date raised: 2021-12-02

  • 1.1.55 CHANGE resolved by: M. Sereinig exudyn.robotics.special (#813)

    • description: extend and move roboticsSpecial to robotics.special; add special robotics functionality likde manipulability

    • date resolved: 2021-12-02 11:03, date raised: 2021-12-02

  • 1.1.54 EXTENSION robotics submodule (#618)

    • description: Create robotics.special and robotics.mecanum or robotics.ros submodules with subdirectories

    • date resolved: 2021-12-02 11:02, date raised: 2021-03-23

  • 1.1.53 EXTENSION Suppress warnings (#812)

    • description: add flag to globally suppress warnings

    • notes: use exudyn.SuppressWarnings(True) to turn off warnings

    • date resolved: 2021-12-01 08:50, date raised: 2021-12-01

  • 1.1.52 CHANGE add default constructors (#811)

    • description: add rule of five default constructors to SlimVector, SlimArray, ConstSizeVector and ConstSizeMatrix; remove mutable from data

    • date resolved: 2021-11-28 21:56, date raised: 2021-11-28

  • 1.1.51 EXTENSION GeneralContact visualization (#810)

    • description: add visualization for searchtree (box) and bounding boxes

    • notes: use SC.visualizationSettings.contact to adjust the various options to visualize the contact search tree

    • date resolved: 2021-11-26 23:20, date raised: 2021-11-26

  • 1.1.50 EXTENSION resolved by: S. Holzinger ParameterVariation (#809)

    • description: Added a additional argument parameterFunctionData={} to function ParameterVariation(). The argument parameterFunctionData can be used to make global data available inside the parameterFunction.

    • date resolved: 2021-11-26 12:57, date raised: 2021-11-26

  • 1.1.49 TESTING Performance test for GeneralContact (#808)

    • description: added test with sphere contact

    • date resolved: 2021-11-26 10:49, date raised: 2021-11-26

  • 1.1.48 TESTING GeneralContact (#802)

    • description: add TestModel for Sphere-Sphere GeneralContact

    • date resolved: 2021-11-25 22:58, date raised: 2021-11-25

  • 1.1.47 CHANGE GeneralContact (#807)

    • description: added new functions to initialize searchTree, searchTreeBox and frictionPairings which were previously in FinalizeContact(…)

    • date resolved: 2021-11-25 22:16, date raised: 2021-11-25

  • 1.1.46 CHANGE removed FinalizeContact (#806)

    • description: removed this function, which is now automatically called in mbs.Assemble()

    • date resolved: 2021-11-25 22:15, date raised: 2021-11-25

  • 1.1.45 EXTENSION AssembleSystemInitialize (#805)

    • description: add additional function inside mbs.Assemble() to initialize GeneralContact

    • date resolved: 2021-11-25 22:14, date raised: 2021-11-25

  • 1.1.44 EXTENSION sensor recorder (#779)

    • description: add utilities function for recording signals internally in mbs; avoids writing to sensor files, which helps reducing overhead in ParameterVariation and GeneticOptimization

    • notes: available in Python utilities function AddSensorRecorder(…)

    • date resolved: 2021-11-25 11:10, date raised: 2021-10-17

  • 1.1.43 CHANGE Box3D (#801)

    • description: check Ubuntu20 warnings; replace Vector3D pmin with Real pmin[3] to avoid warnings and gain speedup

    • date resolved: 2021-11-25 11:08, date raised: 2021-11-23

  • 1.1.42 EXTENSION Implicit GeneralContact (#798)

    • description: add ODE2RHS jacobian and PostNewton to GeneralContact

    • date resolved: 2021-11-19 16:07, date raised: 2021-11-19

  • 1.1.41 EXTENSION GeneralContact (#787)

    • description: add contact object, directly in mbs, which allows different types of contact with efficient computation and search trees; start with simple spherical contact

    • date resolved: 2021-11-19 16:06, date raised: 2021-11-01

  • 1.1.40 BUG verboseMode (#784)

    • description: output of every step in verboseMode=1 after long time or if there are some very long lasting steps

    • notes: not fully clarified, but modified time when data is output; may occur in case of very long running iPython?

    • date resolved: 2021-11-14 23:23, date raised: 2021-10-31

  • 1.1.39 BUG multithreading fails for user functions (#790)

    • description: build separate lists for objects and loads with user functions, excluded in MT evaluation

    • date resolved: 2021-11-14 23:21, date raised: 2021-11-02

  • 1.1.38 BUG error when switching from n to 1 threads (#794)

    • description: RuntimeError: TemporaryComputationDataArray::operator[]: index out of range caused when switching from numberOfThreads>1 to 1 thread

    • date resolved: 2021-11-13 23:59, date raised: 2021-11-04

  • 1.1.37 EXTENSION multithreaded ODE2RHS and compute loads (#788)

    • description: use multithreaded computation for ODE2 RHS and for loads computation; use simulationSettings.numberOfThreads > 1 for multithreaded computation

    • date resolved: 2021-11-13 23:59, date raised: 2021-11-01

  • 1.1.36 EXTENSION GL list GeneralContact (#796)

    • description: speed up visualization with GL list for spheres in GeneralContact

    • date resolved: 2021-11-13 23:03, date raised: 2021-11-10

  • 1.1.35 EXTENSION itemInterface (#797)

    • description: add representation for item interface classes, using __repr__() = dict(self)

    • date resolved: 2021-11-10 08:40, date raised: 2021-11-10

  • 1.1.34 EXTENSION constant mass matrix (#789)

    • description: do not recompute mass matrix if it is totally constant in implicit solver; add flag to solver options to force recompute

    • date resolved: 2021-11-08 10:30, date raised: 2021-11-02

  • 1.1.33 EXTENSION add TCP/IP interface (#795)

    • description: add CreateTCPIPconnection and other functions to utilities for interconnection with other programs via TCP/IP

    • date resolved: 2021-11-08 10:29, date raised: 2021-11-08

  • 1.1.32 EXTENSION TemporaryComputationDataArray (#786)

    • description: add array of TemporaryCompData for multithreaded computation

    • date resolved: 2021-11-01 23:01, date raised: 2021-11-01

  • 1.1.31 EXTENSION ComputeSystemODE1RHS (#785)

    • description: add list of loads with ODE1 relevancy, otherwise all loads are computed even if there are no ODE1 coordinates

    • notes: added simple flag to avoid computation if no ODE1 coordinates available

    • date resolved: 2021-11-01 21:28, date raised: 2021-11-01

  • 1.1.30 EXAMPLE add n-mass-oscillator (#781)

    • description: add interactive example based on simulateInteractively for n-mass-oscillator with step and frequency excitation

    • date resolved: 2021-10-28 16:44, date raised: 2021-10-25

  • 1.1.29 EXTENSION ComputeLinearizedSystem (#747)

    • description: add exudyn.ComputeLinearizedSystem similar to what is done in ComputeODEEigenvalues, returning M, K, D, …

    • date resolved: 2021-10-27 18:40, date raised: 2021-09-03

  • 1.1.28 EXTENSION enable close window button (#780)

    • description: close window button is now enabled, which stops current and following simulations until render window is restarted or SetRenderEngineStopFlag(False)

    • notes: if a simulation with renderer is quit (also ESCAPE button), then a further call to solver will be ignored until the simulation is reset, or SetRenderEngineStopFlag(False)

    • date resolved: 2021-10-21 09:31, date raised: 2021-10-21

  • 1.1.27 EXTENSION GenericODE2 FEM (#778)

    • description: add FEMinterface function for creation of ObjectGenericODE2 with linear FEM model and nonlinear FEM model (using NGsolve)

    • date resolved: 2021-10-16 23:23, date raised: 2021-10-16

  • 1.1.26 BUG MatrixContainer::SetWithSparseMatrixCSR (#776)

    • description: does not set number of columns and rows due to error in MatrixContainer::SetAllZero()

    • date resolved: 2021-10-09 16:53, date raised: 2021-10-08

  • 1.1.25 EXTENSION sparse ObjectJacobianODE2 (#767)

    • description: add dense and sparse interface to ObjectJacobianODE2

    • date resolved: 2021-10-09 16:53, date raised: 2021-09-27

  • 1.1.24 BUG ObjectGenericODE2, ObjectFFRFreducedOrder (#775)

    • description: visualization fails if outputVariable = None

    • date resolved: 2021-10-08 17:26, date raised: 2021-10-08

  • 1.1.23 EXTENSION ImportMeshFromNGsolve (#773)

    • description: added option meshOrder which allows to use second order elements with meshOrder=2, leading to much higher accuracy of displacements and stresses

    • date resolved: 2021-10-01 14:04, date raised: 2021-10-01

  • 1.1.22 EXTENSION ComputePostProcessingModesNGsolve (#774)

    • description: added improved functionality for ComputePostProcessingModes using NGsolve, speeding up computations by factor of 10

    • date resolved: 2021-10-01 14:03, date raised: 2021-10-01

  • 1.1.21 EXTENSION compute HCB modes with NGsolve (#772)

    • description: add much faster computation function ComputeHurtyCraigBamptonModesNGsolve for computation of eigenmodes

    • date resolved: 2021-10-01 14:03, date raised: 2021-10-01

  • 1.1.20 EXTENSION GeneticOptimization (#771)

    • description: add normal distribution and distanceFactorGenerations

    • date resolved: 2021-09-29 17:38, date raised: 2021-09-29

  • 1.1.19 EXTENSION Marker jacobian derivative (#769)

    • description: add jacobian derivative to markers to allow analytical differentiation of connectors

    • date resolved: 2021-09-28 18:57, date raised: 2021-09-28

  • 1.1.18 CHANGE Newton.useNumericalDifferentiation (#768)

    • description: change to Newton.numericalDifferentiation.forAE and Newton.numericalDifferentiation.forODE2; previous Newton.useNumericalDifferentiation only affected AE (algebraic equations) and should be changed now to Newton.numericalDifferentiation.forAE; default is False

    • date resolved: 2021-09-27 15:11, date raised: 2021-09-27

  • 1.1.17 EXTENSION sparse object matrices (#612)

    • description: add sparse matrix computation mode for ComputeMassMatrix and for ObjectJacobianODE2; consider Lie algebra derivatives

    • notes: sparse ObjectJacobianODE2 computation not yet implemented and moved to issue767

    • date resolved: 2021-09-27 14:35, date raised: 2021-03-21

  • 1.1.16 CHANGE ObjectGenericODE2 (#766)

    • description: change mass matrix, stiffnessmatrix, etc. types to PyMatrixContainer in order to accept dense and sparse matrices

    • date resolved: 2021-09-27 14:32, date raised: 2021-09-26

  • 1.1.15 DOCU describe Python types (#765)

    • description: describe Python types such as NumpyMatrix or PyMatrixContainer in intro to objects, nodes, …

    • date resolved: 2021-09-27 14:32, date raised: 2021-09-26

  • 1.1.14 EXTENSION PyMatrixContainer (#764)

    • description: extend PyMatrixContainer to accept numpy.array or list of lists as input

    • date resolved: 2021-09-26 23:35, date raised: 2021-09-26

  • 1.1.13 EXTENSION ComputeMassMatrix (#763)

    • description: add sparse mode with MatrixContainer

    • date resolved: 2021-09-26 18:01, date raised: 2021-09-26

  • 1.1.12 IMPROVEMENT MatrixBase (#762)

    • description: remove virtual from begin/end operators

    • date resolved: 2021-09-26 17:36, date raised: 2021-09-26

  • 1.1.11 BUG ANCF/ALE contour plot (#750)

    • description: contour plot not showing displacements or forces

    • notes: bug due to issue 760, which has been resolved now!

    • date resolved: 2021-09-24 08:48, date raised: 2021-09-03

  • 1.1.10 EXTENSION LinkedDataVectorBase (#761)

    • description: allowing SetNumberOfItems to make LinkedDataVectors smaller after linking

    • date resolved: 2021-09-24 08:47, date raised: 2021-09-24

  • 1.1.9 BUG contour plot (#760)

    • description: nodes in contour plot leading to exudyn crash due to ConstSizeVector decoupled from Vector

    • date resolved: 2021-09-24 08:47, date raised: 2021-09-24

  • 1.1.8 EXTENSION FEM CMSObjectComputeNorm (#758)

    • description: add function into FEM to compute maximum stress / strain / etc for CMSObject (ObjectFFRFreducedOrder), using only the objectNumber as an input; options are outputVariableType=StressLocal, norm=”” (Mises, L2norm, none), nodeNumbers=[] … providing optional list of nodes to restrict the computation

    • date resolved: 2021-09-23 19:25, date raised: 2021-09-22

  • 1.1.7 EXTENSION FEM GetNodePositionsMean (#757)

    • description: add function into FEMinterface to compute mean (average) position based on nodeNumbers (as list)

    • date resolved: 2021-09-23 17:38, date raised: 2021-09-22

  • 1.1.6 BUG contour plot (#759)

    • description: equivalent stress showing negative color bar values in contour plot

    • notes: contour plot with norm (component -1) showing only positive min and max values when tested

    • date resolved: 2021-09-23 17:19, date raised: 2021-09-23

  • 1.1.5 EXTENSION FEM MisesStress (#756)

    • description: add function that computes Mises stress from 6 stress components as obtained in stress sensor

    • notes: put into exudyn.physics module

    • date resolved: 2021-09-23 16:02, date raised: 2021-09-22

  • 1.1.4 EXTENSION GetKinematicTree66 in robotics (#755)

    • description: add function to export KinematicTree66 from Robotic class

    • date resolved: 2021-09-22 18:06, date raised: 2021-09-22

  • 1.1.3 TESTING performance tests (#754)

    • description: add automated performance tests for solver speed to determine significant drop of performance

    • date resolved: 2021-09-22 10:10, date raised: 2021-09-22

  • 1.1.2 EXTENSION TorsionalSpringDamper (#620)

    • description: add torsional spring damper similar to SpringDamper, fixed on a single local axis of marker0, allowing to realize controllers and torques

    • date resolved: 2021-09-16 10:45, date raised: 2021-04-06

  • 1.1.1 EXTENSION Renderer tkinter (#679)

    • description: add flag to disable calls to tkinter from Renderer, which is not possible if tkinter is already used for interactive dialogs. This allows to open visualizationSettings in AnimateModes and SolutionViewer

    • date resolved: 2021-09-14 10:21, date raised: 2021-05-14

  • 1.1.0 BUG SetMarkerParameter (#751)

    • description: causes internal error, because of wrong index check; workaround: use int(..) to cast marker index

    • date resolved: 2021-09-10 16:22, date raised: 2021-09-10

Version 1.0

  • 1.0.295 BUG ObjectALEANCFCable2D (#749)

    • description: precomputed mass terms not computed accordingly; leads to crash if not static solution computed in advance

    • date resolved: 2021-09-03 15:12, date raised: 2021-09-03

  • 1.0.294 DOCU Extend solver description (#748)

    • description: add some description for SolveStatic / SolveDynamic in solver chapter

    • date resolved: 2021-09-03 13:54, date raised: 2021-09-03

  • 1.0.293 EXTENSION serialrobot (#504)

    • description: build completely from homogenouos transformations, COMs, inertia tensors, masses, axes, axesTypes

    • notes: done earlier

    • date resolved: 2021-08-22 11:12, date raised: 2020-12-16

  • 1.0.292 EXTENSION github (#540)

    • description: update README.rst file and make it similar to other packages (e.g. pydy)

    • notes: done earlier

    • date resolved: 2021-08-22 11:11, date raised: 2021-01-09

  • 1.0.291 DOCU README.rst (#729)

    • description: add .rst readme file containing gettingStarted, introduction, tutorial and other information

    • date resolved: 2021-08-22 10:58, date raised: 2021-08-05

  • 1.0.290 EXTENSION robotics (#740)

    • description: extend Robot class for Modified DH parameters and general transformations; add transformations before and after joint axis

    • date resolved: 2021-08-19 00:22, date raised: 2021-08-18

  • 1.0.289 BUG robotics (#739)

    • description: CreateRedundantCoordinateMBS draws wrong axes

    • date resolved: 2021-08-19 00:22, date raised: 2021-08-18

  • 1.0.288 BUG robotics (#742)

    • description: Robot.JointHT computes LinkHT

    • date resolved: 2021-08-18 23:31, date raised: 2021-08-18

  • 1.0.287 CHANGE robotics (#741)

    • description: add base and tool class to robotics to have more flexibility for future developments; replace toolHT to tool.HT, baseHT to base.HT; add tool.visualization and base.visualization

    • date resolved: 2021-08-18 15:07, date raised: 2021-08-18

  • 1.0.286 EXTENSION ContactCoordinate (#733)

    • description: add recommendedStepSize to ContactCoordinate and find optimal solution with data variable from StartOfStep configuration; check if step size is permanently reduced with recommendedStepSize; check a way of an overall recommendedStepSize (with filter) or allow a single event not to change global step size

    • date resolved: 2021-08-13 13:23, date raised: 2021-08-12

  • 1.0.284 DOCU RigidBody tutorial (#730)

    • description: add tutorial for rigid body with AddRigidBody(…), AddRevoluteJoint(…) functionalities

    • date resolved: 2021-08-06 20:05, date raised: 2021-08-05

  • 1.0.283 EXTENSION DrawSystemGraph (#732)

    • description: improve visualization and return graph and other information

    • date resolved: 2021-08-06 17:58, date raised: 2021-08-06

  • 1.0.282 BUG AddRevoluteJoint (#731)

    • description: AddRevoluteJoint shows error in axis definition

    • date resolved: 2021-08-05 13:40, date raised: 2021-08-05

  • 1.0.281 IMPROVEMENT Optimization2 (#704)

    • description: add direct function to NodeRigidBody to retrieve essential data for rigid body EOM and MarkerRigidBody; add flag, if rotation matrix and other quantities needed

    • notes: still no optimization for Lie group nodes, which however have simpler matrices

    • date resolved: 2021-07-31 22:33, date raised: 2021-07-04

  • 1.0.280 EXTENSION resolved by: P. Manzl general wheel (#514)

    • description: add general wheel model (with general rotation body); for mecanum wheel rolls

    • notes: implemented ObjectContactConvexRoll for general usage in Mecanum wheels and other applications

    • date resolved: 2021-07-31 21:20, date raised: 2020-12-19

  • 1.0.279 DOCU NodeRigidBody2D (#727)

    • description: Outputvariable Rotation gives 3D vector, but wrong description in DOCU

    • notes: additionally: rotation is now directly copied from rotation coordinate and is not recomputed from Tait-Bryan angles of rotation matrix

    • date resolved: 2021-07-31 21:18, date raised: 2021-07-14

  • 1.0.278 DOCU description of nodes (#726)

    • description: finish detailed description of 3D nodes and add rotation parameter description for Tait-Bryan in theory part

    • date resolved: 2021-07-13 21:17, date raised: 2021-07-13

  • 1.0.277 DOCU unify description (#725)

    • description: unify notation for special vectors, e.g., reference point or local position; add unified abbreviations for ODE2, etc.

    • date resolved: 2021-07-13 21:17, date raised: 2021-07-13

  • 1.0.276 BUG Linux version (#724)

    • description: exudyn fails after import exudyn on Ubuntu18.04 and 20.04, showing error with RenderStateMachine selectionString

    • notes: version 276 tested with Ubuntu20.04, working again

    • date resolved: 2021-07-12 22:47, date raised: 2021-07-12

  • 1.0.275 CHANGE SolutionViewer (#723)

    • description: remove SolutionViewer from exudyn init file, as it causes problems if no tkinter or matplotlib installed

    • notes: use exudyn.interactive.SolutionViewer(…) instead

    • date resolved: 2021-07-12 20:23, date raised: 2021-07-12

  • 1.0.274 BUG glfwGetWindowContentScale (#722)

    • description: function causes immediate crash on linux (UBUNTU) when importing exudyn

    • notes: added flag for linux compilation, excluding font scaling

    • date resolved: 2021-07-12 19:31, date raised: 2021-07-12

  • 1.0.273 CHANGE Pybind11 2.6 (#719)

    • description: switch to Pybind11 2.6 in included C++ files

    • date resolved: 2021-07-12 16:57, date raised: 2021-07-12

  • 1.0.272 CHANGE Python3.8 FASTLINALG (#718)

    • description: using now __FAST_EXUDYN_LINALG option, which excludes all range checks and other checks in arrays, matrices, etc.; leads usually to 30percent higher performance

    • date resolved: 2021-07-12 16:57, date raised: 2021-07-12

  • 1.0.271 BUG FEM.GetNodesOnLine(..) (#721)

    • description: fails because self. missing in call to GetNodesOnCylinder

    • date resolved: 2021-07-12 16:35, date raised: 2021-07-12

  • 1.0.270 CHANGE SC.StaticSolve, SC.TimeIntegrationSolve (#717)

    • description: remove these deprecated functions from interface

    • date resolved: 2021-07-12 15:33, date raised: 2021-07-11

  • 1.0.269 CHANGE remove old solvers (#669)

    • description: remove old static and dynamic solvers as they are not any more up to date with graphics interface

    • date resolved: 2021-07-12 15:32, date raised: 2021-05-10

  • 1.0.268 CHANGE SystemIsConsistent (#716)

    • description: add checks for functions that may not be called if not SystemIsConsistent

    • date resolved: 2021-07-11 17:30, date raised: 2021-07-11

  • 1.0.267 BUG mbs.GetSensorValues (#714)

    • description: raises error for ObjectFFRFreducedOrder: ERROR: LinkedDataVectorBase(const VectorBase<T>&, Index), startPosition < 0

    • notes: caused when called before Assemble(); checks added in future

    • date resolved: 2021-07-11 17:08, date raised: 2021-07-10

  • 1.0.266 BUG ObjectFFRFreducedOrder (#715)

    • description: OutputVariable Displacement includes localPosition, but should not

    • notes: GetMeshNodeLocalPosition included reference position twice

    • date resolved: 2021-07-11 16:33, date raised: 2021-07-10

  • 1.0.265 IMPROVEMENT ConstSizeVector (#706)

    • description: decouple ConstSizeVector and ConstSizeMatrix from Vector / Matrix and avoid virtual calls, erase all rule of 5 member functions, optimize algebra

    • notes: improved speed up to factor 2 for some items!

    • date resolved: 2021-07-11 15:06, date raised: 2021-07-06

  • 1.0.264 BUG ObjectFFRFreducedOrder (#713)

    • description: GetOutputVariableSuperElement does not agree with types described in theDoc; object does not provide Displacement or Position, sensors return wrong values

    • notes: corrected C++ implementation and theDoc.pdf for OutputVariableTypesSuperElement

    • date resolved: 2021-07-09 20:53, date raised: 2021-07-09

  • 1.0.263 CHANGE serialRobot (#712)

    • description: improve speed of serial robot by transferring controllers from load userfunctions to mbs.SetPreStepUserFunction

    • date resolved: 2021-07-09 13:28, date raised: 2021-07-09

  • 1.0.262 CHANGE generator files (#711)

    • description: changed backslash to slash in generator files such that they can also be executed on Linux and MacOS

    • date resolved: 2021-07-09 12:18, date raised: 2021-07-09

  • 1.0.261 IMPROVEMENT CMarkerBodyRigid::ComputeMarkerData (#699)

    • description: implement optimized version for Rigid node and ObjectRigidBody and avoid repeated computation of rotation matrix, etc.

    • date resolved: 2021-07-08 00:46, date raised: 2021-07-01

  • 1.0.260 BUG Linux/MacOS compile error (#709)

    • description: compiler error caused by EXU::Square

    • date resolved: 2021-07-07 19:11, date raised: 2021-07-07

  • 1.0.259 CHANGE preprocessor flags (#708)

    • description: move EXUDYN_RELEASE to preprocessor flags in setup.py

    • date resolved: 2021-07-07 08:53, date raised: 2021-07-07

  • 1.0.258 IMPROVEMENT Optimization3 (#705)

    • description: optimize ObjectRigidBody EOM, take Glocal columns instead numberOfRotationCoordinates, move rot_t into loop, etc.

    • date resolved: 2021-07-06 23:04, date raised: 2021-07-04

  • 1.0.257 CHANGE ComputeOrthonormalBasis (#703)

    • description: changed rigidBodyUtilities function, which returns a list of basis vectors, into ComputeOrthonormalBasisVectors, while ComputeOrthonormalBasis now returns a rotation matrix

    • date resolved: 2021-07-02 08:49, date raised: 2021-07-02

  • 1.0.256 EXTENSION AddPrismaticJoint (#702)

    • description: add convenient utility function to add prismatic joint based on 2 bodies, point and axis, doing all necessary work in background

    • date resolved: 2021-07-02 08:49, date raised: 2021-07-02

  • 1.0.255 EXTENSION AddRevoluteJoint (#701)

    • description: add convenient utility function to add revolute joint based on 2 bodies, point and axis, doing all necessary work in background

    • date resolved: 2021-07-02 08:49, date raised: 2021-07-02

  • 1.0.254 DOCU add links for utility functions (#700)

    • description: ADDED LINKS to Examples/ and TestModels/ example files at end of each python utility function and class, see sec:pythonUtilityFunctions

    • date resolved: 2021-07-01 21:46, date raised: 2021-07-01

  • 1.0.253 BUG GenericJoint (#697)

    • description: index2 equations not properly implemented for prismatic joints

    • notes: added second term for index2 case if joint position not constrained; TrapezoidalIndex2 solver now works if translational joint axes not constrained

    • date resolved: 2021-07-01 15:50, date raised: 2021-07-01

  • 1.0.252 EXTENSION add PrismaticJoint (#696)

    • description: add 3D prismatic joint with rotationMarker0/1 to adjust local coordinate systems and joint local x axis as the free axis of the joint

    • date resolved: 2021-07-01 13:43, date raised: 2021-07-01

  • 1.0.251 EXTENSION add RevoluteJoint (#369)

    • description: add 3D revolute joint with rotationMarker0/1 to adjust joint coordinates and joint local z axis as rotation axis

    • date resolved: 2021-07-01 13:43, date raised: 2020-04-10

  • 1.0.250 CHANGE Solution functions (#695)

    • description: remove exu and SC arguments from exudyn.utilities functions SetSolutionState(…), AnimateSolution(…); remove functoin SetVisualizationState(…): use SetSolutionState instead!

    • date resolved: 2021-06-29 17:47, date raised: 2021-06-29

  • 1.0.249 EXTENSION SolutionViewer (#694)

    • description: add interactive dialog to view solution based on coordinateSolution.txt

    • date resolved: 2021-06-29 17:31, date raised: 2021-06-29

  • 1.0.248 EXTENSION RigidBody user function (#693)

    • description: add test model for GenericODE2 user function based rigid body with Euler parameter and constraint

    • date resolved: 2021-06-28 19:34, date raised: 2021-06-28

  • 1.0.247 CHANGE NodeRigidBodyEP (#564)

    • description: transfer EP constraint from object to node, for future application to 3D beams

    • date resolved: 2021-06-28 19:34, date raised: 2021-01-28

  • 1.0.246 EXTENSION ConnectorCoordinateVectorUF (#413)

    • description: implement coordinate vector constraint user function; can be used as generic joint

    • date resolved: 2021-06-28 16:19, date raised: 2020-05-25

  • 1.0.245 EXTENSION extend ConnectorCoordinateVector (#691)

    • description: extend ConnectorCoordinateVector for quadratic terms to be used as Euler Parameters constraint

    • date resolved: 2021-06-27 23:29, date raised: 2021-06-27

  • 1.0.244 EXTENSION add MarkerNodeCoordinates (#690)

    • description: used for CoordinateVector constraint

    • date resolved: 2021-06-27 23:29, date raised: 2021-06-27

  • 1.0.243 CHANGE add itemIndex to user functions (#689)

    • description: CHANGE OF userFunctions interface with additional itemIndex for ConnectorSpringDamper, ConnectorCartesianSpringDamper, ConnectorRigidBodySpringDamper, ConnectorCoordinate, ConnectorCoordinateVector, ConnectorJointGeneric; see theDoc for changes in the interface of these user functions and adapt your models!

    • notes: WARNING: Interface of user functions for ConnectorSpringDamper, ConnectorCartesianSpringDamper, ConnectorRigidBodySpringDamper, ConnectorCoordinate, ConnectorCoordinateVector, ConnectorJointGeneric changed!!!

    • date resolved: 2021-06-27 20:45, date raised: 2021-06-27

  • 1.0.242 CHANGE ObjectGenericODE2 (#688)

    • description: extend ObjectGenericODE2 and ObjectGenericODE1 user functions for the item index to have access to nodes and other informaiton: WARNING: you need to adapt your existing user functions!

    • notes: WARNING: Interface of user functions for ObjectGenericODE2, ObjectFFRF… changed!!!

    • date resolved: 2021-06-27 20:44, date raised: 2021-06-24

  • 1.0.241 EXTENSION ObjectRigidBody (#687)

    • description: add output variable VelocityLocal to 2D and 3D rigid body objects

    • date resolved: 2021-06-22 16:55, date raised: 2021-06-22

  • 1.0.240 EXTENSION eigenvalue solver (#686)

    • description: use ngsolve solver for eigenvalue computation speedup

    • date resolved: 2021-06-14 15:21, date raised: 2021-06-14

  • 1.0.239 BUG openGL.multisampling (#684)

    • description: Mac OS multisampling option in visualizationSettings crashes; ==> do not change this option under Mac OS

    • notes: excluded multisampling option for MacOS compilation

    • date resolved: 2021-05-30 12:02, date raised: 2021-05-25

  • 1.0.238 BUG ObjectALEANCFCable2D (#681)

    • description: ObjectALEANCFCable2D position jacobian does not provide axially moving part for ObjectContactFrictionCircleCable2D, NEED TO BE ADDED

    • notes: had been already included in MarkerBodyCable2Dshape and works for roll contact

    • date resolved: 2021-05-30 12:01, date raised: 2021-05-17

  • 1.0.237 CHANGE NodeRigidBody2D (#685)

    • description: add same drawing as 3D nodes (with reference frame)

    • date resolved: 2021-05-30 11:37, date raised: 2021-05-30

  • 1.0.236 EXTENSION SlidingJointRigid (#683)

    • description: Add functionality for rigid sliding joint or add a flag for sliding joint to do both options

    • date resolved: 2021-05-20 09:30, date raised: 2021-05-19

  • 1.0.235 EXTENSION copy paste code from theDoc.pdf (#682)

    • description: changed ‘ characters to enable copy/paste of code with quotes

    • date resolved: 2021-05-19 08:54, date raised: 2021-05-19

  • 1.0.234 BUG SetSystemState (#680)

    • description: mbs.systemData.SetSystemState does not set data coordinates

    • date resolved: 2021-05-15 11:07, date raised: 2021-05-15

  • 1.0.233 CHANGE single threaded renderer (#676)

    • description: improve exu.DoRendererIdleTasks() and use it in all python function - AnimateModes, Interactive, etc.

    • notes: can now be also called in multithreaded renderer

    • date resolved: 2021-05-14 21:42, date raised: 2021-05-12

  • 1.0.232 BUG mouseInteractiveExample (#678)

    • description: not running any more, check new Renderer functions

    • date resolved: 2021-05-14 21:41, date raised: 2021-05-14

  • 1.0.231 EXTENSION HurtyCraigBampton (#630)

    • description: extend computation to work with 0 eigenmodes

    • date resolved: 2021-05-12 23:51, date raised: 2021-04-23

  • 1.0.229 BUG OutputVariable.StressLocal (#674)

    • description: norm of OutputVariable stresses does not work

    • date resolved: 2021-05-12 23:21, date raised: 2021-05-12

  • 1.0.228 BUG ObjectFFRF bug with GenericJoint (#456)

    • description: raises error: CSolverBase::SolveSteps CObjectSuperElement:GetAccessFunctionSuperElement: AngularVelocity_qt not implemented; cannot compute jacobian for orientation

    • date resolved: 2021-05-12 22:27, date raised: 2020-10-13

  • 1.0.226 EXTENSION UPDATE Lest tests (#100)

    • description: update lest tests (select C++ vs. python tests)

    • date resolved: 2021-05-12 22:21, date raised: 2019-04-01

  • 1.0.225 EXTENSION add manual solver example (#372)

    • description: add manual for solver and example; also add new prestep user function

    • notes: resolved earlier

    • date resolved: 2021-05-12 22:20, date raised: 2020-04-10

  • 1.0.224 EXTENSION Solver interface (#384)

    • description: change solver interface such that it stores MainSystem/mbs for user functions; MainSolverXYZ and CSolverXYZ take MainSystem as argument in constructor

    • date resolved: 2021-05-12 22:18, date raised: 2020-05-06

  • 1.0.223 EXTENSION PostProcessingModes (#675)

    • description: compute PostProcessingModes with multiprocessing

    • date resolved: 2021-05-12 22:10, date raised: 2021-05-12

  • 1.0.222 EXTENSION right-mouse-dialog (#672)

    • description: add item indices to right mouse dialog

    • date resolved: 2021-05-12 22:05, date raised: 2021-05-11

  • 1.0.221 EXTENSION FEM.PostProcessingModes (#673)

    • description: compute PostProcessingModes in FEMinterface with multiprocessing option

    • date resolved: 2021-05-12 15:37, date raised: 2021-05-12

  • 1.0.220 EXTENSION stress modes FEMinterface (#430)

    • description: add into FEMinterface and allow storing that data

    • notes: resolved already earlier, see issue 623

    • date resolved: 2021-05-12 15:36, date raised: 2020-07-01

  • 1.0.219 BUG ObjectFFRFreducedOrder (#631)

    • description: freefree eigenmodes and Hurty-Craig-Bampton modes do not converge to same results

    • notes: convergence for eigenmodes and HCB modes given, but differences due to HCB boundary sets, inconsistent initial conditions for MarkerSuperElementRigid; pure beam bending converges well

    • date resolved: 2021-05-12 14:05, date raised: 2021-04-23

  • 1.0.218 BUG mbs.Reset() and SC.Reset() (#671)

    • description: reset MainSystem mbs and SystemContainer SC hangs; current SC is erronously stolen from renderer when another SC is deleted

    • date resolved: 2021-05-11 10:55, date raised: 2021-05-11

  • 1.0.217 EXTENSION MacOS graphics support (#670)

    • description: add compatibility to MacOS in single-threaded graphics mode (tested with OS X 10.7)

    • date resolved: 2021-05-10 22:34, date raised: 2021-05-10

  • 1.0.216 EXTENSION Single Thread Renderer (#647)

    • description: Implement single thread renderer version for MAC OS compatibility test

    • date resolved: 2021-05-10 22:32, date raised: 2021-04-30

  • 1.0.215 EXTENSION Set visualization state (#634)

    • description: add thread-safe variant for updating the visualization state

    • date resolved: 2021-05-10 18:32, date raised: 2021-04-25

  • 1.0.214 EXTENSION multiple mbs and SystemContainer support (#668)

    • description: adapt renderer and MainSystemContainer to work with multiple MainSystems (mbs) and SC instances at same time; add SC.AttachToRenderEnginer, SC.DetachFromRenderEngine

    • date resolved: 2021-05-10 18:20, date raised: 2021-05-10

  • 1.0.213 BUG StartRenderer() (#665)

    • description: without being in a render loop (e.g., SC.WaitForRenderEngineStopFlag()), the pure StartRenderer() crashes upon left mouse click

    • date resolved: 2021-05-10 14:51, date raised: 2021-05-05

  • 1.0.212 CHANGE right mouse (#664)

    • description: add function to retrieve py::dict from items safely in python thread into temporary storage; check also other python calls to operate fully in main thread

    • date resolved: 2021-05-10 14:51, date raised: 2021-05-05

  • 1.0.211 BUG Render window (#662)

    • description: during open tkinter dialogs, the render window responds on keyboard or mouse input, which calls again python functions that hang up the system

    • date resolved: 2021-05-10 14:51, date raised: 2021-05-04

  • 1.0.210 CHECK WaitAndLockSemaphoreIgnore (#633)

    • description: check which atomic_flags are needed in C++ to make code threadsafe

    • date resolved: 2021-05-10 14:51, date raised: 2021-04-25

  • 1.0.209 EXTENSION tkinter dialogs focus and on top (#667)

    • description: when opening tkinter dialogs - visualizationSettings, edit dialogs, help, … - they immediately get focus and are on top

    • date resolved: 2021-05-10 14:49, date raised: 2021-05-10

  • 1.0.208 CHANGE make renderer Python and thread safe (#666)

    • description: add strict separation between renderer (thread) and Python (thread); add rendererPythonInterface between both threads; left and right mouse clicks now safe to press; render window does not accept any input as long as tkinter window is open, but does not produce crashes any more

    • date resolved: 2021-05-10 14:49, date raised: 2021-05-10

  • 1.0.207 DOCU help button (#663)

    • description: show “press h for help” as startup message for 10 seconds and sync help message with theDoc.pdf

    • date resolved: 2021-05-05 10:02, date raised: 2021-05-05

  • 1.0.206 EXTENSION add right mouse edit dialog (#653)

    • description: open Edit dialog for item on right-mouse-press

    • date resolved: 2021-05-04 20:58, date raised: 2021-05-01

  • 1.0.205 EXTENSION identify itemID under mouse coursor (#652)

    • description: identify object/node/… under mouse using unique color for itemID (left mouse button press)

    • date resolved: 2021-05-04 12:49, date raised: 2021-05-01

  • 1.0.204 EXTENSION Python3.8 windows wheels (#637)

    • description: create Python3.8 windows wheels automatically

    • date resolved: 2021-05-03 18:51, date raised: 2021-04-26

  • 1.0.203 EXTENSION add C++ unit tests (#661)

    • description: add C++ unit tests to Python3.6 64bits version and to testSuite. Changed initialization of all vector types to avoid errors of Vector({5}), now allowing only Vector({4.}) in constructors

    • date resolved: 2021-05-03 18:50, date raised: 2021-05-03

  • 1.0.202 CHECK initializerList (#660)

    • description: check if Vector is used with initializer list with one item - Vector({10}), converting to std::vector or Vector(10)

    • date resolved: 2021-05-03 18:50, date raised: 2021-05-03

  • 1.0.201 DOCU Troubleshooting (#659)

    • description: Add Trouble shooting section, treating common Python and solver errors to theDoc.pdf

    • date resolved: 2021-05-03 10:18, date raised: 2021-05-03

  • 1.0.200 EXTENSION Highlight item# (#650)

    • description: Highlight item# for object/node/etc.; add to visualizationSettings (itemType, item#, colorHighlightItem, colorOtherItems), draw all other items in gray

    • date resolved: 2021-05-03 01:18, date raised: 2021-05-01

  • 1.0.199 EXTENSION add ItemType (#649)

    • description: Add enum ItemType: Node, Object, …

    • date resolved: 2021-05-03 01:18, date raised: 2021-05-01

  • 1.0.198 EXTENSION add itemID to graphics objects (#651)

    • description: Add itemID (nodes, objects, markers, loads, sensors, in that order) to graphics objects (for right-mouse-press)

    • date resolved: 2021-05-02 21:26, date raised: 2021-05-01

  • 1.0.197 CHANGE add VisualizationSettings() interactive (#658)

    • description: move visualizationSettings window functions keypressRotationStep, mouseMoveRotationFactor, keypressTranslationStep, zoomStepFactor to new substructure “interactive”

    • notes: adapt your models if you used these options!

    • date resolved: 2021-05-01 23:36, date raised: 2021-05-01

  • 1.0.196 EXTENSION coordinates sizes (#654)

    • description: add function ODE2Size(…), ODE1Size(…), SystemSize(…) to mbs.systemData to retrieve number of ODE2,ODE1,AE and Data coordinates for certain configurationType; only works after mbs.Assemble()

    • date resolved: 2021-05-01 23:23, date raised: 2021-05-01

  • 1.0.195 CHANGE mbs.systemData (#656)

    • description: removed GetCurrentTime() and SetVisualizationTime(…) which have been marked as deprecated already

    • notes: Use GetTime(…) and SetTime(…) in mbs.systemData instead

    • date resolved: 2021-05-01 23:08, date raised: 2021-05-01

  • 1.0.194 EXTENSION solver messages (#644)

    • description: add solver message if not converged with helpful hints (especially if invert fails or newton fails)

    • date resolved: 2021-05-01 02:31, date raised: 2021-04-30

  • 1.0.193 EXTENSION add causing row (#349)

    • description: output causing row/column (=coordinate) which leads to singular matrix; do this for Matrix.Invert as well as for SparseLU .info code; matrix class creates string with error message!

    • date resolved: 2021-05-01 02:30, date raised: 2020-03-02

  • 1.0.192 EXTENSION jacobian singular (#646)

    • description: resolve singularities in general jacobian: resolves coordinates which are still free for static problems, but is marked as unsafe

    • date resolved: 2021-05-01 02:29, date raised: 2021-04-30

  • 1.0.191 EXTENSION redundant constraints (#645)

    • description: resolve redundant constraints: add flag linearSolverSettings.ignoreSingularJacobian in SC.SimulationSettings() to ignore singular constraint jacobians

    • date resolved: 2021-05-01 02:29, date raised: 2021-04-30

  • 1.0.190 EXTENSION node numbers with type (#333)

    • description: extend node/object/… numbers as python class with type information to check if item numbers are mixed illegally

    • notes: done already earlier, but still marked as unresolved

    • date resolved: 2021-04-30 17:04, date raised: 2020-02-06

  • 1.0.189 DOCU ObjectContactFrictionCircleCable2D (#641)

    • description: add description and figure for theory and computation

    • date resolved: 2021-04-29 08:40, date raised: 2021-04-29

  • 1.0.188 BUG fix MarkerSuperElementRigidBody (#423)

    • description: fix velocity level for MarkerSuperElementRigidBody (check constraint equations)

    • notes: fixed several errors and test examples work now on velocity level, but further checks are necessary

    • date resolved: 2021-04-27 18:24, date raised: 2020-06-09

  • 1.0.187 CHECK AnimateModes (#635)

    • description: check, why animate modes has threading-conflicts; use std::cout to find issues

    • notes: resolved threading conflicts, but visualization state set inbetween graphics update, which needs to resolve #634

    • date resolved: 2021-04-27 18:20, date raised: 2021-04-25

  • 1.0.186 EXTENSION MarkerSuperElementRigid (#640)

    • description: remove referencePosition and add offset instead (to correct errors of midpoint due to small mesh-unsymmetries)

    • notes: CHANGED interface: MarkerSuperElementRigid does not have a referencePosition anymore, but adds a parameter offset

    • date resolved: 2021-04-27 18:18, date raised: 2021-04-26

  • 1.0.185 BUG ObjectFFRFreducedOrder (#639)

    • description: incorrect AccessFunction AccessFunctionType::AngularVelocity_qt, missing correct reference point = midpoint for computation of rotation

    • date resolved: 2021-04-26 21:47, date raised: 2021-04-26

  • 1.0.184 EXTENSION MarkerSuperElementRigid (#638)

    • description: use consistent reference point = midpoint for computation of rotation and use exponential Map for rotation matrix

    • date resolved: 2021-04-26 21:47, date raised: 2021-04-26

  • 1.0.183 EXTENSION Python3.8 (#636)

    • description: add python 3.8 compilation tests; resolve issues with __index__ method needed fore NodeIndex, MarkerIndex, etc.

    • date resolved: 2021-04-26 16:25, date raised: 2021-04-26

  • 1.0.182 BUG mesh visualization (#629)

    • description: visualization artifacts in larger FE meshes due to multithreading

    • notes: added flag threadSafeGraphicsUpdate to avoid thread conflicts between graphics and computation, which is by default set True and MAY SLOW DOWN your computation speed if True

    • date resolved: 2021-04-25 22:28, date raised: 2021-04-22

  • 1.0.181 DOCU CMS theory (#632)

    • description: add theory section for Hurty-Craig-Bampton modes and eigenmode computation

    • date resolved: 2021-04-23 19:03, date raised: 2021-04-23

  • 1.0.180 BUG FEMinterface.GetNodesOnCylinder (#628)

    • description: returns erroneous indices

    • notes: corrected indexing and add warnings for illegal node types

    • date resolved: 2021-04-22 22:59, date raised: 2021-04-22

  • 1.0.179 EXTENSION Craig-Bampton (#616)

    • description: add static modes (Hurty-Craig-Bampton) to computation of modes in CMSinterface

    • notes: implemented in FEMinterface.ComputeHurtyCraigBamptonModes(…)

    • date resolved: 2021-04-21 11:09, date raised: 2021-03-21

  • 1.0.178 EXTENSION norm in contour plots (#624)

    • description: show norm (of vectors or stresses) in contour plot, using special outputVariable component=-1

    • date resolved: 2021-04-09 18:18, date raised: 2021-04-09

  • 1.0.177 EXTENSION postProcessingModes (#623)

    • description: add function to compute stress or strain modes for postprocessing, working for linear tetraherons (Tet4); see Examples/NGsolvePostProcessingStresses.py

    • date resolved: 2021-04-09 15:46, date raised: 2021-04-09

  • 1.0.176 EXTENSION show modes (#424)

    • description: add feature to visualize eigenmodes, e.g. using ObjectFFRFreducedOrder and set one initialCoordinate nonzero

    • date resolved: 2021-04-07 13:48, date raised: 2020-06-12

  • 1.0.175 EXTENSION Eigenmode visualizer (#619)

    • description: visualize eigenmodes with interactive tools with new function AnimateModes(…) to show eigenmodes of system or ObjectFFRFreducedOrder (see sec:interactive:AnimateModes)

    • date resolved: 2021-04-07 13:47, date raised: 2021-03-30

  • 1.0.174 EXTENSION InteractiveDialog (#622)

    • description: improved functionality of InteractiveDialog in interactive.py, specially for animating modes

    • date resolved: 2021-04-07 12:20, date raised: 2021-04-07

  • 1.0.173 BUG mbs.GetNodeODE2Index (#621)

    • description: Fails for NodeRigidBodyEP, because mix of AE and ODE2 variables

    • notes: added correct type check in MainSystem::PyGetNodeODE2Index

    • date resolved: 2021-04-07 09:12, date raised: 2021-04-07

  • 1.0.172 EXTENSION CMS C++ (#403)

    • description: add ObjectFFRFreducedOrder (CMS) equations in C++ and clean up code

    • date resolved: 2021-03-30 16:57, date raised: 2020-05-21

  • 1.0.171 EXTENSION geometrically exact beam2D (#470)

    • description: add to CPP

    • date resolved: 2021-03-25 18:07, date raised: 2020-11-21

  • 1.0.170 EXTENSION ODE1Coordinate (#563)

    • description: add MarkerODE1Coordinate and extend LoadCoordinate for ODE1

    • date resolved: 2021-03-25 07:43, date raised: 2021-01-27

  • 1.0.169 EXTENSION MarkerNodeCoordinate (#615)

    • description: add check in CSystem for valid coordinate numbers in MarkerNodeCoordinate

    • date resolved: 2021-03-22 14:18, date raised: 2021-03-21

  • 1.0.168 EXTENSION adaptiveStep (#611)

    • description: add adaptiveStepIncrease, Decrease and RecoverySteps options to control behavior in case of discontinuous problems

    • date resolved: 2021-03-21 00:21, date raised: 2021-03-21

  • 1.0.167 CHANGE loadFactor (#603)

    • description: exclude load factor for loads with user functions in static computations

    • date resolved: 2021-03-20 23:24, date raised: 2021-03-18

  • 1.0.166 EXTENSION startOfStep (#610)

    • description: add access function for nodal coordinates at startOfStep configuration, used in mbs.GetNodeOutput(configuration = exu.ConfigurationType.startOfStep)

    • date resolved: 2021-03-20 23:23, date raised: 2021-03-20

  • 1.0.165 CHANGE SolveDynamic, SolveStatic (#609)

    • description: store dynamicSolver and staticSolver in mbs.sys dictionary immediately after creation, which allows to use these structures in user functions during static or dynamic solution

    • date resolved: 2021-03-20 23:23, date raised: 2021-03-20

  • 1.0.164 TESTING test recommendedStepSize (#607)

    • description: test recommendedStepSize and PostNewtonUserFunction with simple elastic contact example

    • date resolved: 2021-03-20 23:23, date raised: 2021-03-20

  • 1.0.163 EXTENSION UIndex, UReal (#605)

    • description: change all relevant unsigned quantities to UIndex and UReal, as well as Vectors of UReal and Arrays of UIndex

    • date resolved: 2021-03-20 23:23, date raised: 2021-03-19

  • 1.0.162 EXTENSION UIndex check (#604)

    • description: add automatic check in item interface to check for correctness of UIndex and UReal quantities

    • date resolved: 2021-03-20 23:23, date raised: 2021-03-19

  • 1.0.161 CHANGE local quantities beam (#337)

    • description: change beam output of Force, Torque, Curvature, Stress and Strain to ForceLocal, TorqueLocal, CurvatureLocal, StressLocal, and StrainLocal

    • notes: WARNING: you need to adapt force, torque and stress, strain and curvature output variables accordingly as they may have changed specifically for ANCF beams; adapt all your model files regarding Force, Torque, etc.

    • date resolved: 2021-03-20 23:22, date raised: 2020-02-18

  • 1.0.160 CHANGE Index (#139)

    • description: change Index to (signed) int and use UIndex in python interface for unsigned parameters

    • notes: ATTENTION: this change affects many routines. All TestSuite examples passed the change but there may still be open problems due to this major change.

    • date resolved: 2021-03-20 23:21, date raised: 2019-05-20

  • 1.0.159 TESTING resolve errors 32bit testsuite (#606)

    • description: add extra tolerances for 32bit

    • date resolved: 2021-03-20 23:19, date raised: 2021-03-20

  • 1.0.158 BUG new genAlpha solver (#575)

    • description: new generalized alpha/implicit trapezoidal solver does not call solver user functions; Solution: derive CSolverImplicitSecondOrderTimeIntNew from CSolverBase and add user functions on top

    • notes: solved by removing old solver structure; new solver fully supports user functions now

    • date resolved: 2021-03-18 21:34, date raised: 2021-02-08

  • 1.0.157 EXTENSION PostNewton step size recommendation (#602)

    • description: add step recommendation as outcome of PostNewton function to improve contact and friction accuracy

    • date resolved: 2021-03-18 21:33, date raised: 2021-03-18

  • 1.0.156 EXTENSION mbs.postNewtonUserFunction (#601)

    • description: add function PostNewton(…) to be called after step update (Newton or explicit step)

    • date resolved: 2021-03-18 21:33, date raised: 2021-03-18

  • 1.0.155 IMPROVEMENT ImplicitSecondOrderSolver (#600)

    • description: remove old solver

    • date resolved: 2021-03-18 21:33, date raised: 2021-03-18

  • 1.0.154 EXTENSION rigidBodyUtilities (#598)

    • description: add G matrices for Rxyz (Tait-Bryan angles) and also time derivatives of G

    • date resolved: 2021-03-18 17:05, date raised: 2021-03-18

  • 1.0.153 EXTENSION CMS rotations (#594)

    • description: test and extend CMS / ObjectFFRFreducedOrder object for other rotation parameterizations (Tait-Bryan and rotation vector/Lie group) such that they work with explicit codes

    • date resolved: 2021-03-18 17:04, date raised: 2021-02-24

  • 1.0.152 DOCU ObjectRigidBody (#597)

    • description: fix description of equations of motion (missing m) and add steps in derivation

    • date resolved: 2021-03-18 08:22, date raised: 2021-03-18

  • 1.0.151 EXTENSION cylinder with hole (#283)

    • description: add TriangleList for cylinder with hole

    • notes: not implemented, because it can be easily created with GraphicsDataSolidOfRevolution

    • date resolved: 2021-03-16 16:59, date raised: 2019-12-07

  • 1.0.150 DOCU description (#396)

    • description: add latex description for ObjectFFRF

    • date resolved: 2021-03-16 16:57, date raised: 2020-05-16

  • 1.0.149 DOCU description (#394)

    • description: add latex description for ObjectSuperElement

    • date resolved: 2021-03-16 16:57, date raised: 2020-05-16

  • 1.0.148 EXTENSION ObjectFFRFreducedOrder (#595)

    • description: add general nodeType to AddObjectFFRFreducedOrderWithUserFunctions

    • date resolved: 2021-03-16 16:56, date raised: 2021-03-14

  • 1.0.147 CHECK ObjectRigidBody (#461)

    • description: check discription of output variables

    • date resolved: 2021-03-16 16:55, date raised: 2020-11-12

  • 1.0.146 EXTENSION GetRigidBodyNode (#596)

    • description: add function GetRigidBodyNode into rigidBodyUtilities, which returns a node item for an according node type, e.g., Euler parameters or rotation vector

    • date resolved: 2021-03-14 14:43, date raised: 2021-03-14

  • 1.0.145 DOCU FFRF docu (#583)

    • description: add documentation for FFRF and FFRFreducedOrder (CMS) to documentation

    • date resolved: 2021-03-01 12:15, date raised: 2021-02-16

  • 1.0.144 DOCU FEM help (#455)

    • description: add comments to ObjectFFRF (Tisserand frame!) and reduced that there are convenient helper functions in FEM, etc. for creating objects

    • date resolved: 2021-02-24 21:21, date raised: 2020-10-13

  • 1.0.143 CHANGE Add MacOS support (#593)

    • description: make minor adjustments for MacOS to run setup.py

    • date resolved: 2021-02-22 13:10, date raised: 2021-02-22

  • 1.0.142 BUG StartRenderer (#592)

    • description: flag verbose=True not working

    • date resolved: 2021-02-22 10:08, date raised: 2021-02-22

  • 1.0.141 EXTENSION SensorMarker visualization (#590)

    • description: add visualization for SensorMarker according to marker position

    • date resolved: 2021-02-19 10:21, date raised: 2021-02-19

  • 1.0.140 EXTENSION add SensorMarker (#400)

    • description: add sensor for markers, restricting to position/velocity and rotation/angular velocity

    • date resolved: 2021-02-18 19:15, date raised: 2020-05-20

  • 1.0.139 EXTENSION UserSensor (#585)

    • description: add user sensor, which enables the user to add any kind of sensor, specifically to combine several sensor outputs into one single sensor

    • date resolved: 2021-02-18 19:14, date raised: 2021-02-17

  • 1.0.138 CHANGE solver updateInitialValues (#589)

    • description: update also initial coordinates in order to avoid jumps in accelerations when continuing simulation

    • date resolved: 2021-02-18 18:15, date raised: 2021-02-18

  • 1.0.137 CHANGE Solver file header (#588)

    • description: move writing of solution file and sensor files headers from InitializeSolverPreChecks(…) to InitializeSolverInitialConditions(…) to avoid sensor evaluation for initial configuration

    • date resolved: 2021-02-18 16:23, date raised: 2021-02-18

  • 1.0.136 FIX ALEANCFCable2D (#587)

    • description: change mass proportional load to include force in direction of ALE coordinate

    • date resolved: 2021-02-17 18:19, date raised: 2021-02-17

  • 1.0.135 FIX GeneticOptimization (#586)

    • description: add special warnings and adaptations in order to catch cases where elitistRatio*populationSize < 1 and if distanceFactor >= 1

    • date resolved: 2021-02-17 18:17, date raised: 2021-02-17

  • 1.0.134 EXTENSION parameter variation (#584)

    • description: add possibility to prescribe set of parameters using list, e.g., ‘mass’:[1,2,4,8] instead of of tuple which describes the range: ‘mass’:(0,6,4)

    • date resolved: 2021-02-16 09:43, date raised: 2021-02-16

  • 1.0.133 DOCU optimization (#582)

    • description: add parameter variation and genetic optiization to documentation of solvers

    • date resolved: 2021-02-16 08:21, date raised: 2021-02-16

  • 1.0.132 BUG SetODE2Coordinates_tt (#581)

    • description: SetODE2Coordinates_tt writes to velocities instead of accelerations

    • date resolved: 2021-02-14 11:12, date raised: 2021-02-14

  • 1.0.131 EXTENSION ParameterVariation (#580)

    • description: processing.ParameterVariation(…): write to resultsFile to show progress in resultsMonitor.py

    • date resolved: 2021-02-11 17:49, date raised: 2021-02-11

  • 1.0.130 EXTENSION add ClearWorkspace (#576)

    • description: add ClearWorkspace() to basicUtilities which allows simple and save cleanup of globals() in python environment; recommended to be called at beginning of complex models

    • date resolved: 2021-02-10 12:35, date raised: 2021-02-08

  • 1.0.129 FIX contour text (#569)

    • description: add space to computation info text before contour plot text

    • date resolved: 2021-02-10 12:35, date raised: 2021-02-05

  • 1.0.128 FIX Renderer axes (#568)

    • description: use X(0), Y(1) and Z(2) for axes description to be compliant with Python indexing starting with 0 as well as contour components

    • date resolved: 2021-02-10 12:35, date raised: 2021-02-05

  • 1.0.127 EXTENSION ClearWorkspace (#579)

    • description: add ClearWorkspacefunction to exudyn.basicUtilities, which allows to reset global variables in ipython; see example in function description

    • date resolved: 2021-02-10 12:13, date raised: 2021-02-10

  • 1.0.126 EXTENSION SmoothStep (#578)

    • description: add SmoothStep function to exudyn.utilities, which produces a smooth step function using cosine

    • date resolved: 2021-02-10 12:13, date raised: 2021-02-10

  • 1.0.125 FIX void (#572)

    • description: redundant with issue 568

    • date resolved: 2021-02-10 12:05, date raised: 2021-02-05

  • 1.0.124 FIX void (#571)

    • description: redundant with issue 568

    • date resolved: 2021-02-10 12:05, date raised: 2021-02-05

  • 1.0.123 FIX void (#570)

    • description: redundant with issue 568

    • date resolved: 2021-02-10 12:05, date raised: 2021-02-05

  • 1.0.122 BUG PostNewtonStep (#577)

    • description: perform PostNewtonStep and PostDiscontinuousIterationStep only for active objects

    • date resolved: 2021-02-09 14:00, date raised: 2021-02-09

  • 1.0.121 EXTENSION generalized alpha (#355)

    • description: implement version of Brüls and Arnold for generalized alpha solver

    • notes: WARNING: switched to new solver based on displacement increments (Arnold/Bruls,2007), which leads to DIFFERENT (but improved) RESULTS than previous dynamic implicit integrator; new implicit solver now works with ODE1 variables

    • date resolved: 2021-02-08 01:56, date raised: 2020-03-08

  • 1.0.120 DOCU merge solver documentation (#573)

    • description: merge docu on solver in EXUDYN overview and in solver section

    • date resolved: 2021-02-07 17:33, date raised: 2021-02-07

  • 1.0.119 DOCU solvers description (#567)

    • description: extend description for equations of motion, explicit and implicit solvers

    • date resolved: 2021-02-04 01:14, date raised: 2021-02-03

  • 1.0.118 EXTENSION Impl integrator ODE1 (#560)

    • description: add ODE1 coordinates to implicit integrator

    • date resolved: 2021-02-02 15:16, date raised: 2021-01-26

  • 1.0.117 EXTENSION implicit Lie group integrator (#508)

    • description: implement implicit index2/index3 Lie group integrator as python function

    • notes: cancelled, because will be directly done in C++

    • date resolved: 2021-02-02 15:15, date raised: 2020-12-17

  • 1.0.116 CHECK memory alloc cnt (#566)

    • description: add control to check whether large amount of memory allocations happen during time integration+test suite

    • date resolved: 2021-02-01 01:38, date raised: 2021-01-29

  • 1.0.115 EXTENSION objectODE1/2, constraint lists (#541)

    • description: add lists of ODE1 and ODE2 objects, constraints, etc. in cSystemData in order to speed up processing

    • date resolved: 2021-02-01 01:38, date raised: 2021-01-13

  • 1.0.114 EXTENSION RK with constraints (#557)

    • description: add CoordinateConstraints to explict Runge-Kutta solvers

    • notes: only ground constraints included for now

    • date resolved: 2021-01-27 17:38, date raised: 2021-01-26

  • 1.0.113 TESTING Lie group tests (#558)

    • description: add Lie group integrator simple tests

    • date resolved: 2021-01-27 12:00, date raised: 2021-01-26

  • 1.0.112 EXTENSION GraphicsDataArrow (#550)

    • description: add arrow to graphicsDataUtilities

    • notes: also added GraphicsDataBasis(…) for drawing 3 orthogonal basis vectors, GraphicsDataCheckerBoard(…) for simple drawing of checker board background and MergeGraphicsDataTriangleList(…) for merging graphicsData triangle lists

    • date resolved: 2021-01-27 00:10, date raised: 2021-01-17

  • 1.0.111 EXTENSION add ODE1 coordinates (#495)

    • description: extend system (Jacobian, etc.) for ODE1 coordinates

    • date resolved: 2021-01-26 13:21, date raised: 2020-12-09

  • 1.0.110 TESTING explicit RK tests (#556)

    • description: add tests for explicit Runge Kutta integrators to TestModels

    • date resolved: 2021-01-26 13:17, date raised: 2021-01-25

  • 1.0.109 EXTENSION explicit Lie group integrator (#555)

    • description: add existing Lie group integrator in C++

    • date resolved: 2021-01-26 13:17, date raised: 2021-01-25

  • 1.0.108 EXTENSION explicit integrator (#554)

    • description: add explicit integrator with automatic step size control (DOPRI5, ODE23); checkout sec:ExplicitSolver for description of explicit solvers and sec:DynamicSolverType for available solver types

    • date resolved: 2021-01-25 00:54, date raised: 2021-01-24

  • 1.0.107 EXTENSION add RK4 integrator (#513)

    • description: put existing python RK4 integrator into CPP

    • date resolved: 2021-01-25 00:54, date raised: 2020-12-19

  • 1.0.106 EXTENSION ObjectGenericODE1 (#533)

    • description: add object ObjectGenericODE1 for generic first order ODEs

    • date resolved: 2021-01-21 17:27, date raised: 2021-01-04

  • 1.0.105 EXTENSION create physics submodule (#553)

    • description: create exudyn.physics and add friction functions

    • date resolved: 2021-01-20 10:25, date raised: 2021-01-20

  • 1.0.104 BUG DrawSystemGraph (#552)

    • description: does not work with RigidBodySpringDamper due to invalid GenericNodeData number

    • date resolved: 2021-01-19 14:43, date raised: 2021-01-19

  • 1.0.103 EXTENSION InteractiveDialog (#551)

    • description: add interactive tkinter dialog and new submodule exudyn.interactive to interact with models

    • date resolved: 2021-01-19 00:26, date raised: 2021-01-19

  • 1.0.102 EXTENSION show solver name and time (#549)

    • description: add options to show/hide solver name and current time in render window

    • date resolved: 2021-01-17 17:42, date raised: 2021-01-17

  • 1.0.101 BUG mbs.WaitForUserToContinue() (#545)

    • description: call to WaitForUserToContinue() does not always wait for keypress. Check StartRender() function and flag settings

    • date resolved: 2021-01-17 16:55, date raised: 2021-01-15

  • 1.0.100 BUG SolveDynamic/SolveStatic (#548)

    • description: option updateInitialValues not working

    • notes: corrected SetSystemState call

    • date resolved: 2021-01-17 00:08, date raised: 2021-01-17

  • 1.0.99 EXTENSION GeneticOptimization (#542)

    • description: store values continuously to file, add automatic loader and animate optimized values

    • notes: added resultsMonitor.py to exudyn module

    • date resolved: 2021-01-15 15:18, date raised: 2021-01-13

  • 1.0.98 EXTENSION realtimeSimulation (#547)

    • description: add factor for timeIntegration.simulateInRealtime

    • date resolved: 2021-01-15 15:16, date raised: 2021-01-15

  • 1.0.97 EXTENSION add __version__ version to module (#546)

    • description: enable exudyn.__version__ as commonly used in other modules

    • date resolved: 2021-01-15 15:05, date raised: 2021-01-15

  • 1.0.96 EXTENSION geneticOptimization (#544)

    • description: add optional argument resultsFile to specify a file for output of results data

    • date resolved: 2021-01-14 23:17, date raised: 2021-01-14

  • 1.0.95 EXTENSION add results monitor (#543)

    • description: add resultsMonitor.py to be called from command line for doing continuous visualization of sensors and geneticOptimization output

    • date resolved: 2021-01-14 23:08, date raised: 2021-01-14

  • 1.0.94 EXTENSION NodeGenericODE1 (#532)

    • description: add node NodeGenericODE1 for arbitrary number of ODE1 coordinates

    • date resolved: 2021-01-13 20:12, date raised: 2021-01-04

  • 1.0.93 EXTENSION solidExtrusion (#531)

    • description: add graphicsData for solid extrusion (prismatic) body; based on 2D point and segment list for flat boundaries

    • date resolved: 2021-01-10 20:43, date raised: 2021-01-04

  • 1.0.92 EXTENSION RigidBodySpringDamper (#539)

    • description: add postNewtonStepUserFunction and dataCoordinates

    • date resolved: 2021-01-08 14:34, date raised: 2021-01-08

  • 1.0.91 BUG Render window (#537)

    • description: double calling of Render(…) function could happen from RunLoop/Render and glfwSetWindowRefreshCallback (set in InitCreateWindow(…)); check if semaphore would remove visualization problems

    • notes: added semaphore but FEM visualization anomalies are still there

    • date resolved: 2021-01-07 11:23, date raised: 2021-01-06

  • 1.0.90 EXTENSION add solver eigenvalues example (#385)

    • description: add Examples/solverFunctionsTestEigenvalues to test suite

    • notes: added ComputeODE2EigenvaluesTest.py using new functionality exudyn.solver.ComputeODE2Eigenvalues(…)

    • date resolved: 2021-01-07 11:08, date raised: 2020-05-06

  • 1.0.89 EXTENSION add all tests (#494)

    • description: add all TestModel/*.py to testsuite and also examples before making changes to solver

    • date resolved: 2021-01-07 11:04, date raised: 2020-12-09

  • 1.0.88 EXTENSION user function connector (#515)

    • description: add forceUserFunction for ObjectConnectorRigidBodySpringDamper to enable User connector

    • date resolved: 2021-01-07 11:03, date raised: 2020-12-19

  • 1.0.87 EXTENSION utilities docu (#506)

    • description: complete documentation for all exudyn python utilities and add unique headers for documentation

    • date resolved: 2021-01-06 22:57, date raised: 2020-12-16

  • 1.0.86 EXTENSION solidOfRevolution (#530)

    • description: add graphicsData for solid of revoluation

    • date resolved: 2021-01-06 00:31, date raised: 2021-01-04

  • 1.0.85 EXTENSION GraphicsDataPlane (#536)

    • description: add graphicsData for simple rectangular plane with option for checkerboard pattern

    • date resolved: 2021-01-05 22:57, date raised: 2021-01-05

  • 1.0.84 EXTENSION alternating color for cylinder (#535)

    • description: add alternatingColor argument in GraphicsDataCylinder for visualization of rotation of cylindric bodies

    • date resolved: 2021-01-05 21:46, date raised: 2021-01-05

  • 1.0.83 CHANGE HIGH add MainSystem to userFunctions (#529)

    • description: add MainSystem “mbs” to all user functions as first argument (WARNING: this changes ALL user functions!!!

    • date resolved: 2021-01-05 14:31, date raised: 2021-01-04

  • 1.0.82 CHECK test examples (#447)

    • description: test all examples with new index types

    • date resolved: 2021-01-05 14:31, date raised: 2020-09-09

  • 1.0.81 BUG PlotSensor (#534)

    • description: PlotSensor crashes for Load sensors because no outputVariableType exists

    • notes: added special treatment for load sensors

    • date resolved: 2021-01-04 20:11, date raised: 2021-01-04

  • 1.0.80 EXTENSION faces transparent (#527)

    • description: add general transparency flag for faces in visualizationSettings.openGL, switchable with button “T”; allows to make node/marker/object numbers visible

    • date resolved: 2021-01-03 21:53, date raised: 2021-01-03

  • 1.0.79 TESTING ComputeODE2Eigenvalues (#509)

    • description: add example in TestModels

    • date resolved: 2021-01-03 10:44, date raised: 2020-12-18

  • 1.0.78 EXTENSION textured fonts (#528)

    • description: use TEXTURED based bitmap fonts based stored in glLists, allowing better interpolation, scalability (currently up to font size 64 without quality drop) and much higher performance

    • date resolved: 2021-01-03 10:29, date raised: 2021-01-03

  • 1.0.77 BUG solver.ComputeODE2Eigenvalues (#526)

    • description: dense mode returned unsorted eigenvalues==>add sorting

    • date resolved: 2021-01-03 10:21, date raised: 2021-01-03

  • 1.0.76 CHANGE interpret UTF8 (#524)

    • description: add conversion from UTF8 to unicode to interpret most central European characters + some important characters correctly (see sec:graphicsData)

    • date resolved: 2021-01-02 20:13, date raised: 2020-12-29

  • 1.0.75 EXTENSION opengl write UTF8 (#525)

    • description: use UTF8 encoding in opengl text output

    • date resolved: 2020-12-29 21:00, date raised: 2020-12-29

  • 1.0.74 EXTENSION show version (#523)

    • description: show current version info in openGL window; can be switched off with showComputationInfo=False

    • date resolved: 2020-12-27 01:33, date raised: 2020-12-27

  • 1.0.73 FIX openGl issues (#522)

    • description: fix positioning problems of coordinate system and contour colorbar

    • notes: now using pixel coordinates for info texts and different font sizes

    • date resolved: 2020-12-27 01:31, date raised: 2020-12-27

  • 1.0.72 EXTENSION useWindowsDisplayScaleFactor (#521)

    • description: add new option useWindowsDisplayScaleFactor in visualizationSettings.general to include display scaling factor for font sizes

    • date resolved: 2020-12-27 01:25, date raised: 2020-12-27

  • 1.0.71 EXTENSION useBitmapText (#520)

    • description: add new option useBitmapText in visualizationSettings.general to activate bitmap fonts (deprecated; now using textured fonts)

    • date resolved: 2020-12-27 01:25, date raised: 2020-12-27

  • 1.0.70 EXTENSION add bitmap font (#516)

    • description: add font using OpenGL bitmaps to improve visibility of texts (deprecated, now using textured fonts)

    • date resolved: 2020-12-27 01:23, date raised: 2020-12-21

  • 1.0.69 CHANGE correct coordinateSystemSize (#519)

    • description: set visualizationSettings.general.coordinateSystemSize relative to fontSize which scales better with larger screens

    • date resolved: 2020-12-24 01:25, date raised: 2020-12-24

  • 1.0.68 EXTENSION windows display scaling (#518)

    • description: include windows display (screen) scaling into drawing of texts to increase visibility on high dpi screens

    • notes: added flag in visualizationSettings: general.useWindowsDisplayScaleFactor

    • date resolved: 2020-12-24 00:22, date raised: 2020-12-24

  • 1.0.67 TESTING GeneticOptimization (#511)

    • description: add example in TestModels

    • date resolved: 2020-12-19 23:31, date raised: 2020-12-19

  • 1.0.66 TESTING ParameterVariation (#510)

    • description: add example in TestModels

    • date resolved: 2020-12-19 23:31, date raised: 2020-12-19

  • 1.0.65 DOCU rigidbodyinertia (#502)

    • description: add description for rigidBodyUtilities class RigidBodyInertia

    • date resolved: 2020-12-19 23:28, date raised: 2020-12-14

  • 1.0.64 BUG testsuite (#512)

    • description: EXUDYN build date referred shows wrong path

    • notes: refer now to installed module

    • date resolved: 2020-12-19 00:44, date raised: 2020-12-19

  • 1.0.63 EXTENSION changes (#507)

    • description: incorporate resolved issues and bugs into theDoc.pdf

    • date resolved: 2020-12-17, date raised: 2020-12-16

  • 1.0.62 EXTENSION rigidBodyUtilities (#505)

    • description: add description for RigidBodyInertia class

    • date resolved: 2020-12-17, date raised: 2020-12-16

  • 1.0.61 EXTENSION geneticOptimization add crossover (#501)

    • description: added crossover and improved parameters for GeneticOptimization

    • date resolved: 2020-12-14, date raised: 2020-12-14

  • 1.0.60 CHECK genetic algorithm (#497)

    • description: check if stochsearch or genetic algorithm has simpler interface

    • date resolved: 2020-12-14, date raised: 2020-12-10

  • 1.0.59 EXTENSION FilterSignal (#500)

    • description: put in signal module, make it working for 1D signals as well

    • date resolved: 2020-12-11, date raised: 2020-12-10

  • 1.0.58 EXTENSION FEMinterface GetNodesInOrthoCube (#492)

    • description: add function which returns all nodes lying in cube aligned with global coordinate system, using [pMin, pMax], with tolerance

    • date resolved: 2020-12-11, date raised: 2020-12-08

  • 1.0.57 EXTENSION FEMinterface GetNodesOnCylinder (#491)

    • description: add function which returns all nodes lying on specific cylinder, with tolerance

    • date resolved: 2020-12-11, date raised: 2020-12-08

  • 1.0.56 BUG key V gives error (#499)

    • description: keypress V for visualizationSettings dialog gives error

    • date resolved: 2020-12-10, date raised: 2020-12-10

  • 1.0.55 BUG SensorObject position (#498)

    • description: wrong position shown in sensor

    • date resolved: 2020-12-10, date raised: 2020-12-10

  • 1.0.54 TESTING test DEAP (#484)

    • description: test genetic optimization with DEAP

    • notes: too many parameters and too involved to simply include

    • date resolved: 2020-12-10, date raised: 2020-12-04

  • 1.0.53 BUG CheckForValidFunction (#493)

    • description: modify / add this check to setParameters; additional if for setting this to 0

    • date resolved: 2020-12-09, date raised: 2020-12-09

  • 1.0.52 BUG keypress crash (#490)

    • description: find out causes for crash in keyPress user function; find way to deactivate the user function (set it to 0)

    • date resolved: 2020-12-09, date raised: 2020-12-07

  • 1.0.51 IMPROVEMENT MainSystem includes (#389)

    • description: put SystemIntegrity item checks into separate file, to reduce includig MainSystem into every .cpp item file

    • date resolved: 2020-12-09, date raised: 2020-05-13

  • 1.0.50 EXTENSION solver flag prolong solution (#357)

    • description: add flag for solvers that current state at end of computation is set as initial state for next solving

    • notes: added into new python interface of solver

    • date resolved: 2020-12-09, date raised: 2020-03-11

  • 1.0.49 EXTENSION add gradient background (#489)

    • description: add according visualization.general option

    • date resolved: 2020-12-06, date raised: 2020-12-06

  • 1.0.48 BUG problem with coordinate sys (#488)

    • description: fix problems with drawing of coordinate system: text moves strangely and axes dissappear after rotation

    • date resolved: 2020-12-06, date raised: 2020-12-06

  • 1.0.47 EXTENSION draw world basis (#487)

    • description: add option to draw coordinate system at origin (world basis)

    • date resolved: 2020-12-06, date raised: 2020-12-06

  • 1.0.46 EXTENSION realtime (#486)

    • description: add flag to time integration to simulate in realtime

    • date resolved: 2020-12-05, date raised: 2020-12-05

  • 1.0.45 EXTENSION mouse coordinates (#485)

    • description: store mouse coordinates in renderState

    • date resolved: 2020-12-05, date raised: 2020-12-05

  • 1.0.44 EXTENSION mouse coordinates (#467)

    • description: show mouse coordinates in render window (without transformation)

    • date resolved: 2020-12-05, date raised: 2020-11-19

  • 1.0.43 EXTENSION key callback (#325)

    • description: add key callback function into graphics module to enable interactive settings, etc.; transfer latin letters, SHIFT, CTRL, ALT, 0-9,A-Z,.,SPACE as ASCII code

    • date resolved: 2020-12-05, date raised: 2020-01-26

  • 1.0.42 TESTING test accelerations (#460)

    • description: test GetODE2Coordinates_tt, nodal accelerations and rigidbody2D/3D accelerations

    • date resolved: 2020-12-04, date raised: 2020-11-12

  • 1.0.41 EXTENSION store model view (#482)

    • description: store renderState in exudyn.sys dictionary after exu.StopRenderer() for subsequent simulations

    • date resolved: 2020-12-03, date raised: 2020-12-03

  • 1.0.40 DOCU link examples (#478)

    • description: automatically add links to examples in thedoc

    • date resolved: 2020-12-03, date raised: 2020-12-02

  • 1.0.39 EXTENSION links in theDoc (#477)

    • description: add links between user functions, add labels to item sections

    • date resolved: 2020-12-03, date raised: 2020-12-02

  • 1.0.38 EXTENSION accelerations (#463)

    • description: add accelerations Outputvariable to Super elements

    • date resolved: 2020-12-03, date raised: 2020-11-18

  • 1.0.37 EXTENSION eigenvalue solver (#481)

    • description: add eigenvalue computation interface for mbs in python

    • date resolved: 2020-12-02, date raised: 2020-12-02

  • 1.0.36 EXTENSION python solver (#480)

    • description: add solver interfaces in python for MainSolverStatic and MainSolverImplicitSecondOrder, helping to retrieve solver data and to make solvers accessible for users

    • date resolved: 2020-12-02, date raised: 2020-12-02

  • 1.0.35 EXTENSION solver return (#479)

    • description: add return value to solvers and copy solver structures to mbs.sys variables after finishing

    • notes: added python interfaces and kept old cpp solvers

    • date resolved: 2020-12-02, date raised: 2020-12-02

  • 1.0.34 EXTENSION userfunctions (#469)

    • description: put user function generation in objectdefinition, with seperate U userfunction flag - this will automatically document the user function parameters (AND return values); this improves documentation and adds a unique interface in C++ using exception handling as well as GIL handling

    • date resolved: 2020-12-02, date raised: 2020-11-20

  • 1.0.33 DOCU graphicsDataUserFunction (#458)

    • description: add example to docu in ObjectGround and GenericODE2 and add more accurate docu to ALL python user functions

    • date resolved: 2020-12-02, date raised: 2020-11-10

  • 1.0.32 EXTENSION queue user functions (#428)

    • description: implement drawing user functions as global function similar to PyProcessQueue, in order to avoid messing up the CSystem and visualization modules

    • date resolved: 2020-12-02, date raised: 2020-06-26

  • 1.0.31 EXTENSION add RequireVersion (#476)

    • description: functionality to allow to add a simple check to see if the installed version meets the requirements

    • date resolved: 2020-11-30, date raised: 2020-11-30

  • 1.0.30 EXTENSION rolling disc ext (#475)

    • description: add force on ground and moving ground for ObjectJointRollingDisc

    • notes: needs to be tested further

    • date resolved: 2020-11-29, date raised: 2020-11-26

  • 1.0.29 CHECK auto compilation (#474)

    • description: check automatic compilation; check version in wheels; check linux wheels

    • notes: linux wheels can not be built with admin rights

    • date resolved: 2020-11-29, date raised: 2020-11-25

  • 1.0.28 EXTENSION no glfw option (#473)

    • description: add simple option in setup.py to deactivate glfw both in setup.py as well as in C++ part

    • date resolved: 2020-11-29, date raised: 2020-11-25

  • 1.0.27 EXTENSION GetVersionString (#457)

    • description: put into docu with pybindings

    • date resolved: 2020-11-29, date raised: 2020-11-07

  • 1.0.26 EXTENSION examples in utilities (#472)

    • description: activate lstlisting for examples

    • date resolved: 2020-11-25, date raised: 2020-11-25

  • 1.0.25 TESTING test WSL2 (#468)

    • description: test compilation on WSL2 - Windows subsystem for Linux

    • notes: WSL2 now used to automatically create linux wheels

    • date resolved: 2020-11-21, date raised: 2020-11-19

  • 1.0.24 BUG SC.GetSystem(..) (#465)

    • description: raises RuntimeError: should return reference instead of copy

    • date resolved: 2020-11-21, date raised: 2020-11-18

  • 1.0.20 CHANGE main/bin (#466)

    • description: remove main/bin from github and from Tools folder

    • date resolved: 2020-11-19, date raised: 2020-11-19

  • 1.0.19 EXTENSION processing module (#464)

    • description: create processing module for parameter variation and optimization using multiprocessing library

    • date resolved: 2020-11-18, date raised: 2020-11-18

  • 1.0.18 DOCU AVX Celeron problems (#462)

    • description: add info to documentation - FAQ AND common problems and installation instructions that CPUs without AVX support only work with 32bit version

    • date resolved: 2020-11-18, date raised: 2020-11-16

  • 1.0.17 EXTENSION resolved by: S. Holzinger lie group utilities (#459)

    • description: add documented lie group utilities to exudyn (python) lib

    • date resolved: 2020-11-11, date raised: 2020-11-11

  • 1.0.16 EXTENSION add item graph (#454)

    • description: add graph containing nodes, objects, etc.

    • date resolved: 2020-10-08, date raised: 2020-10-08

  • 1.0.15 EXTENSION systemdata.NumberOfSensors (#453)

    • description: add access function for systemdata.NumberOfSensors()

    • date resolved: 2020-10-08, date raised: 2020-10-08

  • 1.0.14 EXTENSION MT ngsolve (#449)

    • description: add NGsolve multithreading library (task manager)

    • notes: first tests made

    • date resolved: 2020-09-16, date raised: 2020-09-15

  • 1.0.13 CHANGE correct ODE2RHS (#330)

    • description: correct ODE2RHS to ODE2Terms in objects because it is left-hand-side

    • notes: changed object computation function from RHS to LHS, as it always computed the LHS (the system.cpp function ComputeODE2RHS then puts it to RHS)

    • date resolved: 2020-09-10, date raised: 2020-02-03

  • 1.0.12 CHECK check runtimeError (#435)

    • description: check if exception runtimeerror works for all catch cases (test in windows?)

    • date resolved: 2020-09-09, date raised: 2020-07-21

  • 1.0.11 CHANGE remove GetItemByName() (#445)

    • description: remove GetNodeByName, GetObjectByName, etc. from C++ interface; already disabled in python interface before

    • date resolved: 2020-09-08, date raised: 2020-09-08

  • 1.0.10 CHANGE Item::CallFunction (#288)

    • description: Disable Item::CallFunction functionality from EXUDYN; either outputvariables can be used, or some functions are automatically created including the documentation

    • notes: already removed from python interface earlier

    • date resolved: 2020-09-08, date raised: 2019-12-10

  • 1.0.9 EXTENSION SensorObject (#443)

    • description: add error message, if sensorobject is used for a body (and check if SensorBody excepts object other than body

    • notes: added test for SensorObject if attached to body

    • date resolved: 2020-09-04, date raised: 2020-09-03

  • 1.0.8 BUG difference MSC and setuptools (#442)

    • description: compilation with MSC and setuptools gives different results

    • notes: problem with VS2019 compilation of Eigen; resolved by removing VS2019 installation

    • date resolved: 2020-08-25, date raised: 2020-08-24

  • 1.0.7 EXTENSION auto create dirs (#431)

    • description: automatically create dictionaries if they do not exist

    • date resolved: 2020-08-25, date raised: 2020-07-01

  • 1.0.6 EXTENSION setuptools (#439)

    • description: use setuptools for installation

    • date resolved: 2020-08-17, date raised: 2020-08-13

  • 1.0.5 TESTING test pybind11_2020 (#381)

    • description: downloaded in Download folder

    • date resolved: 2020-08-17, date raised: 2020-05-06

  • 1.0.4 EXTENSION setup tools (#378)

    • description: use setup tools to install EXUDYN on local user accounts; use installed python version to decide which version to install

    • date resolved: 2020-08-17, date raised: 2020-05-04

  • 1.0.3 CHANGE remove WorkingRelease path (#441)

    • description: do not include WorkingRelease to sys.path any more, but require installation of modules

    • date resolved: 2020-08-14, date raised: 2020-08-14

  • 1.0.2 EXTENSION exudyn package (#440)

    • description: make a package with sub .py files in exudyn package - requires renaming of C++ module

    • date resolved: 2020-08-14, date raised: 2020-08-13

  • 1.0.1 EXTENSION UBUNTU (#438)

    • description: adapt setup.py and implementation for gcc and UBUNTU

    • date resolved: 2020-08-13, date raised: 2020-08-13

  • 1.0.0 BUG CheckSystemIntegrity (#434)

    • description: gives wrong node, marker, etc. numbers for some checks

    • date resolved: 2020-07-20, date raised: 2020-07-20

Version 0.1

  • 0.1.367 CHANGE #pragma once (#433)

    • description: remove #pragma once directives, not compatible with gcc

    • date resolved: 2020-07-20, date raised: 2020-07-20

  • 0.1.366 BUG FFRF object bug (#432)

    • description: wrong results in ObjectFFRF in case of refpos!=0

    • date resolved: 2020-07-02, date raised: 2020-07-02

  • 0.1.365 EXTENSION add stress modes (#429)

    • description: add additional modes in ObjectFFRFreducedOrder to visualize stresses and strains

    • date resolved: 2020-07-01, date raised: 2020-07-01

  • 0.1.364 EXTENSION visualization user function (#419)

    • description: add possibility of user function for visualization: is called on cSystem side to generate graphicsData lists or via a thread-safe callback

    • date resolved: 2020-06-26, date raised: 2020-05-29

  • 0.1.363 EXTENSION prestep py function (#371)

    • description: Add prestep function as function using mbs (MainSystem)

    • date resolved: 2020-06-24, date raised: 2020-04-10

  • 0.1.362 DOCU utilities docu (#284)

    • description: Add documentation for exudynUtilities.py

    • date resolved: 2020-06-24, date raised: 2019-12-07

  • 0.1.361 EXTENSION output variable connector (#259)

    • description: add consistent output variables for connectors

    • date resolved: 2020-06-24, date raised: 2019-08-30

  • 0.1.360 EXTENSION RollingDiscPenalty (#427)

    • description: implement RollingDisc model with penalty formulation and friction

    • date resolved: 2020-06-22, date raised: 2020-06-19

  • 0.1.359 EXTENSION RollingDisc (#426)

    • description: implement RollingDisc model

    • date resolved: 2020-06-22, date raised: 2020-06-19

  • 0.1.358 CHECK HasVelocityEquations() (#425)

    • description: check if HasVelocityEquations() is really needed

    • date resolved: 2020-06-19, date raised: 2020-06-19

  • 0.1.357 EXTENSION SuperElement gravity (#420)

    • description: add gravity to superelements

    • date resolved: 2020-06-09, date raised: 2020-06-03

  • 0.1.356 EXTENSION MarkerSuperElementReducedOrderRigidBody (#405)

    • description: Implement averaging multinode marker for position and orientation for reduced order elements

    • date resolved: 2020-06-09, date raised: 2020-05-21

  • 0.1.355 EXTENSION add STL import (#281)

    • description: add exudynGraphics function for STL faces import

    • date resolved: 2020-06-09, date raised: 2019-12-05

  • 0.1.354 EXTENSION contour maxValue (#422)

    • description: add second mode to contour auto range, which does not reduce the range

    • date resolved: 2020-06-07, date raised: 2020-06-07

  • 0.1.353 EXTENSION standard views (#421)

    • description: add key shortcuts for standard views

    • date resolved: 2020-06-07, date raised: 2020-06-07

  • 0.1.352 CHECK read only parameters (#418)

    • description: raise exception if read only values are attempted to be overwritten==> currently, read only parameters are ignored!

    • date resolved: 2020-06-01, date raised: 2020-05-28

  • 0.1.351 EXTENSION visualization shortnames (#417)

    • description: add shortnames, e.g., VMass1D for visualization objects

    • date resolved: 2020-06-01, date raised: 2020-05-27

  • 0.1.350 EXTENSION MarkerSuperElementPosition (#411)

    • description: cleanup MarkerSuperElementPosition Matrix objects and test

    • date resolved: 2020-06-01, date raised: 2020-05-25

  • 0.1.349 EXTENSION ObjectConnectorRelativeRotation (#408)

    • description: add connector with drive functionality, which constrains relative rotation (or translation) in the local frame of one Marker; use gear ratio + offset; enables gears, drives, etc.

    • date resolved: 2020-06-01, date raised: 2020-05-22

  • 0.1.348 EXTENSION MarkerSuperElementRigidBody (#404)

    • description: Implement averaging multinode maker for position and orientation

    • date resolved: 2020-06-01, date raised: 2020-05-21

  • 0.1.347 DOCU description (#395)

    • description: add latex description for MarkerSuperElementPosition

    • date resolved: 2020-06-01, date raised: 2020-05-16

  • 0.1.346 EXTENSION ObjectFFRFreducedOrder EP (#414)

    • description: add Euler Parameter constraint to ObjectFFRFreducedOrder

    • date resolved: 2020-05-29, date raised: 2020-05-26

  • 0.1.345 EXTENSION check accessFunctionTypes (#338)

    • description: add automatized marker/force/accessFunctionType checks using the fact that same bits are used in types

    • date resolved: 2020-05-28, date raised: 2020-02-18

  • 0.1.344 EXTENSION check markers (#329)

    • description: add integrity check if node/body implements necessary access functions for marker

    • date resolved: 2020-05-28, date raised: 2020-02-02

  • 0.1.342 BUG CNodeRigidBody2D bug (#415)

    • description: CNodeRigidBody2D misses OutputVariables Rotation, RotationMatrix, AngularVelocity(Local)

    • date resolved: 2020-05-26, date raised: 2020-05-26

  • 0.1.341 EXTENSION implement FFRF tisserand frame (#407)

    • description: implement Phit.T*M*c_F=0 and xRefTilde.T*M*c_F=0 as FFRF constraint for rigid body motion

    • notes: only possible as ConnectorCoordinateVector constraint externally

    • date resolved: 2020-05-26, date raised: 2020-05-22

  • 0.1.340 EXTENSION add 1D nodes and objects (#388)

    • description: add 1D nodes/objects for drive-train applications; add optional visualization offset position p0, rotation A0 and transformation q->(u3D, theta3d), which transforms the 1D coordinate to 3D translation and rotation

    • date resolved: 2020-05-26, date raised: 2020-05-08

  • 0.1.339 EXTENSION add velocity markers (#387)

    • description: add MarkerNodeRotationCoordinate (velocity level=angular velocity), with option for local frame and for MarkerRotation matrix, this enables to couple single (angular) velocities and to couple drives, etc. between 1D objects and 3D objects

    • date resolved: 2020-05-26, date raised: 2020-05-08

  • 0.1.338 EXTENSION ConnectorCoordinateVector (#412)

    • description: implement coordinate vector constraint applied to a body; can be used as generic joint (with user function)

    • date resolved: 2020-05-25, date raised: 2020-05-25

  • 0.1.337 EXTENSION MarkerObjectCoordinates (#409)

    • description: add new Marker MarkerObjectCoordinates, which applies to all coordinates of an object; this enables generic constraints on object coordinates (nodal coordinates may be added in future)

    • date resolved: 2020-05-25, date raised: 2020-05-24

  • 0.1.336 EXTENSION add NGsolve interface (#402)

    • description: add NGsolve to FEMinterface to create mechanical body from geo, some options; create M, K, nodeList, elements and surface; add surfaces for specific boundaries

    • date resolved: 2020-05-22, date raised: 2020-05-21

  • 0.1.335 DOCU ObjectContactFrictionCircleCable2D (#399)

    • description: ObjectContactFrictionCircleCable2D: contact stiffness wrong comment

    • date resolved: 2020-05-22, date raised: 2020-05-20

  • 0.1.334 IMPROVEMENT clean up ObjectGenericODE2 (#393)

    • description: remove ffrf from ObjectGenericODE2

    • date resolved: 2020-05-21, date raised: 2020-05-16

  • 0.1.333 EXTENSION FEM interface (#398)

    • description: add FEMinterface python class for mesh and system matrix import, surface mesh extraction, mode computation, export to ObjectFFRF etc.

    • date resolved: 2020-05-17, date raised: 2020-05-16

  • 0.1.332 TESTING tests FFRF (#397)

    • description: add TestModels for FFRF and FFRFreducedOrder

    • date resolved: 2020-05-17, date raised: 2020-05-16

  • 0.1.331 EXTENSION MarkerSuperElementRigidReducedOrder (#392)

    • description: add MarkerSuperElementRigidReducedOrder for reducedOrder objects

    • date resolved: 2020-05-17, date raised: 2020-05-16

  • 0.1.330 EXTENSION add MarkerSuperElementPosition (#391)

    • description: add MarkerSuperElementPosition

    • date resolved: 2020-05-16, date raised: 2020-05-16

  • 0.1.329 EXTENSION LinkedDataMatrix (#125)

    • description: Implement LinkedDataMatrix

    • date resolved: 2020-05-16, date raised: 2019-05-13

  • 0.1.328 EXTENSION add superelement (#386)

    • description: add intermediate object, which offers access functions for node-position/velocity,/jacobian; object redirects either to nodes or uses the mode basis (FFRF) to compute position of virtual node

    • date resolved: 2020-05-15, date raised: 2020-05-07

  • 0.1.327 EXTENSION add FFRF object (#382)

    • description: enabling full and reduced set of coordinates

    • date resolved: 2020-05-15, date raised: 2020-05-06

  • 0.1.326 EXTENSION Implement reduced FFRF (#368)

    • description: Implement reduced FFRF in GenericODE2 by adding a transformation matrix

    • date resolved: 2020-05-15, date raised: 2020-04-10

  • 0.1.325 EXTENSION auto testSuite (#379)

    • description: integrate test suite into workflow for generating WorkingReleaseXYZ; copy output.log to WorkingRelease folders

    • date resolved: 2020-05-06, date raised: 2020-05-05

  • 0.1.324 EXTENSION Implement FFRF (#367)

    • description: Implement FFRF in GenericODE2

    • notes: internal folder only

    • date resolved: 2020-05-06, date raised: 2020-04-10

  • 0.1.323 EXTENSION testSuite (#377)

    • description: integrate test suite into workflow for generating WorkingReleaseXYZ; copy output.log to WorkingRelease folders; make directory with named (versionNr) logs to quickly find problems

    • date resolved: 2020-05-05, date raised: 2020-05-04

  • 0.1.322 EXTENSION user functions catch (#376)

    • description: catch exceptions of user functions, such that uunidentified errors in time integration can be located

    • date resolved: 2020-04-25, date raised: 2020-04-24

  • 0.1.321 CHECK loadVectorUserFunction (#373)

    • description: loadVectorUserFunction does not work with np.array as return type

    • notes: changed std::function return type from StdVector3D(=std::array) to StdVector(=std::vector), which works automatically with numpy arrays

    • date resolved: 2020-04-24, date raised: 2020-04-14

  • 0.1.320 CHECK euler parameters (#336)

    • description: check input of euler paramters: is norm of EP given for 1-e8

    • date resolved: 2020-04-24, date raised: 2020-02-17

  • 0.1.319 EXTENSION rigid body COM (#375)

    • description: add center of mass COM to rigid body; extend equations of motion

    • date resolved: 2020-04-22, date raised: 2020-04-22

  • 0.1.318 CHECK check GenericJoint (#361)

    • description: check generic joint jacobian: in case that not all translational components are fixed, the jacobian entries should be excluded

    • date resolved: 2020-04-22, date raised: 2020-04-09

  • 0.1.317 EXTENSION add LoadController (#339)

    • description: add possibility to add controllers with sensors as input and a user python function

    • date resolved: 2020-04-22, date raised: 2020-02-18

  • 0.1.316 EXTENSION Implement DH parameters (#370)

    • description: use DH-parameters to set up link relative to previous body

    • date resolved: 2020-04-20, date raised: 2020-04-10

  • 0.1.315 EXTENSION SetRenderState (#374)

    • description: add function SetRenderState in analogy to GetRenderState in order to set previously saved openGL state

    • date resolved: 2020-04-14, date raised: 2020-04-14

  • 0.1.314 EXTENSION 3D rotation (#360)

    • description: make incremental rotation with right-mouse-button relative to current configuration

    • date resolved: 2020-04-14, date raised: 2020-03-20

  • 0.1.313 EXTENSION Add FFRF GenericODE2 (#366)

    • description: Add FFRF mode to GenericODE2, using the first node as RigidBodyNode to represent the floating reference frame

    • date resolved: 2020-04-11, date raised: 2020-04-10

  • 0.1.312 EXTENSION add SphericalJoint (#365)

    • description: add separate spherical joint with option to constrain one of the 3 axes

    • date resolved: 2020-04-10, date raised: 2020-04-10

  • 0.1.311 EXTENSION add multinodal marker (#364)

    • description: add multinodal marker with weights for GenericODE2 objects

    • date resolved: 2020-04-10, date raised: 2020-04-10

  • 0.1.310 EXTENSION draw springs 3d (#363)

    • description: add 3d helical spring drawing

    • date resolved: 2020-04-10, date raised: 2020-04-10

  • 0.1.309 EXTENSION unique drawing (#362)

    • description: make unique line and 3d drawing for markers, sensors and loads

    • date resolved: 2020-04-10, date raised: 2020-04-10

  • 0.1.308 EXTENSION vis nodes (#359)

    • description: add option to visualize nodes as spheres

    • date resolved: 2020-04-10, date raised: 2020-03-20

  • 0.1.307 EXTENSION vis nodes (#358)

    • description: visualize 3D nodes as 3 circles

    • date resolved: 2020-04-10, date raised: 2020-03-20

  • 0.1.306 CHECK ALEANCFCable2D mass terms (#297)

    • description: check if mass terms in ALEANCFCable2D (9th column/row)

    • notes: terms are correct, but lead to instability at high velocities

    • date resolved: 2020-04-10, date raised: 2019-12-16

  • 0.1.304 EXTENSION sensor tutorial (#356)

    • description: add sensor to tutorial

    • date resolved: 2020-03-13, date raised: 2020-03-08

  • 0.1.303 TESTING benchmark problems (#302)

    • description: implement benchmark problems of iftomm web page and from papers Bruls/Arnold, Terze, etc.

    • date resolved: 2020-03-08, date raised: 2019-12-26

  • 0.1.302 EXTENSION exceptions pybind (#352)

    • description: check whether lambda functions do not catch appropriately exceptions in pybind ==> use manual try catch mechanisms to catch exceptions

    • date resolved: 2020-03-06, date raised: 2020-03-03

  • 0.1.301 CHECK check ANCFALE (#328)

    • description: check if access functions implemented correctly: local jacobians include only 3x8 instead of 3x9 components?

    • date resolved: 2020-03-06, date raised: 2020-02-02

  • 0.1.300 EXTENSION AddItem (#353)

    • description: unify AddItem(dict/py::object) into one function

    • date resolved: 2020-03-05, date raised: 2020-03-04

  • 0.1.299 EXTENSION exudynFast (#351)

    • description: name all versions exudyn, because of unresolvable conflicts in utilities includes

    • date resolved: 2020-03-05, date raised: 2020-03-03

  • 0.1.298 EXTENSION Add ODE2equations (#350)

    • description: add ObjectODE2equations with GenericODE2/NodePoint/NodePoint2D nodes

    • date resolved: 2020-03-05, date raised: 2020-03-02

  • 0.1.297 EXTENSION GetObjectOutputBody (#348)

    • description: GetObjectOutputBody and similar functions shall not be callable if system is inconsistent

    • date resolved: 2020-03-05, date raised: 2020-02-24

  • 0.1.296 CHECK evaluate autodiff (#346)

    • description: evaluate netgen autodiff and autodiff.github.io for straightforward auto-differentiation of ODE2RHS functions

    • date resolved: 2020-03-05, date raised: 2020-02-23

  • 0.1.293 EXTENSION time in connector UF (#345)

    • description: add time to connector user functions, to allow time dependent trajectories in spring dampers

    • date resolved: 2020-02-23, date raised: 2020-02-22

  • 0.1.292 EXTENSION docu examples+equations (#335)

    • description: add multiline equations section and example section in the object description

    • date resolved: 2020-02-23, date raised: 2020-02-16

  • 0.1.291 EXTENSION GenericRigidBodyJoint2D (#309)

    • description: Add generic joint with local transformation matrix of marker1; enable fixed or free ux,uy and phi in the joint, relative to marker1 coordinate system

    • date resolved: 2020-02-23, date raised: 2020-01-10

  • 0.1.290 EXTENSION Std::array (#287)

    • description: check if performance of python interfaces can be improved using std::array; add typdefs for std::array<Real,3>, etc.

    • date resolved: 2020-02-23, date raised: 2019-12-09

  • 0.1.289 EXTENSION extend CoordinateConstraint (#343)

    • description: extend CoordinateConstraint user function: value0/1, value_t0/1, factorValue1

    • notes: NOT COMPLETED: do this extension instead in a separate user coordinate constraint as it requires also the jacobians to be computed

    • date resolved: 2020-02-22, date raised: 2020-02-20

  • 0.1.288 CHANGE initialDisplacements (#344)

    • description: change the misleading name initialDisplacements to initialCoordinates in all nodes for consitency reasons

    • date resolved: 2020-02-21, date raised: 2020-02-21

  • 0.1.287 EXTENSION add load sensor (#342)

    • description: add load sensor which measures loads especially if modified in user defined loads

    • date resolved: 2020-02-19, date raised: 2020-02-19

  • 0.1.286 EXTENSION add bodyFixed loads (#341)

    • description: add bodyFixed (local / follower) forces and torques

    • date resolved: 2020-02-19, date raised: 2020-02-19

  • 0.1.285 EXTENSION bodyFixed force (#340)

    • description: use markers bodyFixed property to realize local forces - make bodyFixed globally available in markers and add to computation of loads in csystem.cpp

    • notes: moved bodyFixed property to loads; see issue #341

    • date resolved: 2020-02-19, date raised: 2020-02-19

  • 0.1.284 EXTENSION visualize sensors (#324)

    • description: add visualization to sensors (draw as circle with cross)

    • date resolved: 2020-02-18, date raised: 2020-01-25

  • 0.1.283 EXTENSION exudynUtilities (#301)

    • description: split up exudynUtilities into separate files

    • date resolved: 2020-02-14, date raised: 2019-12-26

  • 0.1.282 EXTENSION add RigidBodySpringDamper (#334)

    • description: add a generalization for CartesianSpringDamper, using local coordinate systems and coupling all local translations and rotations

    • date resolved: 2020-02-12, date raised: 2020-02-12

  • 0.1.281 CHECK PyError in C++ (#319)

    • description: check why PyError is not working any more properly

    • notes: did not show up again

    • date resolved: 2020-02-12, date raised: 2020-01-16

  • 0.1.280 EXTENSION Add generic node ODE2 (#311)

    • description: generic node with n ODE2 coordinates

    • date resolved: 2020-02-12, date raised: 2020-01-10

  • 0.1.279 EXTENSION GenericRigidBodyJoint3D (#310)

    • description: Add generic joint with local transformation matrix of marker1; enable fixed or free tranlatory motion (ux,uy,uz) and rotations (phix,phiy,phiz) in the joint, relative to marker1 coordinate system

    • date resolved: 2020-02-12, date raised: 2020-01-10

  • 0.1.278 EXTENSION time in constraints (#304)

    • description: consistently add time to constraint evaluation; add flag to mark time dependency of constraints (influence on velocity level and on initial conditions)

    • date resolved: 2020-02-12, date raised: 2019-12-28

  • 0.1.277 CHECK correct Rigid3DEP (#331)

    • description: correct gyroscopic terms and add test suite example

    • date resolved: 2020-02-03, date raised: 2020-02-03

  • 0.1.276 EXTENSION ANCF beam (#317)

    • description: add rigid body access functions for ANCF elements

    • date resolved: 2020-02-02, date raised: 2020-01-15

  • 0.1.275 EXTENSION visualizationSettings (#327)

    • description: convert system structures to dictionary and back; include type information

    • date resolved: 2020-01-31, date raised: 2020-01-27

  • 0.1.274 BUG python single line (#326)

    • description: fix possible threading issues of python single command execute

    • date resolved: 2020-01-31, date raised: 2020-01-27

  • 0.1.273 EXTENSION pout, threads (#146)

    • description: Check if pout is threadsafe ==> introduce a mutex

    • date resolved: 2020-01-31, date raised: 2019-05-25

  • 0.1.272 EXTENSION node ltg (#322)

    • description: add python access function to retrieve node local to global ODE2 and AE coordinates

    • notes: added reference to starting index in global coordinate vector

    • date resolved: 2020-01-25, date raised: 2020-01-22

  • 0.1.271 EXTENSION consistent shut down (#305)

    • description: Perform consistent shut down of exudyn in case of PyError(): stop renderer before raising Py or SysError()

    • notes: but errors which occur directly in python cannot be catched

    • date resolved: 2020-01-25, date raised: 2019-12-28

  • 0.1.270 DOCU add docu for solvers (#255)

    • description: add documentation about flags, formulas, error control, jacobians and about the steps in the solvers

    • date resolved: 2020-01-25, date raised: 2019-08-28

  • 0.1.269 EXTENSION IntegrityNodeCheck (#227)

    • description: add integrity check that correct node type is supplied to object; use an additional function for RequiredNodeType(); use none for special elements or mixed node types –> check needs to be put into element specific checks

    • date resolved: 2020-01-25, date raised: 2019-07-13

  • 0.1.268 EXTENSION Sensors (#216)

    • description: Add sensor concept and add simple sensors for postprocessing; e.g. add simple sensors to cSystemData, which are written to prescribed sensor file or global sensor file; sensors have [marker, OutputVariableType, coordinate1, coordinate2=0]

    • date resolved: 2020-01-25, date raised: 2019-06-29

  • 0.1.267 BUG RenderWindow focus (#321)

    • description: add options to resolve problem of focus/showing of render window in spyer/ipython

    • notes: solved: change sypder preferences, see FAQ

    • date resolved: 2020-01-22, date raised: 2020-01-22

  • 0.1.266 EXTENSION GetParameter (#320)

    • description: in autogenerated object/node GetNodeParameter(..): change return value to py::in_(invalid index…) in order to reduce error message in spyder

    • date resolved: 2020-01-22, date raised: 2020-01-16

  • 0.1.265 EXTENSION Add try/catch (#316)

    • description: add try/catch to main python interface functions; add in all autogenerated functions

    • date resolved: 2020-01-22, date raised: 2020-01-10

  • 0.1.264 EXTENSION sparse init acc (#318)

    • description: compute initial accelerations with sparse solver

    • date resolved: 2020-01-21, date raised: 2020-01-15

  • 0.1.263 EXTENSION Export M, D, K, Cq (#268)

    • description: Make (linearized/constant) mass, damping, stiffness and constraint matrices available in python

    • date resolved: 2020-01-08, date raised: 2019-10-10

  • 0.1.262 EXTENSION Export residuals (#269)

    • description: Make residuals available in python

    • date resolved: 2020-01-06, date raised: 2019-10-10

  • 0.1.261 EXTENSION PybindMatrix (#190)

    • description: Use Pybind to bind matrices and vectors to numpy (simplify interface); copy all matrix/vector contents for now; only lateron, an option without copying would be nice; link to pybind example see https://github.com/pybind/pybind11/blob/master/tests/test_buffers.cpp as well as the pybind reference section about numpy

    • date resolved: 2020-01-06, date raised: 2019-06-16

  • 0.1.259 EXTENSION PySolver (#276)

    • description: Link data structures and functions of solver to python; use new MainSolver object for that reason

    • date resolved: 2020-01-05, date raised: 2019-12-01

  • 0.1.258 EXTENSION SetOutputToConsole (#290)

    • description: SetOutputToConsole(flag): add functionality to write activate/deactivate console output

    • date resolved: 2020-01-04, date raised: 2019-12-13

  • 0.1.257 EXTENSION SetOutputToFile (#289)

    • description: SetOutputToFile(flage, fileName): add functionality to write all console output to file

    • date resolved: 2020-01-04, date raised: 2019-12-13

  • 0.1.256 DOCU Add flowcharts (#307)

    • description: add flowcharts for items, exu,SC,mbs,systemData, … and solver

    • date resolved: 2019-12-31, date raised: 2019-12-30

  • 0.1.255 EXTENSION WaitForUserToContinue (#306)

    • description: check if renderer is running; if not, the functions WaitForUserToContinue and WaitForRenderEngineStopFlag will do nothing or wait for console input

    • date resolved: 2019-12-31, date raised: 2019-12-28

  • 0.1.254 EXTENSION add show constraints mode (#308)

    • description: add mode to show constraints with key “c” in openGL renderer

    • date resolved: 2019-12-30, date raised: 2019-12-30

  • 0.1.253 EXTENSION initial accelerations (#299)

    • description: consistently compute initial accelerations for Newmark (and approx. for generalizedalpha

    • date resolved: 2019-12-27, date raised: 2019-12-17

  • 0.1.252 EXTENSION exudyn rules (#300)

    • description: add name conventions, code style and rules, etc. to docu

    • date resolved: 2019-12-26, date raised: 2019-12-25

  • 0.1.251 IMPROVEMENT cleanup solvers (#256)

    • description: cleanup and unify initialization and computation iterations for solvers; add solver data structure accessible via pybind

    • date resolved: 2019-12-25, date raised: 2019-08-28

  • 0.1.250 EXTENSION CircleContact (#254)

    • description: pre-check possible region of contact

    • date resolved: 2019-12-25, date raised: 2019-08-28

  • 0.1.249 EXTENSION RecordFrames (#244)

    • description: grap openGL snapshot with glReadPixels and store frame to image file

    • date resolved: 2019-12-25, date raised: 2019-08-22

  • 0.1.248 CHECK Check diff rel eps (#208)

    • description: Check why the differentiation parameter needs to be very small 1e-11 in case of larger system sizes

    • notes: might be solved with new jacobianAE and new solvers

    • date resolved: 2019-12-25, date raised: 2019-06-28

  • 0.1.247 EXTENSION solver step reduction (#298)

    • description: add step reduction if Newton / discIt fails to solver

    • date resolved: 2019-12-18, date raised: 2019-12-16

  • 0.1.246 EXTENSION new static solver (#295)

    • description: add new static solver and test it

    • date resolved: 2019-12-17, date raised: 2019-12-16

  • 0.1.245 CHECK generalized alpha Newton (#245)

    • description: revise newton method in time integration solver: modified and full newton are not consistent; time integration continues even in case of errors, etc.

    • date resolved: 2019-12-17, date raised: 2019-08-23

  • 0.1.244 EXTENSION ANCFCable2DALE (#296)

    • description: additional flag for moving mass terms

    • date resolved: 2019-12-16, date raised: 2019-12-16

  • 0.1.243 EXTENSION improve impl. solver (#294)

    • description: compute correct initial conditions, add new convergence criteria (residuum/nCoords and newtonDecrement.norm2/nCoords)

    • date resolved: 2019-12-15, date raised: 2019-12-15

  • 0.1.242 EXTENSION solver_data (#275)

    • description: restructure solver data structure: computation data, temporary data, system matrices, functions

    • date resolved: 2019-12-15, date raised: 2019-12-01

  • 0.1.241 CHANGE disc.iteration (#293)

    • description: discontinuous iteration in generalized alpha: verbose wrongly used; should not have affected the solution

    • date resolved: 2019-12-14, date raised: 2019-12-14

  • 0.1.240 BUG time steps (#292)

    • description: Wrong time is used for time integration when evaluating loads, etc.; need to change time from beginning of step to end of step for evaluation of RHS

    • date resolved: 2019-12-13, date raised: 2019-12-13

  • 0.1.239 BUG generalized alpha (#291)

    • description: discontinuous iteration is is not initialized for algorithmic acceleration

    • date resolved: 2019-12-13, date raised: 2019-12-13

  • 0.1.238 CHANGE GetAccessFunctionBody (#187)

    • description: Use ResizableMatrix in GetAccessFunctionBody and Resizable Vector in GetOutputVariableBody; add templated fill-in function to ResizableVector/Matrix to be able to copy data more easy from other types

    • date resolved: 2019-12-11 13:27, date raised: 2019-06-13

  • 0.1.237 EXTENSION split marker/load (#99)

    • description: split Marker and Load into .h and .cpp AND reduce dependencies on Nodes, body, etc.

    • date resolved: 2019-12-11, date raised: 2019-04-01

  • 0.1.236 EXTENSION link (#6)

    • description: link to matrix/vector classes to Eigen OR MKL solvers

    • date resolved: 2019-12-11, date raised: 2019-04-01

  • 0.1.235 CHECK check visualization (#286)

    • description: Check visualization of items, specifically of nodes and objects: graphicsdata should use the AddBodyGraphicsData(…) function for rigid body transformation

    • date resolved: 2019-12-10, date raised: 2019-12-07

  • 0.1.234 EXTENSION CqTLambda (#235)

    • description: ComputeODE2RHS (=CqT*lambda) based on single constraint object jacobians instead of global matrix multiply

    • date resolved: 2019-12-09, date raised: 2019-08-19

  • 0.1.233 EXTENSION SuperLU (#158)

    • description: Link SuperLU to linalg

    • date resolved: 2019-12-09, date raised: 2019-05-28

  • 0.1.232 EXTENSION EigenTriple (#157)

    • description: Add Eigentriple to mass matrix and jacobian computation

    • date resolved: 2019-12-09, date raised: 2019-05-28

  • 0.1.231 EXTENSION Joints (#155)

    • description: Add 2D spherical and prismatic joint

    • date resolved: 2019-12-09, date raised: 2019-05-28

  • 0.1.230 BUG rigidbody2D (#285)

    • description: TriangleList does not work

    • date resolved: 2019-12-07, date raised: 2019-12-07

  • 0.1.229 EXTENSION relativ paths import (#282)

    • description: use relative paths for import of WorkingRelease and TestModels

    • date resolved: 2019-12-07, date raised: 2019-12-07

  • 0.1.228 CHECK referenceCoordsRigid2D (#271)

    • description: check whether all reference coordinates in NodeRigid2D are correctly considered

    • date resolved: 2019-12-07, date raised: 2019-10-19

  • 0.1.227 EXTENSION add OpenGL settings (#280)

    • description: add settings for lights, material, normals and faces

    • date resolved: 2019-12-05, date raised: 2019-12-05

  • 0.1.226 EXTENSION add .py cube and cylinder (#279)

    • description: add functions in EXUDYN utilities for creation of 3D cube and cylinder with GLTriangles

    • date resolved: 2019-12-05, date raised: 2019-12-05

  • 0.1.225 EXTENSION Graphics Faces (#265)

    • description: Add triangular faces for 3D graphics

    • date resolved: 2019-12-05, date raised: 2019-10-10

  • 0.1.224 EXTENSION PyFunctions test (#278)

    • description: Test PyFunctions for SpringDamper, CoordinateSpringDamper, CoordinateConstraint and CoordinateLoad

    • date resolved: 2019-12-02, date raised: 2019-12-01

  • 0.1.223 EXTENSION PyFunctions (#277)

    • description: finalize PyFunctions for SpringDamper, CoordinateSpringDamper, CoordinateConstraint and CoordinateLoad

    • date resolved: 2019-12-02, date raised: 2019-12-01

  • 0.1.222 EXTENSION SparseLU (#274)

    • description: Add sparse matrices and sparse solver to static and dynamic solvers

    • date resolved: 2019-12-01, date raised: 2019-11-14

  • 0.1.221 EXTENSION constraint action (#273)

    • description: Add constraint action forces $Cq^T \cdot lambda$ via a function in csystem; eliminates need for computation of separate matrix during computation

    • date resolved: 2019-12-01, date raised: 2019-11-14

  • 0.1.220 EXTENSION Intro to theDoc (#270)

    • description: write introductory sections and tutorials for theDoc

    • date resolved: 2019-12-01, date raised: 2019-10-19

  • 0.1.219 EXTENSION GitLab (#267)

    • description: Put EXUDYN on UIBK/GitLab

    • date resolved: 2019-12-01, date raised: 2019-10-10

  • 0.1.218 EXTENSION use (#86)

    • description: use pybind/functional.h (see pybind11.readthedocs.io) to: use python functions / classes in C++; also use classes to define functions (+parameters); user defined python objects!!!; see refToFunctionsClasses.py

    • date resolved: 2019-12-01, date raised: 2019-04-01

  • 0.1.217 EXTENSION Rigid 3D (#264)

    • description: include rigid body, add graphics

    • date resolved: 2019-11-26, date raised: 2019-10-10

  • 0.1.216 BUG maximumSolutionNorm (#272)

    • description: changed default value for maximum solution norm from 1e10 to 1e38, because it is the square norm (no square root!) and was easily exceeded with values u (or v) larger than 100000; now a scalar value can be up to 1e19, before the Newton method is stopped

    • notes: new limit is 1e38 for compatibility with float

    • date resolved: 2019-11-08, date raised: 2019-11-08

  • 0.1.215 BUG correct unit tests (#266)

    • description: check 2 failures in unit tests

    • notes: small errors in tests 2 and 7 fixed by updating the reference values in the 1e-12 - 1e-9 range

    • date resolved: 2019-10-17, date raised: 2019-10-10

  • 0.1.214 EXTENSION ANCF damping (#263)

    • description: finish bending damping

    • date resolved: 2019-10-17, date raised: 2019-10-10

  • 0.1.213 EXTENSION python generator (#262)

    • description: add specific flag to autogenerated files, which detects if files have been changed or not

    • date resolved: 2019-10-10, date raised: 2019-09-12

  • 0.1.212 EXTENSION CircleContact2D (#230)

    • description: add friction

    • date resolved: 2019-09-12, date raised: 2019-07-23

  • 0.1.211 EXTENSION color bar (#257)

    • description: add color bar for contour plots

    • date resolved: 2019-08-30, date raised: 2019-08-30

  • 0.1.210 EXTENSION outputvariables (#253)

    • description: add new autogenerated output variables to all objects

    • date resolved: 2019-08-30, date raised: 2019-08-28

  • 0.1.209 EXTENSION PostProcessing (#231)

    • description: Add contour plot and settings - must be same as in sensors

    • date resolved: 2019-08-30, date raised: 2019-07-23

  • 0.1.208 EXTENSION switching sliding joint (#251)

    • description: add sliding joint example with switching activeConnector flag and relocation of sliding body

    • date resolved: 2019-08-28, date raised: 2019-08-25

  • 0.1.207 EXTENSION DiscontinuousIteration (#215)

    • description: Add discontinuous iteration to dynamic solvers; also incorporate restarting of Newton by adding data variables

    • date resolved: 2019-08-28, date raised: 2019-06-28

  • 0.1.206 EXTENSION Jacobian (#180)

    • description: Add jacobian computation for constraints based on markers and objects/nodes jacobians

    • date resolved: 2019-08-26, date raised: 2019-06-11

  • 0.1.205 BUG test suite graphics fails (#250)

    • description: multiple use of graphics in testsuite leads to crashes; inconsistent cSystem and vSystem containers; check mbs.Reset() function

    • notes: added missing call to visualizationSystemData.Reset() in mbs.Reset()

    • date resolved: 2019-08-25, date raised: 2019-08-25

  • 0.1.204 EXTENSION user stopflag python (#249)

    • description: add read and write access to stopSimulation flag in python; this allows to interrupt python loops - e.g. for static loading or for animation

    • date resolved: 2019-08-25, date raised: 2019-08-25

  • 0.1.203 EXTENSION visualize solution (#248)

    • description: set visualization state and time with pybind interface and send renderer update flag

    • date resolved: 2019-08-25, date raised: 2019-08-25

  • 0.1.202 EXTENSION animateSolution (#247)

    • description: load solution file and consecutively set visualization state to loaded states; implement in python

    • date resolved: 2019-08-25, date raised: 2019-08-25

  • 0.1.201 EXTENSION TimeIntegrationCPU (#240)

    • description: add CPU statistics accoding to static solver (with common data structure) to time integration; this will be needed to check performance of sparse matrix versions

    • date resolved: 2019-08-25, date raised: 2019-08-21

  • 0.1.200 EXTENSION LoadSolution (#232)

    • description: Add functionality to load solution from coordinates solution file

    • date resolved: 2019-08-25, date raised: 2019-07-23

  • 0.1.199 BUG ActivateConnector (#246)

    • description: Error in Newton / time integration with pure algebraic equations (CoordinateConstraint with activateConnector=False)

    • date resolved: 2019-08-23, date raised: 2019-08-23

  • 0.1.198 EXTENSION Vactive (#243)

    • description: consistently integrate visualization active flag in UpdateGraphics for all items

    • date resolved: 2019-08-23, date raised: 2019-08-22

  • 0.1.197 EXTENSION MarkerDataComp (#242)

    • description: Unify markerData computation in CSystem and in GetOutputVariableConnector at different places using a CSystem function

    • notes: not fully checked

    • date resolved: 2019-08-22, date raised: 2019-08-22

  • 0.1.196 EXTENSION Get/SetParameters (#233)

    • description: add functionality to set single parameters of items via pybind interface

    • date resolved: 2019-08-22, date raised: 2019-07-23

  • 0.1.195 EXTENSION PybindInterface (#239)

    • description: Complete pybind interfaces for systemData, version, …

    • date resolved: 2019-08-21, date raised: 2019-08-21

  • 0.1.194 EXTENSION JacobianODE2RHS_t (#238)

    • description: add object-wise computation to NumericalJacobianODE2RHS_t in System.cpp

    • date resolved: 2019-08-21, date raised: 2019-08-21

  • 0.1.193 EXTENSION CoordinateSpringDamper (#237)

    • description: add new scalar (coordinate) spring damper for action on arbitrary objects; include dry friction as option

    • date resolved: 2019-08-21, date raised: 2019-08-20

  • 0.1.192 EXTENSION LoadCoordinate (#221)

    • description: Add a load which is attached to a single MarkerCoordinate

    • date resolved: 2019-08-21, date raised: 2019-07-04

  • 0.1.191 CHECK ResizableMatrix (#131)

    • description: Investigate casting between Matrix and ResizableMatrix … check assignement operator (should it work?); implicit casting should be avoided because of memory allocation ==> use only explicit CopyFrom(Matrix)

    • date resolved: 2019-08-21, date raised: 2019-05-17

  • 0.1.190 EXTENSION IssueTracker (#236)

    • description: add date, release and version (=number of resolved issues) into issues tracker

    • date resolved: 2019-08-20, date raised: 2019-08-20

  • 0.1.189 CHECK IntegrityMarkerCheck (#234)

    • description: Add check that correct markertype is used: e.g. BodyRigid for torque or CoordinateMarker, etc.

    • date resolved: 2019-08-19, date raised: 2019-08-19

  • 0.1.188 EXTENSION MarkerNodeCoordinate (#224)

    • description: Add Integrity check for valid coordinate number

    • date resolved: 2019-08-19, date raised: 2019-07-08

  • 0.1.187 EXTENSION RequestedMarkerType (#222)

    • description: Add RequestedMarkerType check to SystemIntegrity checks; specific marker type checks (e.g. SlidingJoint) are done in the element-specific checks ==> requestedMarkertype=None

    • date resolved: 2019-08-19, date raised: 2019-07-06

  • 0.1.186 EXTENSION add args (#92)

    • description: add args to pybind interface: m.def(“add”, &add, “A function which adds two numbers”, py::arg(“i”) = 1, py::arg(“j”) = 2);

    • date resolved: 2019-08-19, date raised: 2019-04-01

  • 0.1.185 EXTENSION Objects: (#91)

    • description: Objects: add to GetOutputVariableTypes(): GetAccessibleMarkerTypes() ==> returns all MarkerFlags, which can be used with body …

    • notes: already available via GetAccessFunctionTypes and GetOutputVariableTypes

    • date resolved: 2019-08-19, date raised: 2019-04-01

  • 0.1.184 EXTENSION Add (#85)

    • description: Add Test suite for Python side (test all interface functions)

    • date resolved: 2019-08-19, date raised: 2019-04-01

  • 0.1.183 CHECK TimeIntNewton (#228)

    • description: Check why modified Newton does not converge as full Newton

    • date resolved: 2019-08-18, date raised: 2019-07-15

  • 0.1.182 CHECK Pendulum (#223)

    • description: Pendulum example with constraint does not work any more. check jacobian and algebraic equations

    • date resolved: 2019-08-18, date raised: 2019-07-08

  • 0.1.181 EXTENSION AxiallyMovingJoint (#229)

    • description: add prescribed sliding of point along ALECable2D

    • date resolved: 2019-07-24, date raised: 2019-07-23

  • 0.1.180 EXTENSION AxiallyMovingCable2D (#219)

    • description: Add ALE cable element with axially moving component; derive this class from ANCFCable2D; in this way parameters of ANCFCable2D are hidden, but all functions can be reused; direct access to parameters. must be removed in all ANCFCable2D implementation

    • date resolved: 2019-07-24, date raised: 2019-07-04

  • 0.1.179 EXTENSION SlidingJoint2D (#226)

    • description: Add jacobian function

    • date resolved: 2019-07-23, date raised: 2019-07-10

  • 0.1.178 EXTENSION NodeGenericODE2 (#220)

    • description: Add generic node for ODE2 coordinates, used for AxiallyMovingCable2D

    • date resolved: 2019-07-23, date raised: 2019-07-04

  • 0.1.177 EXTENSION ContactFrictionCircle2D (#217)

    • description: Add a circular contact+friction; same as ObjectContactCircleCable2D

    • date resolved: 2019-07-23, date raised: 2019-06-28

  • 0.1.176 CHECK numDiff (#218)

    • description: Check whether the reference coordinates should be added to current coordinates for the size of the differentiation parameter

    • date resolved: 2019-07-12, date raised: 2019-07-04

  • 0.1.175 EXTENSION ObjectSlidingJoint2D (#213)

    • description: add sliding joint and according marker(s): one marker for set of cable elements or a list of markers (needs to update ltg list)

    • date resolved: 2019-07-12, date raised: 2019-06-28

  • 0.1.174 EXTENSION LoadMassProportional (#210)

    • description: Add mass proportional vector loading: body marker + according load

    • date resolved: 2019-07-12, date raised: 2019-06-28

  • 0.1.173 EXTENSION User system function (#185)

    • description: Add user-defined system function to every end of step in time integration; use separate User-structure in settings

    • date resolved: 2019-07-10, date raised: 2019-06-13

  • 0.1.172 EXTENSION StaticSolver (#153)

    • description: Add nonlinear iteration for contact

    • date resolved: 2019-07-09, date raised: 2019-05-28

  • 0.1.171 EXTENSION Numerical Jacobian (#214)

    • description: Add numerical jacobian for every object / constraint instead of global jacobian

    • date resolved: 2019-07-04, date raised: 2019-06-28

  • 0.1.170 EXTENSION ObjectContactCircleANCF2D (#212)

    • description: add a circular contact with centerpoint, radius and range of according angle of a circle segment

    • date resolved: 2019-07-04, date raised: 2019-06-28

  • 0.1.169 EXTENSION MarkerANCFCable2DShape (#211)

    • description: Add a marker to measure 2D/3D? ANCF shapes

    • date resolved: 2019-07-04, date raised: 2019-06-28

  • 0.1.168 EXTENSION Item names (#193)

    • description: Add name tag to class interfaces for objects, nodes, … to add item names; use empty string (“”) to identify that default names shall be generated

    • date resolved: 2019-07-04, date raised: 2019-06-19

  • 0.1.167 EXTENSION ODE2CoordinatesNode (#166)

    • description: Replaced by new issue 220

    • date resolved: 2019-07-04, date raised: 2019-06-03

  • 0.1.166 EXTENSION ObjectContactCoordinate (#207)

    • description: add functionality for nonlinear iterations in objects and in static solver

    • date resolved: 2019-06-28, date raised: 2019-06-28

  • 0.1.165 EXTENSION ObjectContactCoordinate (#206)

    • description: Add a contact connector for single coordinates

    • date resolved: 2019-06-28, date raised: 2019-06-28

  • 0.1.164 EXTENSION MarkerNodeCoordinate (#183)

    • description: A marker which addresses a certain nodal coordinate for Issue #165 NodalConstraint

    • date resolved: 2019-06-28, date raised: 2019-06-12

  • 0.1.163 EXTENSION Jacobian (#145)

    • description: Compute jacobian in timeintegration also with respect to velocities

    • date resolved: 2019-06-28, date raised: 2019-05-23

  • 0.1.162 EXTENSION SystemChecks (#93)

    • description: check system consistency/integrity before Assemble: objects->nodes, marker<->objects/nodes, marker<->constraints, marker<->loads

    • date resolved: 2019-06-28, date raised: 2019-04-01

  • 0.1.161 EXTENSION ObjectConnectorCartesianSpringDamper (#205)

    • description: Add a cartesian spring damper, which acts with certain parameters in x,y, and z-direction; can be used for 2D and 3D elements

    • date resolved: 2019-06-27, date raised: 2019-06-27

  • 0.1.160 EXTENSION NodeGenericData (#204)

    • description: Add new node with data coordinates; generic size

    • date resolved: 2019-06-26, date raised: 2019-06-26

  • 0.1.159 CHANGE PythonClassNames (#189)

    • description: Add field pythonShortName to objectDefinition, to give the python object - e.g. ObjectConnectorDistance a better name - e.g. simply Distance, SpringDamper; use typedef, i.e. ConstrainDistance = ObjectConnectorDistance

    • date resolved: 2019-06-26, date raised: 2019-06-14

  • 0.1.158 CHANGE useIndex2 (#188)

    • description: Rename useIndex2 in connectors / algebraic equations to velocityLevel

    • date resolved: 2019-06-26, date raised: 2019-06-14

  • 0.1.157 EXTENSION graphics (#169)

    • description: Add graphics representation for ForceVector

    • date resolved: 2019-06-26, date raised: 2019-06-05

  • 0.1.156 EXTENSION ConstraintNodeCoord (#165)

    • description: ObjectConstraintNodeCoordinate: used to directly constrain two nodal coordinates

    • date resolved: 2019-06-26, date raised: 2019-06-03

  • 0.1.155 EXTENSION RigidBody (#154)

    • description: Add 2D rigid body

    • date resolved: 2019-06-26, date raised: 2019-05-28

  • 0.1.154 EXTENSION CData (#152)

    • description: Couple CData, initialState, etc. to pybind DIRECTLY as state structure –> enable multiple computations

    • date resolved: 2019-06-26, date raised: 2019-05-28

  • 0.1.153 CHANGE enum Index (#140)

    • description: change from enum class to enum which is convertible to Index

    • date resolved: 2019-06-26, date raised: 2019-05-20

  • 0.1.152 CHECK AddMatrix (#133)

    • description: Test function add matrix and use it in mass matrix assembly

    • date resolved: 2019-06-26, date raised: 2019-05-17

  • 0.1.151 EXTENSION Solve:MarkerData (#129)

    • description: Implement a GetMarkerData() function for markers

    • date resolved: 2019-06-26, date raised: 2019-05-14

  • 0.1.150 EXTENSION integrate (#90)

    • description: integrate rigid body (3D/2D) and according constraints

    • date resolved: 2019-06-26, date raised: 2019-04-01

  • 0.1.149 EXTENSION LoadTorqueVector (#203)

    • description: Add new load TorqueVector

    • date resolved: 2019-06-25, date raised: 2019-06-25

  • 0.1.148 EXTENSION MarkerBodyRigid (#202)

    • description: Create a rigid body marker for application of torques

    • date resolved: 2019-06-24, date raised: 2019-06-24

  • 0.1.147 EXTENSION ObjectANCFCable2D (#201)

    • description: Add kappa0 and eps0

    • date resolved: 2019-06-23, date raised: 2019-06-23

  • 0.1.146 EXTENSION ObjectANCFCable2D (#200)

    • description: Create 2D ancf Bernoulli-Euler beam elements

    • date resolved: 2019-06-22, date raised: 2019-06-28

  • 0.1.145 EXTENSION NodePoint2DSlope1 (#199)

    • description: Create node for 2D ancf Bernoulli-Euler beam elements

    • date resolved: 2019-06-18, date raised: 2019-06-18

  • 0.1.144 EXTENSION 2D Nodes/Objects (#198)

    • description: Add NodePoint2D, NodeRigidBody2D, ObjectMassPoint2D, ObjectRigidBody2D, ObjectJointRevolute2D

    • date resolved: 2019-06-17, date raised: 2019-06-17

  • 0.1.143 EXTENSION ObjectConstraintCoordinate (#197)

    • description: constrain two coordinates; possibly add an offset (modifyable?)

    • date resolved: 2019-06-16, date raised: 2019-06-16

  • 0.1.142 EXTENSION MarkerNodeCoordinate (#196)

    • description: DE2/ODE1 coordinate at displacement or velocity level; extend MarkerType/OutputVariable interface

    • date resolved: 2019-06-15, date raised: 2019-06-15

  • 0.1.141 EXTENSION NodePointGround (#195)

    • description: Add node similar to nodepoint, but no action and zero coordinates

    • date resolved: 2019-06-14, date raised: 2019-06-14

  • 0.1.140 EXTENSION MarkerNodePoint (#186)

    • description: Add a Marker to Node point; extend according assemble and computation functions

    • date resolved: 2019-06-13, date raised: 2019-06-13

  • 0.1.139 EXTENSION GeneralizedAlpha (#184)

    • description: Extend Newmark to generalized alpha

    • date resolved: 2019-06-13, date raised: 2019-06-13

  • 0.1.136 EXTENSION create (#89)

    • description: create .tex reference pages for objects

    • date resolved: 2019-06-13, date raised: 2019-04-01

  • 0.1.135 EXTENSION Item Dicts (#182)

    • description: Use letter V ahead all visualization parameters in interface; add VNodePoint python class for interface with visualization

    • date resolved: 2019-06-12, date raised: 2019-06-12

  • 0.1.134 EXTENSION SolutionFile (#181)

    • description: Add user_defined comments to user file

    • date resolved: 2019-06-12, date raised: 2019-06-12

  • 0.1.133 EXTENSION safe copy (#177)

    • description: Make consistent copy of current version

    • date resolved: 2019-06-12, date raised: 2019-06-11

  • 0.1.132 CHECK Python Interface (#176)

    • description: Check if it is better to add python classes for objects with according init function (can they be converted implicitly to dict and used in current AddNode(py::dict) function - or to use additional AddNode(…) function interfaces in MainSystem

    • date resolved: 2019-06-12, date raised: 2019-06-09

  • 0.1.131 EXTENSION Interface class (#175)

    • description: Add interface Python classes which return a dictionary for items; this enables autocompletion in editor …

    • date resolved: 2019-06-12, date raised: 2019-06-07

  • 0.1.130 EXTENSION GLFW client (#179)

    • description: Link client to MSC instead to MainSystem and link visualization to all cSystems; add “visualization.show” flag to visualize system

    • date resolved: 2019-06-11, date raised: 2019-06-11

  • 0.1.129 CHANGE Start/stop renderer (#178)

    • description: Put function into MSC

    • date resolved: 2019-06-11, date raised: 2019-06-11

  • 0.1.128 EXTENSION RendererWait (#170)

    • description: Add Wait function for renderer in pybind interface

    • date resolved: 2019-06-11, date raised: 2019-06-06

  • 0.1.127 EXTENSION Algebraic equations (#168)

    • description: Extend implicit time integration for algebraic equations; add warning to explicit time integration

    • date resolved: 2019-06-11, date raised: 2019-06-04

  • 0.1.126 EXTENSION ComputationSystem (#115)

    • description: Extend static computation for AE equations (DistanceConstraint)

    • date resolved: 2019-06-11, date raised: 2019-05-13

  • 0.1.125 EXTENSION Graphics (#156)

    • description: Add basic graphics elements (Line, Polygon, Circle) to bodies and ground visualization objects ==> for moving and static objects

    • date resolved: 2019-06-05, date raised: 2019-05-28

  • 0.1.124 EXTENSION Newton AE (#167)

    • description: Extend Newton for algebraic equations

    • date resolved: 2019-06-04, date raised: 2019-06-03

  • 0.1.123 EXTENSION FinishDistance (#163)

    • description: Finish algebraic equations for static and dynamic solver with distance

    • date resolved: 2019-06-04, date raised: 2019-06-03

  • 0.1.122 CHECK LagrangeMult (#162)

    • description: Check sign of Lagrange multipliers; related to CSystem::ComputeAERHS, last line

    • date resolved: 2019-06-04, date raised: 2019-06-03

  • 0.1.121 EXTENSION GraphicsUpdate (#160)

    • description: Write GraphicsUpdate for nodes and SpringDamper

    • date resolved: 2019-06-03, date raised: 2019-05-29

  • 0.1.120 EXTENSION OpenGL options (#151)

    • description: Add opengl options to pybind: Visualization:General,Window(mouse move, zoom),OpenGL,System(Objects,Nodes,…),Text

    • date resolved: 2019-05-29, date raised: 2019-05-28

  • 0.1.119 EXTENSION StaticSolver (#149)

    • description: Static solver: add time to state structure and file output

    • date resolved: 2019-05-29, date raised: 2019-05-27

  • 0.1.118 EXTENSION StopComputation (#159)

    • description: Add shortcut (CTRL Q) to OpenGL to quit simulation

    • date resolved: 2019-05-28, date raised: 2019-05-28

  • 0.1.117 EXTENSION OpenGLText (#150)

    • description: Add simple text structure to OpenGL

    • date resolved: 2019-05-28, date raised: 2019-05-28

  • 0.1.116 EXTENSION CData (#148)

    • description: extend static/dynamic solvers to work with CData State structures, including start of step, initial step and according time values

    • date resolved: 2019-05-28, date raised: 2019-05-25

  • 0.1.115 BUG glfwRenderer (#147)

    • description: StopRenderer() leads to python session termination ==> try to debug

    • date resolved: 2019-05-28, date raised: 2019-05-25

  • 0.1.114 EXTENSION accelerations (#144)

    • description: add accelerations to cData and option for export (in time integration

    • date resolved: 2019-05-28, date raised: 2019-05-23

  • 0.1.113 EXTENSION Visualization (#117)

    • description: Link visualization Items to main Items

    • date resolved: 2019-05-28, date raised: 2019-05-13

  • 0.1.112 EXTENSION Visualization (#116)

    • description: Add Visualization objects/nodes/…

    • date resolved: 2019-05-28, date raised: 2019-05-13

  • 0.1.111 EXTENSION Newmark (#143)

    • description: Add coefficients to Implicit Trapezoidal rule interface

    • date resolved: 2019-05-27, date raised: 2019-05-23

  • 0.1.110 EXTENSION graphics (#83)

    • description: Link GLFW: Add library; add VisualizationSystem; link to MainSystem; add data structure (linked to pybind); Initialization; add FLAG to deactivate

    • date resolved: 2019-05-27, date raised: 2019-04-01

  • 0.1.109 EXTENSION Discussion (#138)

    • description: Add new label DISCUSSION with blue color to issue tracker

    • date resolved: 2019-05-23, date raised: 2019-05-19

  • 0.1.108 BUG StaticSolver (#137)

    • description: Debug static solver - crashes

    • date resolved: 2019-05-23, date raised: 2019-05-19

  • 0.1.107 EXTENSION SpringDamper (#134)

    • description: Add velocities to Bodies / Markers and to SpringDamperActuator

    • date resolved: 2019-05-23, date raised: 2019-05-19

  • 0.1.106 TESTING ComputationSystem (#113)

    • description: Test Loads

    • date resolved: 2019-05-23, date raised: 2019-05-13

  • 0.1.105 EXTENSION check Timeint (#96)

    • description: check TimeIntegration to work with new objects

    • date resolved: 2019-05-23, date raised: 2019-04-01

  • 0.1.104 CHANGE CMarker::GetPosJac (#128)

    • description: Remove return value Matrix and use Matrix& in arguments to avoid memory allocation

    • date resolved: 2019-05-19, date raised: 2019-05-14

  • 0.1.103 EXTENSION StaticSolver (#114)

    • description: Add Static (Nonlinear) Solver

    • date resolved: 2019-05-19, date raised: 2019-05-13

  • 0.1.102 EXTENSION ComputationSystem (#112)

    • description: Add Jacobian evaluation for ODE2RHS

    • date resolved: 2019-05-19, date raised: 2019-05-13

  • 0.1.101 EXTENSION ComputationSystem (#110)

    • description: Add/merge system level computation functions: ComputeMass, ComputeODE2RHS, …

    • date resolved: 2019-05-19, date raised: 2019-05-13

  • 0.1.100 EXTENSION Setup (#84)

    • description: Setup static solver (use Matrix-solver OR eigen-SuperLU)

    • date resolved: 2019-05-19, date raised: 2019-04-01

  • 0.1.99 EXTENSION Add (#82)

    • description: Add CObjectGround to objects

    • date resolved: 2019-05-19, date raised: 2019-04-01

  • 0.1.98 EXTENSION MatrixInvert (#132)

    • description: Implement simple matrix inversion for simpler tetss without making use of Eigen library

    • date resolved: 2019-05-17, date raised: 2019-05-17

  • 0.1.97 CHANGE constraint ODE2RHS (#127)

    • description: add new interface for ComputeODE2RHS and ComputeAlgebraicEquations; add Array<MarkerData>, which is prefilled during computation; MarkerData=Position,Velocity,PosJacobian,RotJacobian;

    • date resolved: 2019-05-17, date raised: 2019-05-14

  • 0.1.96 EXTENSION ResizableMatrix (#122)

    • description: Implement resizable matrix for temporary data structures in solver/time integration

    • date resolved: 2019-05-17, date raised: 2019-05-13

  • 0.1.95 EXTENSION ComputationSystem (#111)

    • description: Add temporary evaluation structures (Matrices/Vectors) for system evaluation functions (Contraints/Markers)

    • date resolved: 2019-05-17, date raised: 2019-05-13

  • 0.1.94 EXTENSION Finish (#4)

    • description: Finish functions for all matrix classes

    • date resolved: 2019-05-17, date raised: 2019-04-01

  • 0.1.93 EXTENSION set (#3)

    • description: set up all matrix classes

    • date resolved: 2019-05-17, date raised: 2019-04-01

  • 0.1.92 EXTENSION Finish (#1)

    • description: Finish functions for all vector classes

    • date resolved: 2019-05-17, date raised: 2019-04-01

  • 0.1.91 CHECK Eigen (#130)

    • description: perform eigen tests in separate console project

    • date resolved: 2019-05-16, date raised: 2019-05-16

  • 0.1.90 EXTENSION Solver (#109)

    • description: count memory allocations (=new) during solving; eliminate memory allocation

    • date resolved: 2019-05-15, date raised: 2019-05-12

  • 0.1.89 CHANGE SpringDamper (#107)

    • description: remove Matrix from CObjectConstraintSpringDamperActuator::ComputeODE2RHS(…)

    • date resolved: 2019-05-15, date raised: 2019-05-12

  • 0.1.88 CHECK release assert (#120)

    • description: check if release assert works correctly in release and debug mode (check with invalid vector access)

    • date resolved: 2019-05-13, date raised: 2019-05-13

  • 0.1.87 EXTENSION available types (#119)

    • description: Show available types in GetObject/Node/Marker/…Defaults() function, if args are used: GetNodeDefault()

    • date resolved: 2019-05-13, date raised: 2019-05-13

  • 0.1.86 EXTENSION Matrix/Vector (#108)

    • description: add global counter for memory allocations (=new)

    • date resolved: 2019-05-13, date raised: 2019-05-12

  • 0.1.85 FIX VS2017_PYPLOT (#106)

    • description: matplotlib.pyplot does not work in VS2017 - installation fails, while matplotlib is installed; upgrade of pip installer does not help

    • notes: restart of VS2017 solved problem

    • date resolved: 2019-05-12, date raised: 2019-05-12

  • 0.1.84 EXTENSION dict access (#103)

    • description: Lateron: Add dict access to functions (NodeAccessFunction({‘name’:node_name, ‘function’:’Stress’,’position’:[0,1,2,0.5],’option’:’Cauchy’})

    • date resolved: 2019-05-12, date raised: 2019-04-01

  • 0.1.83 EXTENSION dict access (#102)

    • description: Lateron: Add dict access to functions (NodeAccessFunction({‘index’:ind, ‘function’:’CurrentPosition’})

    • date resolved: 2019-05-12, date raised: 2019-04-01

  • 0.1.81 EXTENSION MainSystemContainer (#95)

    • description: move MainSystemContainer to own class

    • date resolved: 2019-05-12, date raised: 2019-04-01

  • 0.1.80 EXTENSION Debug: (#81)

    • description: Debug: CMarkerBodyPosition::GetPositionJacobian

    • date resolved: 2019-05-12, date raised: 2019-04-01

  • 0.1.79 EXTENSION issue tracker (#105)

    • description: add filename and line number to issue tracker

    • date resolved: 2019-05-11, date raised: 2019-05-11

  • 0.1.78 EXTENSION issue tracker (#104)

    • description: set up issue tracking system

    • date resolved: 2019-05-10, date raised: 2019-05-10

  • 0.1.77 EXTENSION Differentiate (#136)

    • description: Add class function for numerical differentiation of a member function of CSystem

    • notes: first tests did not work ==> added manually

    • date raised: 2019-05-19

  • 0.1.76 EXTENSION Data dependency (#87)

    • description: For the moment: use CSystemData* in all objects, …

    • date raised: 2019-02-01

  • 0.1.75 EXTENSION Setup (#80)

    • description: Setup time integration

    • date raised: 2019-02-01

  • 0.1.74 EXTENSION Assemble (#79)

    • description: Assemble function renewed(split into nodes-section, etc.): assign node coordinates, initialize global coordinate vectors

    • date raised: 2019-02-01

  • 0.1.73 EXTENSION def_readwrite (#78)

    • description: def_readwrite used to access SystemStates initial, current, …

    • date raised: 2019-02-01

  • 0.1.72 EXTENSION Add (#77)

    • description: Add pybinding to CData as well ==> but only for read access

    • date raised: 2019-02-01

  • 0.1.71 EXTENSION Python: (#76)

    • description: Python: add pybinding to SystemState .def_property and get/set functions; then access initial, current, etc. via separate functions, e.g.

    • date raised: 2019-02-01

  • 0.1.70 EXTENSION CData (#75)

    • description: CData –> class SystemState; change to individual SystemState for current, initial, reference, etc.

    • date raised: 2019-02-01

  • 0.1.69 EXTENSION change (#74)

    • description: change …ObjectType(), NodeType() in object/node to Type(); unified with CMarker!

    • date raised: 2019-02-01

  • 0.1.68 EXTENSION change (#73)

    • description: change …CObjectType to ObjectType (same as nodes, markers, outputvariabletype…); NO “C”

    • date raised: 2019-02-01

  • 0.1.67 EXTENSION Use (#72)

    • description: Use consistently “Get…” in function (C++: always; py interface: discuss)

    • date raised: 2019-02-01

  • 0.1.66 EXTENSION add (#71)

    • description: add error handling for AddMainNode/Object/… according to AddMainMarker

    • date raised: 2019-02-01

  • 0.1.65 EXTENSION add (#70)

    • description: add GetLoadVector() for LoadForceVector

    • date raised: 2019-02-01

  • 0.1.64 EXTENSION DONE: (#69)

    • description: DONE: size=1 or 3; add dimensionality of Load==>corresponds to dim of Marker; remove loadVector default from CLoad

    • date raised: 2019-02-01

  • 0.1.63 EXTENSION no: (#68)

    • description: no: marker can have variable dimension; add dimensionality of Marker (MarkerBodyPosition=3, MarkerBodyCoordinate=1, MarkerBodyRigid=6, MarkerNodePoint=3, etc.)

    • date raised: 2019-02-01

  • 0.1.62 EXTENSION finish (#67)

    • description: finish constraints, markers and loads

    • date raised: 2019-02-01

  • 0.1.61 EXTENSION integrate (#66)

    • description: integrate markers and loads

    • date raised: 2019-02-01

  • 0.1.60 EXTENSION constraint (#65)

    • description: constraint integration: .cpp file, object factory

    • date raised: 2019-02-01

  • 0.1.59 EXTENSION sys.InfoDetailed() (#64)

    • description: sys.InfoDetailed() ==> Dicts of all objects, nodes, markers, …

    • date raised: 2019-02-01

  • 0.1.58 EXTENSION sys.InfoSummary(): (#63)

    • description: sys.InfoSummary(): __repr__ of sys ==> shows lists and CData;

    • date raised: 2019-02-01

  • 0.1.57 EXTENSION GetNumberOfNodes() (#62)

    • description: sys.GetNumberOfNodes(), etc.

    • date raised: 2019-02-01

  • 0.1.56 EXTENSION Test (#61)

    • description: Test CallObjectFunction(…) ==> error in sys.PyGetOutputVariable(0,ht.OutputVariableType.Position)

    • date raised: 2019-02-01

  • 0.1.55 EXTENSION change (#60)

    • description: change marker->body/load->body/… references from pointers to numbers

    • date raised: 2019-02-01

  • 0.1.54 EXTENSION GetOutputVariableBod (#59)

    • description: GetOutputVariableBody(variableType, localPosition, configuration, value)

    • date raised: 2019-02-01

  • 0.1.53 EXTENSION GetOutputVariable (#58)

    • description: GetOutputVariable(variableType, value)

    • date raised: 2019-02-01

  • 0.1.52 EXTENSION Vector: (#57)

    • description: Vector: add .cpp file and resolve SlimVector compiler conflict

    • date raised: 2019-02-01

  • 0.1.51 EXTENSION CallFunction(…) (#56)

    • description: MainObject::CallFunction(…)

    • date raised: 2019-02-01

  • 0.1.50 EXTENSION PyCallObjectFunction (#55)

    • description: MainSystem::PyCallObjectFunction(…) –> py::object

    • date raised: 2019-02-01

  • 0.1.49 EXTENSION add (#54)

    • description: add CObjectMassPoint.cpp and copy functions from COMassPoint.h

    • date raised: 2019-02-01

  • 0.1.48 EXTENSION resolve (#53)

    • description: resolve includes for Node, Body, MainSystem, ObjectFactory, TimeIntegrationSolver

    • date raised: 2019-02-01

  • 0.1.47 EXTENSION add (#52)

    • description: add addProtected/Public to python autoGenerator

    • date raised: 2019-02-01

  • 0.1.46 EXTENSION migrate (#51)

    • description: migrate from COBody to CObjectBody and MainObjectBody (COMMENT OUT main.cpp and similar implementations…)

    • date raised: 2019-02-01

  • 0.1.45 EXTENSION put (#50)

    • description: put CSystemData* into CObject

    • date raised: 2019-02-01

  • 0.1.44 EXTENSION add (#49)

    • description: add pybindings to Marker-/Load-/OuputVariable-/…types;

    • date raised: 2019-02-01

  • 0.1.43 EXTENSION add (#48)

    • description: add MainMassPoint, …

    • date raised: 2019-02-01

  • 0.1.42 EXTENSION add (#47)

    • description: add MainMarker, MainObject, …

    • date raised: 2019-02-01

  • 0.1.41 EXTENSION finish (#46)

    • description: finish MainNodePoint and access classes of Node

    • date raised: 2019-02-01

  • 0.1.40 EXTENSION ModifyNode(node (#45)

    • description: ModifyNode(node, dict)

    • date raised: 2019-02-01

  • 0.1.39 EXTENSION AddNode(‘nodeType’ (#44)

    • description: AddNode(‘nodeType’:’…’, …), GetNode(number or nodeName), GetDefaultNode(‘nodeType’)

    • date raised: 2019-02-01

  • 0.1.38 EXTENSION Objects (#43)

    • description: Objects available in Python vs. Dict-Interface

    • date raised: 2019-02-01

  • 0.1.37 EXTENSION create (#42)

    • description: create concept for python integration:system

    • date raised: 2019-02-01

  • 0.1.36 EXTENSION create (#41)

    • description: create concept for python integration:specific objects: RigidBody, …

    • date raised: 2019-02-01

  • 0.1.35 EXTENSION create (#40)

    • description: create concept for python integration:core objects: Node, Marker, …

    • date raised: 2019-02-01

  • 0.1.34 EXTENSION move (#39)

    • description: move masspoint and other objects to objects directory

    • date raised: 2019-02-01

  • 0.1.33 EXTENSION create (#38)

    • description: create Object factory: objects added to specified CSystem

    • date raised: 2019-02-01

  • 0.1.32 EXTENSION access (#37)

    • description: access item in CSystem (test)

    • date raised: 2019-02-01

  • 0.1.31 EXTENSION add (#36)

    • description: add python access to CSystem members (obtain a certain CSystem as a copy?)

    • date raised: 2019-02-01

  • 0.1.30 EXTENSION AddPyfunction (#35)

    • description: AddPyfunction add pyFunction (which is global in module.cpp) to create a CSystem in SC

    • date raised: 2019-02-01

  • 0.1.29 EXTENSION define (#34)

    • description: define python dict structure (folders) for object definition:

    • date raised: 2019-02-01

  • 0.1.28 EXTENSION special (#33)

    • description: special function headers in MainObject (compute specific things, postprocessing of stresses?)

    • date raised: 2019-02-01

  • 0.1.27 EXTENSION MainObject (#32)

    • description: MainObject links to functions of CObject, as far as needed

    • date raised: 2019-02-01

  • 0.1.26 EXTENSION ObjectFactory (#31)

    • description: ObjectFactory function

    • date raised: 2019-02-01

  • 0.1.25 EXTENSION GetDict (#30)

    • description: GetDict / SetDict for MainObject types; all MAINObjects have this functionality?; this means a very deep integration of pybind11!; but not needed in base class, because all pybindings in derived class; all communication at ‘dict’ level, ; MainSystem.SetObjectDict(objectID[Name], dict); MainSystem.SetNodeDict(nodeID[Name], dict), etc.

    • date raised: 2019-02-01

  • 0.1.24 EXTENSION dict (#29)

    • description: dict access to MainObject for every chosen parameter or function (put into pymodule-part)

    • date raised: 2019-02-01

  • 0.1.23 EXTENSION (B) (#28)

    • description: (B) bind-only functions of mother class (without definition in Main/CObject)

    • date raised: 2019-02-01

  • 0.1.22 EXTENSION (D) (#27)

    • description: (D) function can have declaration only

    • date raised: 2019-02-01

  • 0.1.21 EXTENSION chose (#26)

    • description: chose, which parameter goes into CObject or MainObject (no doubling!)

    • date raised: 2019-02-01

  • 0.1.20 EXTENSION creates (#25)

    • description: creates CObject, MainObject, etc. classes

    • date raised: 2019-02-01

  • 0.1.19 EXTENSION write (#24)

    • description: write new pythonAutoGenerateObjects.py file for Objects, Nodes, Markers, etc.

    • date raised: 2019-02-01

  • 0.1.18 EXTENSION Create (#23)

    • description: Create -py multibody system according to CreateMultibodySystem() ==> what is done there to add objects?

    • date raised: 2019-02-01

  • 0.1.17 EXTENSION MainObject (#22)

    • description: MainObject setter function, using Python dictionary

    • date raised: 2019-02-01

  • 0.1.16 EXTENSION MainObject (#21)

    • description: MainObject getter function, using Python dictionary

    • date raised: 2019-02-01

  • 0.1.15 EXTENSION MainObjectFactory (#20)

    • description: MainObjectFactory function, using Python dictionary

    • date raised: 2019-02-01

  • 0.1.14 EXTENSION MainObject: (#19)

    • description: MainObject: Pointer to CObject, Pointer to VObject, MainObjectParameters, special member variables, access functions, initialization

    • date raised: 2019-02-01

  • 0.1.13 EXTENSION CObject: (#18)

    • description: CObject: CObjectParameters (currently all public), special member variables, compute functions

    • date raised: 2019-02-01

  • 0.1.12 EXTENSION Access (#17)

    • description: Access to all objects (nodes, markers, etc) independent of class hierarchy: with a Dictionary() access

    • date raised: 2019-02-01

  • 0.1.11 EXTENSION change (#16)

    • description: change pythonAutoGenerator Setter/Getter functions to Pybind default: Set…(const Value& value) {…}

    • date raised: 2019-02-01

  • 0.1.10 EXTENSION extend (#15)

    • description: extend pythonAutoGenerationInterfaces for python+Main-interface classes (flag p?)

    • date raised: 2019-02-01

  • 0.1.9 EXTENSION rename (#14)

    • description: rename PyCNode, PyCSystem, etc. to MainNode, etc.

    • date raised: 2019-02-01

  • 0.1.8 EXTENSION add (#13)

    • description: add MainSystem to CSystem and add functionality for object factory

    • date raised: 2019-02-01

  • 0.1.7 EXTENSION check (#12)

    • description: check how derived classes work in pybind (need for trampoline?) ==> use Test class

    • date raised: 2019-02-01

  • 0.1.6 EXTENSION Add (#11)

    • description: Add global stream which always goes to Python

    • date raised: 2019-02-01

  • 0.1.5 EXTENSION create (#10)

    • description: create PySystemContainer:SystemContainer which adds the Python components to SystemContainer

    • date raised: 2019-02-01

  • 0.1.4 EXTENSION create (#9)

    • description: create SystemContainer as basis for all Comptational (MBS) System objects

    • date raised: 2019-02-01

  • 0.1.3 EXTENSION access (#8)

    • description: access to system and objects, but objects still live in C++ world

    • date raised: 2019-02-01

  • 0.1.2 EXTENSION decide: (#7)

    • description: decide: where do objects live?: objects + system live in C++ (otherwise parallelization inefficient)

    • date raised: 2019-02-01

  • 0.1.1 EXTENSION Test (#0)

    • description: Test efficiency of virtual function calls in current Vector/Matrix library ==> already done earlier ==> will be efficient for AVX implementation (small overhead accepted)

    • date raised: 2019-02-01

Open issues

  • CHECK NORMAL LOW EFF raised by: Claude-JG a 57 MB LaTeX build file in the history: ignore *.synctex and refuse large files at commit (#2916)

    • description: docs/theDoc/theDoc.synctex (56.8 MB, uncompressed SyncTeX of a LaTeX run) was committed with 8c0044f4 (revision2026 step R7.1.5) and deleted with f6c93a52 (R7.1.7); pushing master for 1.13 made GitHub warn (GH001, above the recommended 50 MB). It stays in the history - removing it would rewrite the published history. .gitignore has *.synctex.gz but not *.synctex; add it, and let the commit gate refuse a new tracked file above a few MB

    • date raised: 2026-10-09

  • TESTING NORMAL MEDIUM EFF raised by: Claude-JG the cable run of perfAccessFunctionsAD is ill-conditioned: its result moves by 20% with the Newton settings (#2914)

    • description: perfAccessFunctionsAD:cable-n200-implicit (200 ANCF cable elements, axialStiffness 1000, massPerLength 1, on spring-dampers) gives 0.004663 with the default modified Newton, 0.005112 with full Newton, 0.005388 with relativeTolerance 1e-10 and 0.005266 with both (15 s instead of 0.6 s); the fast module differs by 8.4e-7. A performance run should judge a converged result: choose parameters (stiffness, mass, step size) for which the Newton settings do not move it, then re-record its reference and timing

    • date raised: 2026-10-09

  • CHANGE HIGH EFF raised by: Claude-JG joints and their Jacobians on homogeneous transformations (#2884)

    • description: The constraint equations of the joints become functions of the relative transformation H0^-1 H1 of the two marker frames, and their Jacobians follow systematically from the relative twist - one implementation for JointGeneric, JointRevoluteZ, JointPrismaticX, the 2D joints and the rolling disc instead of one each. Successor of #2745 (the marker interface of RG14.2). revision2026b step RG14.3

    • date raised: 2026-10-07

  • CHECK MEDIUM EFF raised by: Claude-JG the member functions an item must provide, checked at compile time (#2866)

    • description: Successor of #2498, evaluated in RG9.6: an item must implement the functions its declarations require (access function types, output variables, node type, Jacobians); today the base classes provide ~110 defaults that throw ‘illegal call’ at run time and no pure virtual function. Plan: a table capability -> required functions, generated static_asserts per item header (decltype(&CItem::F) names the class that declares F), the runtime half (every declared output variable readable) as a test model.

    • date raised: 2026-10-05

  • CHANGE NORMAL HUGE EFF raised by: Claude-JG objects compute from coordinates passed in, instead of reading them from their nodes (#2746)

    • description: The maintainer, 2026-09-29: CObject::ComputeODE2LHS (bodies, not connectors) getting the coordinates directly instead of retrieving them from the nodes, which enables simpler automatic differentiation. A real performance question with several cases: objects with one node (MassPoint, RigidBody, …) can use linked data, while finite elements etc. would get displacement and velocity coordinates from the interface. First an evaluation step - what is there now, what are the best options. revision2026b group RG15.

    • date raised: 2026-09-29

  • TESTING LOW HIGH EFF raised by: Claude-JG the ROS examples were last tested in 2023 and nobody can run them (#2511)

    • description: ROSMassPoint.py; ROSTurtle.py and ROSMobileManipulator.py were written and tested in 2023 against ROS1 noetic. They have not been run since: the maintainer has no ROS installation; and ExampleSkipReason() skips anything importing rospy; so the automated example run never touches them either. Their supplementary files - the ROS nodes; the launch file and the STL geometry - had been in an Examples/supplementary folder that no longer exists; the headers still pointed at it until revision2026 step R5.18.4 moved them to python/Examples/testData/ROS/ and said so. Each file now carries a STATUS note: it is a working illustration of how the coupling is put together; not something that runs unchanged - topic names; message types and the node layout have to be adapted to the installation and the ROS version. ROS1 noetic reached end of life in May 2025; so the open question is whether these should be ported to ROS2 or marked historical. Needs somebody with a ROS installation.

    • date raised: 2026-09-18

  • EXTENSION LOW EFF shells (#2349)

    • description: adjust comments to fit to internal exudyn format

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2026-08-05

  • EXTENSION MEDIUM EFF itemInterface (#2342)

    • description: replace CopyDictLevel1 with function that takes visualization and VItemClass in all self.visualization inits and either call VItemClass(**visualization) if visualization is a dict, or store VItemClass object; this would enable to accept visualization as dict with only non-default values set; add try-except for dict-based call

    • remarks: planned as revision2026b step RG12.44 (triage 2026-10-07)

    • date raised: 2026-04-17

  • FIX LOW EFF SliderCrank Benchmark (#2326)

    • description: adapt TestModels/sliderCrank3Dbenchmark.py to revised IFToMM model

    • remarks: planned as revision2026b step RG2.6 (triage 2026-10-07)

    • date raised: 2026-03-23

  • DOCU LOW EFF GenericJoint (#2325)

    • description: improve documentation, in particular about order of axes for case of 1 and 2 rotation axes constrained

    • remarks: planned as revision2026b step RG13.9 (triage 2026-10-07)

    • date raised: 2026-03-23

  • EXTENSION HIGH EFF Add ObjectJointSliding (#2317)

    • description: Add implementation and tests for SlidingJoint with thick ANCF beam

    • remarks: planned as revision2026b step RG4.22 (triage 2026-10-07)

    • date raised: 2026-03-02

  • EXTENSION MEDIUM EFF Add ObjectJointSliding (#2316)

    • description: Add tests for SlidingJoint with thin ANCF cable

    • remarks: planned as revision2026b step RG4.22 (triage 2026-10-07)

    • date raised: 2026-03-02

  • EXTENSION HIGH EFF Add ObjectJointSliding (#2315)

    • description: Extend SlidingJoint for rotation case

    • remarks: planned as revision2026b step RG4.22 (triage 2026-10-07)

    • date raised: 2026-03-02

  • EXTENSION LOW EFF graphics (#2305)

    • description: Add error checks for isfinite for all point data imported in PyWriteBodyGraphicsDataList

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2026-02-15

  • EXTENSION LOW EFF graphics (#2304)

    • description: add hints (object type, etc.) to PyWriteBodyGraphicsDataList in VisualizationSystemContainer to simplify error localisation

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2026-02-15

  • EXTENSION MEDIUM EFF graphics (#2281)

    • description: add functionality to make consistent triangles with same orientation (all computed normals are outbound or inbound); used to heal imported geometries

    • remarks: planned as revision2026b step RG6.12 (triage 2026-10-07)

    • date raised: 2026-02-11

  • DOCU LOW EFF GetURDFrobotData (#2267)

    • description: add detailed description to function, in particular to returned dict

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2026-02-04

  • EXTENSION LOW EFF SystemContainer (#2259)

    • description: add option to constructor whether to attach to renderer or not (if used purely for computations, like in InverseKinematics

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2026-02-02

  • CHANGE LOW EFF camera (#2247)

    • description: add documentation for model-centric and camera-centric views

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2026-01-31

  • EXTENSION MEDIUM EFF GLFWClient (#2244)

    • description: add ruler to renderer, only for case where axes are parallel to x, y and z (i.e. 90 degree rotations)

    • remarks: planned as revision2026b step RG6.12 (triage 2026-10-07)

    • date raised: 2026-01-31

  • EXTENSION MEDIUM EFF explicit solver (#2238)

    • description: add adaptive step refinement for case of divergence - define limit for velocities/solution increment to decide step refinement (+ nan/inf)

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2026-01-27

  • EXTENSION LOW EFF computeInitialAccelerations (#2234)

    • description: add WARNING for inconsistent initial velocities - which usually cause heavy oscillations in constraint forces

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2026-01-21

  • TESTING MEDIUM EFF ANCFThinPlate (#2230)

    • description: add hemispheric test problem; compare to literature

    • remarks: planned as revision2026b step RG4.20.5 (triage 2026-10-07)

    • date raised: 2026-01-18

  • TESTING MEDIUM EFF ANCFThinPlate (#2229)

    • description: add cylindrical test problem; compare to ANCFCable2D

    • remarks: planned as revision2026b step RG4.20.5 (triage 2026-10-07)

    • date raised: 2026-01-18

  • EXTENSION LOW EFF Symmetric basis (#2228)

    • description: add a function to compute a basis for two given non-parallel vectors; the average of the two vectors is computed from averaging normalized vectors (=mid axis) and according projections; used for NodeSlope12

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2026-01-18

  • EXTENSION MEDIUM EFF ANCFThinPlate (#2226)

    • description: compute optimal slopes scaling in ShellMesh functionality

    • remarks: planned as revision2026b step RG4.20.5 (triage 2026-10-07)

    • date raised: 2026-01-16

  • EXTENSION HIGH EFF symbolic (#2223)

    • description: add vector and matrix functionality for Diff()

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2026-01-16

  • EXTENSION MEDIUM EFF NodePointSlope12 (#2219)

    • description: correct average Rotation and RotationJacobian to be symmetric w.r.t. both slopes

    • remarks: RG13.3 (2026-10-05): GetRotationJacobianTTimesVector_q of NodePointSlope12 is not implemented - a RigidBodySpringDamper at the node with an implicit solver raises NotImplementedFeatureError; the angular velocity is the least-squares fit, the rotation the Gram-Schmidt frame of slope x - the description says so now; planned as revision2026b step RG4.20.5 (triage 2026-10-07)

    • date raised: 2026-01-13

  • EXTENSION LOW EFF ANCFThinPlate (#2218)

    • description: add access function for rotation

    • remarks: planned as revision2026b step RG4.20.5 (triage 2026-10-07)

    • date raised: 2026-01-13

  • CHECK LOW EFF perspective (#2204)

    • description: check OpenGL visibility problems with larger zoom (is this the 0.1 limit?)

    • remarks: planned as revision2026b step RG6.8.8 (triage 2026-10-07)

    • date raised: 2026-01-08

  • EXTENSION LOW EFF OpenGL view (#2194)

    • description: add manual offsets for zNear and zFar, to adjust visible objects

    • remarks: planned as revision2026b step RG6.8.8 (triage 2026-10-07)

    • date raised: 2026-01-06

  • EXTENSION MEDIUM EFF MarkerSuperElementRigid (#2184)

    • description: highly improve efficiency for larger number of nodes by adding according precomputed transformations

    • remarks: planned as revision2026b step RG5.4 (triage 2026-10-07)

    • date raised: 2026-01-04

  • EXTENSION MEDIUM EFF SparseTripletMatrix (#2183)

    • description: add functions AddSparseTripletMatrix with parameters like AddToDenseMatrix; also add functions AddSubmatrix() and AddTransposedSubmatrix to add dense submatrices for ObjectFFRFreducedOrder

    • remarks: planned as revision2026b step RG5.4 (triage 2026-10-07)

    • date raised: 2026-01-04

  • EXTENSION MEDIUM EFF ObjectFFRFreducedOrder (#2182)

    • description: improve efficiency by using internal sparse triplets for mass matrix in C++ code

    • remarks: planned as revision2026b step RG5.4 (triage 2026-10-07)

    • date raised: 2026-01-04

  • EXTENSION HIGH EFF OpenGL (#2155)

    • description: add textures to renderer (and add reset function), using numpy binary array representing RGB/RGBA image; reference numbers are then used in triangle lists

    • remarks: planned as revision2026b step RG6.11 (triage 2026-10-07)

    • date raised: 2025-11-02

  • EXTENSION HIGH EFF OpenGL (#2154)

    • description: add textures for triangle lists, using texture reference number and coordinates, according to standard format

    • remarks: planned as revision2026b step RG6.11 (triage 2026-10-07)

    • date raised: 2025-11-02

  • EXTENSION MEDIUM EFF ObjectContact (#2131)

    • description: add rolling resistance

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2025-07-05

  • EXTENSION LOW EFF Screw graphics (#2120)

    • description: add function to generate graphics for screw

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2025-07-02

  • EXTENSION HIGH EFF solver (#2110)

    • description: add flag for local frame implicit solver, computing jacobians in local frame and using specific step updates

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2025-06-24

  • EXTENSION MEDIUM EFF Chain drive (#2106)

    • description: add function to create chain gears as well as geometry from chain drive; calculate length similar to reeving system, but with two chains (and kinck) to compensate length

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2025-06-21

  • EXTENSION MEDIUM EFF ContactSphereTriangle (#2097)

    • description: add frictionStiffness similar to bristle model in ANCF contact

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2025-06-15

  • EXTENSION MEDIUM EFF GetDictionary (#2075)

    • description: add read/write dict access for new structures SC.renderer and exudyn.config

    • remarks: planned as revision2026b step RG12.44 (triage 2026-10-07)

    • date raised: 2025-06-02

  • EXTENSION MEDIUM EFF solver timers (#2007)

    • description: add special timer for Python user functions, as solver timer for python does not include user functions

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2025-05-10

  • EXTENSION MEDIUM EFF Body force sensor (#1989)

    • description: add force sensor option for single-noded bodies and bodies which do not share nodes (mass points, rigid bodies, ffrf); for rigid bodies, obtains force and torque; for FFRF, it is generalized force; implement in a way that the contributions of loads are computed like in GeneralContact - based on a flag -, as soon as a BodySensor measures a force or torque

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2025-04-15

  • CHANGE MEDIUM EFF solver (#1977)

    • description: check if solver can raise full solver error message in exception, in order to alleviate tracing during automated code evaluation in SolveStatic and SolveDynamic

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2025-03-30

  • EXTENSION MEDIUM EFF URDF (#1941)

    • description: include parent names and create correct parent indices in URDF files by using link name lists; store list of base link names as well and do reordering

    • remarks: planned as revision2026b step RG12.45 (triage 2026-10-07)

    • date raised: 2024-11-12

  • EXTENSION MEDIUM EFF URDF import (#1932)

    • description: GetURDFrobotData: add tool transformations accordingly (currently shown with no consecutive transformations)

    • remarks: planned as revision2026b step RG12.45 (triage 2026-10-07)

    • date raised: 2024-11-10

  • EXTENSION MEDIUM EFF URDF import (#1931)

    • description: GetURDFrobotData: check for import of other scene information than mesh; check for import of collision

    • remarks: planned as revision2026b step RG12.45 (triage 2026-10-07)

    • date raised: 2024-11-10

  • EXTENSION MEDIUM EFF ContactSphereSphere (#1920)

    • description: add autodiff Jacobian

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2024-11-02

  • EXAMPLE MEDIUM EFF co-simulation (#1912)

    • description: add simple model of two mass-spring-dampers to show simulator coupling of two implicit-explicit mbs, similar to issue 1905

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2024-10-26

  • CHECK HIGH EFF total coordinates (#1910)

    • description: consider a solver option which continuously provides total coordinates during iterations which could be used in user functions or globally and also be linked instead of copied; add an exception if the respective option is not switched on; by default, only add an empty Vector currentState.ODE2CoordsTotal

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2024-10-26

  • EXTENSION HIGH EFF Reference/link data (#1904)

    • description: evaluate further options to link to internal data, such as objects, nodes, etc.; possibly with GetObjectParameter(…) and similar functions possibly automated; this would highly speed up user functions as it reduces the number of exudyn function calls

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2024-10-19

  • EXTENSION MEDIUM EFF GeneralContact (#1896)

    • description: add option to completely freeze searchTree bins if all velocities are below a certain threshold; mark these contact objects as inactive by checking activity from time to time; reactivate bins only if item at boundary exceeds velocity limit at active boundary

    • date raised: 2024-10-16

  • EXTENSION MEDIUM EFF GeneralContact (#1894)

    • description: add n*max(velocity)*stepSize safety for bounding box, in order to update some objects less frequently (when max dist is reached)

    • date raised: 2024-10-16

  • EXTENSION MEDIUM EFF Load/Save HDF5 (#1892)

    • description: Add Data structures like MatrixContainer, Vector3DList, etc.

    • remarks: planned as revision2026b step RG12.46 (triage 2026-10-07)

    • date raised: 2024-10-13

  • EXTENSION HIGH EFF MatrixContainer (#1864)

    • description: consider functionality to link to dense numpy matrix; possibly by using the allocatedSize in ResizableMatrix to indicate linking rather than allocation

    • remarks: planned as revision2026b step RG12.46 (triage 2026-10-07)

    • date raised: 2024-10-02

  • EXTENSION HIGH EFF MatrixContainer (#1863)

    • description: consider functionality to link to sparse CSR scipy matrix rather than using the current CSR format - as a minimal solution do copying on C++ level; Problem: scipy CSR uses other format than Exudyns Triplets

    • remarks: planned as revision2026b step RG12.46 (triage 2026-10-07)

    • date raised: 2024-10-02

  • EXTENSION HUGE EFF inverse dynamics (#1822)

    • description: consider an inverse dynamics solver for constrained systems; this requires decouple constraints from Lagrange multipliers; add separate LTG list for Lagrange multipliers and objectLTGAE; separate CObject::GetAlgebraicEquationsSize from LagrangeMultiplier size; check markerDataStructure.GetLagrangeMultipliers; see CSystemData::ComputeMarkerDataStructure

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2024-04-19

  • EXTENSION HUGE EFF kinematics solver (#1821)

    • description: consider functionality of a kinematic solver; this could be based on a quasi-static solver which utilizes the velocity constraint level and computes unknown velocities for a given configuration; first attempt could be based on finite differences for prescribed incremental motion and resulting incremental coordinates; only possible for systems with DOF=0; alternatively, we could compute velocity coordinates only from the constrained system, which however would only work if all coordinates are constrained

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2024-04-19

  • CHECK MEDIUM EFF ComputeLinearizedSystem (#1776)

    • description: consider paper of Agundez, Vallejo, Freire, Mikkola in International Journal of Mechanical Sciences, Vol 268, 2024 for computation of linearized system and eigenmodes. Test case with bicycle

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2024-02-07

  • EXTENSION HIGH EFF C++ user functions (#1769)

    • description: Add cpp user functions fully to PythonUserFunctionBase capabilities

    • remarks: planned as revision2026b step RG8.10 (triage 2026-10-07)

    • date raised: 2024-02-02

  • EXTENSION HIGH EFF C++ user functions (#1768)

    • description: Add pybind object as container for Cpp user functions, similar to autogenerated SetUserFunction

    • remarks: planned as revision2026b step RG8.10 (triage 2026-10-07)

    • date raised: 2024-02-02

  • EXTENSION HIGH EFF C++ user functions (#1767)

    • description: add file for cpp user functions, registration mechanism like timers

    • remarks: planned as revision2026b step RG8.10 (triage 2026-10-07)

    • date raised: 2024-02-02

  • EXTENSION MEDIUM EFF GeneralContact (#1764)

    • description: add pickle functionality

    • date raised: 2024-01-31

  • EXTENSION HIGH EFF C++ user functions (#1751)

    • description: check injection of user functions with special item-function method, and separate cpp file holding prototypes of those functions, which may be injected accordingly; use mechanism to record user functions in exudyn.functions.userCpp.SpringDamper

    • remarks: planned as revision2026b step RG8.10 (triage 2026-10-07)

    • date raised: 2024-01-29

  • EXTENSION HUGE EFF Parameter type (#1722)

    • description: add exudyn.Parameter for all parameters occuring in items, such as referencePosition, physicsMass, etc.; this helps to avoid strings in user functions to access parameter and may allow to use more efficient case/switch in GetObjectParameter(…)

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2023-12-09

  • EXAMPLE MEDIUM EFF Mainsystem extensions (#1720)

    • description: change create2D functions into separate Create functions

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2023-12-08

  • EXAMPLE MEDIUM EFF generated examples (#1719)

    • description: add set of generically generated examples, generated examples

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2023-12-08

  • EXTENSION HIGH EFF ItemIndices (#1676)

    • description: consider overriding __getattr__ and __setattr__ methods through pybind (or in Python with patching); this should allow to access data directly mapped via the dictionary

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2023-10-29

  • EXTENSION HIGH EFF ItemIndices (#1675)

    • description: consider adding MainSystem* to indices; this would allow to directly operate on Nodes

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2023-10-29

  • CHANGE LOW EFF license.ext (#1674)

    • description: split into internal and external licenses

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2023-10-29

  • EXTENSION LOW EFF velocityOffset (#1631)

    • description: add to CartesianSpringDamper, RigidBodySpringDamper

    • remarks: planned as revision2026b step RG18.2 (triage 2026-10-07)

    • date raised: 2023-06-26

  • EXTENSION LOW EFF static members (#1614)

    • description: LinearSolver GeneralMatrixEXUdense::FactorizeNew has static ResizableMatrix m, which should be turned into class members; add reset method to free memory at solver finalization

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2023-06-11

  • EXTENSION HIGH EFF KinematicTree (#1549)

    • description: consider extension w.r.t. rigid body node at basis (Lie group node in explicit integration…); add baseNode (default=invalid), inertia could be added via a separate rigid body?

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2023-05-02

  • EXTENSION MEDIUM EFF ODE1 loads (#1548)

    • description: fully add Jacobian functionality for ODE1 loads and add test for ODE1 loads or recycle one

    • remarks: planned as revision2026b step RG4.23 (triage 2026-10-07)

    • date raised: 2023-05-01

  • EXTENSION MEDIUM EFF solver (#1529)

    • description: solver functions GetSystemJacobian() and GetSystemMassMatrix() need to be extended with arg sparseTriplets=False; if True, it will return CSR sparse triplets, useful for large matrices, e.g. in eigenvalue computation in linearized system

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2023-04-26

  • CHANGE LOW EFF StaticSolver (#1493)

    • description: add exception in case that Lie group nodes are used with static solver, which cannot work

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2023-04-06

  • EXTENSION MEDIUM EFF CoordinateSpringDamperExt (#1415)

    • description: add flag for stepSizeRecommendation, where 0 is no recommendation, -1 is automatic and >0 is a directly recommended step size

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2023-01-22

  • EXTENSION MEDIUM EFF InteractiveDialog (#1414)

    • description: extend for explicit solver; needs internally different setup of solvers; use dynamicSolverType with default generalizedAlpha changable to Newmark/Index2 as well as explicit solvers

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2023-01-22

  • EXTENSION HIGH EFF Register Items (#1241)

    • description: consider mechanism to self-register items: objects, nodes, …; same a swith TimerStructure registration; this allows to add user-defined objects without touching the overall code

    • remarks: planned as revision2026b step RG8.1 (triage 2026-10-07)

    • date raised: 2022-08-24

  • EXTENSION HIGH MEDIUM EFF parallel / multithreaded (#1203)

    • description: C++: add multithreading for JacobianODE2 (analytic jacobians)

    • remarks: planned as revision2026b step RG5.3 (triage 2026-10-07)

    • date raised: 2022-07-12

  • EXTENSION HIGH MEDIUM EFF parallel / multithreaded (#1202)

    • description: C++: add multithreading for JacobianAE

    • remarks: planned as revision2026b step RG5.3 (triage 2026-10-07)

    • date raised: 2022-07-12

  • EXTENSION MEDIUM EFF generalizedAlpha scaling (#1194)

    • description: turn on/off scaling in interface to test symmetric solver speedup

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2022-07-11

  • EXTENSION MEDIUM EFF ContactFrictionCircleCable2D (#1189)

    • description: add velocity offset to MarkerCable2DShape

    • remarks: planned as revision2026b step RG18.2 (triage 2026-10-07)

    • date raised: 2022-07-08

  • EXTENSION NORMAL HIGH EFF c++ user elements (#1140)

    • description: add auto registration for C++ user items

    • remarks: planned as revision2026b step RG8.1 (triage 2026-10-07)

    • date raised: 2022-06-12

  • EXTENSION NORMAL MEDIUM EFF c++ user elements (#1139)

    • description: add description regarding which functions are needed to add C++ user elements

    • remarks: planned as revision2026b step RG8.9 (triage 2026-10-07)

    • date raised: 2022-06-12

  • EXTENSION HUGE EFF GenericObject (#1104)

    • description: add most general generic object containing ODE1, ODE2 and AE equations + unknowns; jacobianAE as user functions

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2022-05-23

  • EXTENSION HIGH EFF ANCFBeam3D (#1087)

    • description: complete implementation of all functions (rigid marker, etc.)

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2022-05-16

  • EXTENSION MEDIUM EFF BeamSectionGeometry (#1078)

    • description: add BeamSectionGeometry to 2D beam elements

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2022-05-09

  • EXTENSION HIGH LOW EFF Reference and copy (#1061)

    • description: add information to theDoc regarding copying and referencing objects, such as mbs, GetObject(…), etc.; add info into description C/R into generatePyBindings?

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2022-04-30

  • EXTENSION MEDIUM EFF ObjectConnectorCoordinateVector (#1032)

    • description: cleanup, consider better UF and check implementation with theory (jac?)

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2022-04-04

  • EXTENSION HIGH EFF Contact switching (#1008)

    • description: Test improved contact integration method with resolution of switching and correction of integration of discontinuous forces; compare to switching point resolution

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2022-03-26

  • EXTENSION HIGH LOW EFF MarkerNodeCoordinate (#990)

    • description: add option addReferenceCoordinates=False to include reference value in coordinate

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2022-03-16

  • EXTENSION MEDIUM EFF ComputeConstraintJacobianDerivative (#988)

    • description: make sparse version similar to numerically differentiated single objects in JacobianODE2RHS

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2022-03-15

  • DOCU NORMAL MEDIUM EFF ALEANCFCable2D (#987)

    • description: add description - specifically regarding OutputVariables, special terms not available in ANCFCable2D (and add reference to ASME CND paper)

    • remarks: planned as revision2026b step RG13.9 (triage 2026-10-07)

    • date raised: 2022-03-15

  • CHANGE LOW EFF update mecanumWheelRollingDiscTest (#948)

    • description: update w.r.t. Trajectory class and TorsionalSpringDamper

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2022-02-21

  • EXTENSION MEDIUM EFF GeneralContact (#937)

    • description: add option to draw contact forces

    • date raised: 2022-02-10

  • EXTENSION MEDIUM EFF GeneralContact ANCF (#927)

    • description: test if 3 maxTangentialVelocities in 3-point Lobatto integration lead to better Newton performance

    • date raised: 2022-02-04

  • EXTENSION MEDIUM EFF RollingDiscPenalty (#926)

    • description: rollingFrictionViscous only works for rolls with axis parallel to z-Plane; add MISSING formulas to Docu and adapt formulation

    • remarks: planned as revision2026b step RG4.24 (triage 2026-10-07)

    • date raised: 2022-02-03

  • CHANGE MEDIUM EFF GeneralContact (#912)

    • description: add second CCactiveSetError mode, which computes error for given active set ==> error for PostNewton computed (error in assumed conditions forces)

    • date raised: 2022-02-02

  • EXTENSION HIGH EFF GeneralContact (#911)

    • description: implement contact laws

    • date raised: 2022-02-02

  • EXTENSION MEDIUM EFF GeneralContact (#910)

    • description: implement recommended step size (with error bound and separate min stepsize to avoid too small steps

    • date raised: 2022-02-02

  • EXTENSION MEDIUM EFF GeneralContact (#909)

    • description: add functionality to store/restore contact state for start of time step

    • date raised: 2022-02-02

  • EXTENSION HIGH EFF GeneralContact (#907)

    • description: add implicit Trig-Sphere contact

    • date raised: 2022-02-02

  • EXTENSION LOW EFF GeneralContact (#904)

    • description: PostNewton (sphere-sphere, ancf-circle): add if clause to switch off contact in case of negative contact force

    • date raised: 2022-01-31

  • CHANGE MEDIUM EFF GeneralContact (#867)

    • description: change deltaV terms in ANCFCable and TrigSphere contact to fit signs used in docu

    • date raised: 2022-01-17

  • EXTENSION MEDIUM EFF GeneralContact (#859)

    • description: split searchtree into regions, proportional to number of threads (FinalizeContact); use 2 splits in x, 2 splits in y, etc. until uneven number left; add class Box3Dindexed:Box3D, which adds index for region in searchtree; add access in GeneralContact for adding bounding box, creating the index; index is -1, if overlapping, filled in serially

    • date raised: 2022-01-13

  • EXTENSION MEDIUM EFF ParallelFor (#858)

    • description: use ParallelFor with costs argument in GeneralContact and CSystem, to optimize usage

    • remarks: planned as revision2026b step RG5.3 (triage 2026-10-07)

    • date raised: 2022-01-13

  • DOCU HIGH EFF Jacobian documentation (#845)

    • description: add documentation to object and connector jacobians

    • remarks: planned as revision2026b step RG14.3 (triage 2026-10-07)

    • date raised: 2021-12-23

  • EXTENSION HIGH EFF GeneralContact regularized friction (#841)

    • description: extend regularized friction (Haff-Werner) to integrated form using either Cundall-Stack friction or breaking tangential springs

    • date raised: 2021-12-19

  • EXTENSION HIGH EFF GeneralContact add cone (#836)

    • description: for 3D cables add cone (including cylinder) to contact with 3D cables

    • date raised: 2021-12-19

  • EXTENSION MEDIUM EFF GeneralContact add dissipative laws (#835)

    • description: add common dissipative (coeff of restitution, etc. laws to contact

    • date raised: 2021-12-19

  • EXTENSION HIGH EFF GeneralContact add contact laws (#834)

    • description: add Hertzian contact laws to contacts, using separate enum for contact laws and additional parameter

    • date raised: 2021-12-19

  • EXTENSION HIGH EFF GeneralContact rolling pivoting (#833)

    • description: add rolling and pivoting (drilling, boring) friction to spheres and triangles

    • date raised: 2021-12-17

  • EXTENSION MEDIUM EFF velocityOffset (#829)

    • description: add velocity offset to all spring dampers in order to replace many user functions with preStepUserFunctions

    • remarks: planned as revision2026b step RG18.2 (triage 2026-10-07)

    • date raised: 2021-12-15

  • EXTENSION MEDIUM EFF MatrixContainer (#782)

    • description: add SetWithNGsolveSparseMatrix; add an interface to directly convert from NGsolve matrix, also converting coordinate storage xxyyzz

    • remarks: planned as revision2026b step RG12.46 (triage 2026-10-07)

    • date raised: 2021-10-27

  • EXTENSION MEDIUM EFF ContactCoordinate (#737)

    • description: check if is very close to switching, perform switching for end of step and set error very small; if immediate swichting after beginning of step, do not set stepRecommendation to avoid step reduction; repeat step; time integration: if recommended step is set, reduction is performed in first iteration, otherwise iterate

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2021-08-13

  • EXTENSION MEDIUM EFF CollectCurrentNodeData (#710)

    • description: implement CollectCurrentNodeData for NodeRigidBody2D, optimize CollectCurrentNodeData for all rigid body nodes

    • remarks: planned as revision2026b step RG5.1.4 (triage 2026-10-07)

    • date raised: 2021-07-08

  • DOCU MEDIUM EFF ObjectContactFrictionCircleCable2D (#627)

    • description: add description, connector equations and figure

    • remarks: planned as revision2026b step RG13.9 (triage 2026-10-07)

    • date raised: 2021-04-21

  • DOCU MEDIUM EFF GenericJoint (#626)

    • description: add more description on constraint configurations, coordinate transformations and figures for GenericJoint

    • remarks: planned as revision2026b step RG13.9 (triage 2026-10-07)

    • date raised: 2021-04-21

  • DOCU MEDIUM EFF ObjectRigidBody (#625)

    • description: revise equations of motion and add figure for COM and local coordinates

    • remarks: planned as revision2026b step RG13.9 (triage 2026-10-07)

    • date raised: 2021-04-15

  • EXTENSION HIGH EFF sensor dependencies (#614)

    • description: add functionality to compute sensor-dependencies (for LTG computation), used in controller connectors? alternatively add dependentNodes to existing connectors

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2021-03-21

  • EXTENSION LOW EFF recommendedStepSize (#608)

    • description: add recommendedStepSize to ContactCoordinate element

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2021-03-20

  • CHECK MEDIUM EFF ObjectFFRF (#591)

    • description: Check forceVector and gravity forces in comparison to paper

    • remarks: planned as revision2026b step RG2.6 (triage 2026-10-07)

    • date raised: 2021-02-21

  • EXTENSION MEDIUM EFF initialAccelerations (#574)

    • description: add dg/dq*(dot q) term for initial accelerations in velocity level constraints; check with rolling coin

    • remarks: planned as revision2026b step RG4.21 (triage 2026-10-07)

    • date raised: 2021-02-07

  • EXTENSION MEDIUM EFF Drift inspector (#565)

    • description: add functionality to check whether drift gets too large

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2021-01-29

  • EXTENSION HIGH EFF Gen alpha2 (#561)

    • description: setup new generalized alpha integrator with GGL

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2021-01-26

  • TESTING MEDIUM EFF Lie group tests2 (#559)

    • description: add Lie group integrator flybar governor

    • remarks: planned as revision2026b step RG2.6 (triage 2026-10-07)

    • date raised: 2021-01-26

  • EXTENSION MEDIUM EFF item number textures (#517)

    • description: add special textures for item numbers

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2020-12-22

  • EXTENSION MEDIUM EFF Add user marker (#314)

    • description: add user marker

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2020-01-10

  • EXTENSION MEDIUM EFF constraints derivatives (#303)

    • description: add consistent flag, if constraints have velocity coordinate dependence or if they explicitly depend on time (needs additional derivatives for consistent initial accelerations)!

    • remarks: planned as revision2026b step RG4.21 (triage 2026-10-07)

    • date raised: 2019-12-26

  • EXTENSION MEDIUM EFF static computation (#260)

    • description: add consistent flag to markerdata computation, ODE2RHS computation, etc. for static computation, which does not compute information on velocities then.

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2019-09-10

  • CHANGE MEDIUM EFF PostNewtonStep (#252)

    • description: post newton step object functions shall be called from solver including a ResizableVector& dataVariables to be changed; post newton function shall not use direct write access to nodal data coordinates

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2019-08-27

  • EXTENSION MEDIUM EFF Jacobians (#194)

    • description: Make unique member function names for rotation/orientation jacobians in nodes and bodies

    • remarks: kept open as an idea, no plan step (triage 2026-10-07, revision2026b group RG18)

    • date raised: 2019-06-25

  • EXTENSION MEDIUM EFF SlimArray (#161)

    • description: Add template specializations to SlimArray<T,2..4> similar to SlimVector to speed up initialization of short vectors

    • remarks: planned as revision2026b step RG5.1.4 (triage 2026-10-07)

    • date raised: 2019-06-02

  • CHECK MEDIUM EFF Vector performance (#142)

    • description: check Vector operator[], and ConstVector performance regarding inlining

    • remarks: planned as revision2026b step RG5.1.4 (triage 2026-10-07)

    • date raised: 2019-05-21

  • CHANGE LOW EFF Linalg Override (#123)

    • description: Add override statement to all derived classes in linalg for safety

    • remarks: planned as revision2026b step RG18.1 (triage 2026-10-07)

    • date raised: 2019-05-13

Known bugs

  • BUG HIGH LOW EFF raised by: Claude-JG the release run dirties the working tree, so its tag step refuses (#2915)

    • description: exudev release –tag 1.13.2: after the run python/exudyn/__init__.pyi and symbolic.pyi showed as modified with identical content (line endings only) - most likely setup.py rewrote them inside the manylinux Docker build, which runs on the Windows checkout; the tag step then found a dirty tree and no tag v1.13.2 was created. setup.py should write the stubs only when their content changes (or with the line endings of the file), and the release should check the tree before the tag step and say why it does not tag

    • date raised: 2026-10-09