The command line: python -m exudyn

Some things are wanted from a shell rather than from a script: what did I actually install?, show me that sensor file, is this installation working at all?. The installed package answers them directly:

python -m exudyn <command> [options]

There are five commands. Each one parses its own options, so python -m exudyn <command> --help is the authoritative list — this page describes what the commands are for, not every flag they take.

command	what it does
monitor	live view of a results file while it is being written, see The results monitor
plot	one static plot of sensor or solution files, then exit
info	version, location and environment of this installation
demo	run a built-in demo model
dialogs	browse the settings, or the key bindings, in a dialog

python -m exudyn --version prints the version string alone, which is convenient in scripts.

info — what to put in a bug report

python -m exudyn info

prints the Exudyn version and the build it comes from, the path of the installed package, which compiled module is loaded (EXUDYN_MODULE), the output directory, the Python version and platform, and which of numpy, scipy, matplotlib, networkx, NGsolve and pytest are installed.

That block answers most of the questions a bug report otherwise needs a conversation about, so paste it into an issue rather than describing the installation in prose.

plot — a figure without writing a script

python -m exudyn plot solution/sensorPosition.txt
python -m exudyn plot s0.txt s1.txt --columns 0,1 --save position.png

Without --columns, every column except time is drawn over time. --save writes the figure (.png, .pdf, .svg) instead of, or in addition to, showing it; a run that only saves needs no window and works over SSH.

demo — does this installation work?

python -m exudyn demo          #a simple model with the renderer
python -m exudyn demo 2

The two demos of exudyn.demos. If these run, the compiled module, numpy, matplotlib and the renderer are in order — which is the first thing to establish when something else does not work.

dialogs — look a setting up before writing the model

python -m exudyn dialogs vis      #the visualization settings
python -m exudyn dialogs sim      #the simulation settings
python -m exudyn dialogs help     #the keyboard and mouse commands of the renderer

The settings dialog used to be reachable only by pressing V in the render window, which is no help to somebody who has not written the model yet. It is the same dialog: the tree of every setting with its type and its description, CTRL-F to find one by name, and copy line to take the Python statement that sets it. vis and sim are the short forms of visualizationSettings and simulationSettings.

The structures it shows are fresh ones, so what you see are the defaults a model starts from — nothing here is attached to a renderer, and closing the dialog changes no file. What the browsing is for is printed when you close it: the settings you changed, as the lines that set them, ready to paste into a script.

monitor — the results monitor

python -m exudyn monitor --last

attaches to the most recently written results file. The monitor has a page of its own: The results monitor.

Why this is not simply exudyn ...

A console script would put the name exudyn on the PATH of every environment the package is installed into. That is a promise about a name, and the set of commands is young, so the installation deliberately makes no such promise yet: python -m exudyn costs a few characters more and can change without breaking anybody’s shell.

The commands live in a plain dictionary inside exudyn/__main__.py, and each one imports what it needs only when it is called — an unused command costs nothing at startup, and the table is the place where a plugin can add its own command later.