Short answer: FhSim has no units. The engine integrates whatever numbers the input file and the SimObject library give it, and never converts, scales or checks them. Units are a property of the model library you are using, not of FhSim. This page says exactly what that means, what FhSim does fix (a visualisation convention), and where to look to find the units for a given library.

The engine is unit-agnostic

There is no unit system anywhere in the simulation engine. There is no gravity constant, no unit-conversion layer, no reference length or mass, and no scaling step between the input file and the integrator. The engine sees a state vector of doubles and a derivative function, and it advances one against the other.

The practical consequences are worth stating plainly:

Nothing validates magnitudes. A parameter value is read, converted to a double, and handed to the SimObject. The only check applied is on the number of components in a vector value, never on its size or its dimension.
Mixing unit systems is silent. Connect a SimObject library written in millimetres to one written in metres and the simulation runs to completion, reports success, and writes a plausible-looking CSV full of wrong answers. There is no error, no warning, and no diagnostic that will catch it — the numbers are all finite and the integrator is perfectly happy. The diagnostics find stiffness and bad Jacobians, not inconsistent units.
Consistency is your job. Every SimObject in a scenario must be written against, and parameterised in, the same unit system. That is a property of the scenario and of the libraries it loads, and only you can enforce it.
The output carries no units either. CSV columns are bare numbers with a SimObject name and a signal name (see the CSV output format). Whatever units went in come back out.

Note: This is a deliberate design, not an omission. FhSim is a general ODE integrator with a plugin model layer; fixing a unit system in the engine would constrain every library that could ever be written against it.

Finding the units for your model

Because units live in the library, that is where you have to look:

The library's own documentation. Each SimObject's parameters and ports are documented with the library that provides them — see Available model libraries.
The SimObject source or headers, if you have them. Parameter and port registration is where a model author states what a number means; see SimObject construction methods.
An existing working scenario for that library. A scenario that is known to produce correct results is the most reliable statement of its own unit system.

If you are writing a SimObject, document the unit of every parameter, every input port and every output port. Nothing else in the system will.

Vector-valued attributes

Positions, velocities and forces are written in the input file as comma-separated lists of components:

<Connection
    spring.PosB="0,0,0"
    mass.Force="0,0,-9.81"/>

The rules are the same everywhere a vector value appears — connection constants, SimObject parameters and initial conditions:

The separator is a comma. Values are plain decimal numbers; scientific notation is accepted.
The number of components must match exactly what the receiver declared. A constant connected to an input port must supply exactly that port's size, or the run stops with *"Constant value for input port <object,port> is incorrectly defined"*. A SimObject parameter that is declared as n numbers and given fewer stops the run with a message naming n. Nothing is padded and nothing defaults to zero.
How many components a given port or parameter takes is declared by the SimObject, not by FhSim. A three-component vector is the common case for positions and forces in a 3-D mechanical library, but it is the library that decides.
In <OBJECTS>, <INTERCONNECTIONS> and <INITIALIZATION>, each component is additionally passed through the arithmetic evaluator after $Variable substitution, so "0,0,-$Depth/2" is legal. See Arithmetic in attribute values.

The one convention FhSim does fix: Z-up

The visualisation assumes a right-handed world frame with Z up and X–Y horizontal. The camera is the place this is visible: its orbit control takes a bearing and an elevation about a look-at point, computes the horizontal offset from the bearing in the X and Y axes, and raises the camera along Z with the elevation. Camera yaw is applied as a rotation about the world Z axis.

So if you want your model to look right in FhVis or FhSimUI — ground plane flat, gravity pointing down the screen — put your horizontal plane in X–Y and your vertical axis along Z.

Warning: This is a convention of the renderer only. The integrator has no concept of "up": it never inspects which component of a vector is which. A model built Y-up integrates exactly as correctly as a model built Z-up; it will simply be drawn lying on its side. Nothing reports this.

For the scene controls themselves, see 3D scene navigation.

A worked reading of a force constant

A line such as

is a downward force (negative Z, given the Z-up convention above) whose magnitude cannot be read off the page. 9810 is consistent with more than one self-consistent unit system — for example a 1000-unit mass under an acceleration of 9.81, or a 1-unit mass under an acceleration of 9810 — and FhSim will integrate either interpretation without complaint. Which one it is depends entirely on how the library that provides mass defines Mass and Force.

The habit that avoids this: state the unit system in a comment at the top of every scenario file, and never mix libraries whose comments disagree.

Table of Contents

The engine is unit-agnostic

Finding the units for your model

Vector-valued attributes

The one convention FhSim does fix: Z-up

A worked reading of a force constant

See also