Skip to content

hfVisualizer Remote Control Step

step

hfVisualizer --remote [--target <id>] step <type> <name> (--content <text> | --content-file <file>) [--prev <name>] [--nlgeom <on|off>]
  • Creates or updates one step definition while preserving the original position of an existing step in the step list.
  • Exactly one of --content or --content-file is required.
  • step supports all listed step types in preprocessing mode.
  • In postprocessing mode, only <type>=Post is allowed. This is one of the few GUI-matched definition exceptions that remain editable there.
  • <type> and <name> must not be empty.
  • Supported step types are:
  • Static
  • Static, Arclength
  • Static, Quasi
  • Dynamic
  • Seepage
  • Seepage, Transient
  • Frequency
  • ModelUpdating, Static
  • ModelUpdating, Modal
  • ModelUpdating, Bayesian
  • ShapeEstimation
  • Post
  • PerformanceEvaluation
  • Post creates *PostStep, Name=<name>. Other types create *Step, TYPE=<type>, Name=<name>.
  • Optional --prev <name> maps to Prev=<name> and is allowed for every type except Post and PerformanceEvaluation.
  • Optional --nlgeom <on|off> maps to NLGEOM=<ON|OFF> and is allowed only for Static, Static, Arclength, Static, Quasi, and Dynamic.
  • Content is passed directly to hfDBReader after the IPC layer prepends the computed *Step or *PostStep keyword line.
  • Inside --content, use \n for line breaks. \\n stays literal.
  • Empty content is rejected.
  • In preprocessing mode, a successful apply marks the database modified and refreshes the render pipeline.
  • In postprocessing mode, a successful apply additionally runs runLastDataProcessingStep() and updates the DB file immediately, matching the GUI Step widget behavior.

Example:

hfVisualizer --remote step Static STEP1 --content "EquiTime, 0.1, 10\n*Activate, Type=Element\nALL"
hfVisualizer --remote step "Static, Arclength" STEP2 --prev STEP1 --nlgeom on --content-file D:\Work\step2.txt
hfVisualizer --remote step Post CHECK1 --content "elem-all\nSSF, D, sensor-check\n1.3*DC.2"

step-rename

hfVisualizer --remote [--target <id>] step-rename <old-name> <new-name>
  • Available only in preprocessing mode.
  • Both names must be non-empty and use the same single-token normalization as GUI edits.
  • The source name must exist.
  • The target name must not collide with another step unless it normalizes to the same name, in which case the command succeeds as a no-op.
  • Successful execution is recorded by script-save as a canonical step-rename ... tail.

Example:

hfVisualizer --remote step-rename STEP1 STEP_MAIN

step-delete

hfVisualizer --remote [--target <id>] step-delete <name>
  • Available only in preprocessing mode.
  • name must be non-empty and must resolve to an existing step.
  • The command uses the same delete path as ModelTree delete.
  • Existing delete guards are preserved. For example, delete still fails when the step is referenced by another step or by a history definition.
  • Successful execution is recorded by script-save as a canonical step-delete ... tail.

Example:

hfVisualizer --remote step-delete STEP_MAIN

step-delete-from

hfVisualizer --remote [--target <id>] step-delete-from <name>
  • Available only in postprocessing mode.
  • name must be non-empty and must resolve to an existing result-step path that the TreeWidget Delete Steps From ... action can delete.
  • The command uses the same delete path and guard rules as TreeWidget Delete Steps From ....
  • Successful execution modifies the current HDB result data immediately.
  • After success, hfVisualizer reloads result-step metadata from HDB right away so the current step/frame list stays in sync without reopening the file.
  • If no result steps remain after deletion, hfVisualizer switches back to preprocessing mode.
  • Successful execution is recorded by script-save as a canonical step-delete-from ... tail.

Example:

hfVisualizer --remote step-delete-from POST2