Results

After execute_analyses(), the results are stored on the LoadTracer, keyed by member tag.

Attribute	Contents
lt.reactions[tag]	The forces on each support (see below)
lt.models[tag]	The serialized analysis model of each member
lt.expanded_pm[tag]	The papermodel of each member with every load expanded into load case components ("expanded")
lt.issues[tag]	Input that was corrected so that the rundown could continue
lt.errors[tag]	Members that could not be analysed (with on_error="collect")
lt.ignored_reactions[tag]	Transfer loads whose source reactions were missing (with missing_reactions="ignore")
lt.load_cases_used	Every load case in the occupancies, sorted

Reactions

Reactions are keyed by support index, then by direction, then by load case:

{support_index: {direction: {load_case: value}}}

The support index is the position of the support along the member, which is the order that papermodels uses for transfer_reaction_index. Every support is listed, even when its reactions are zero, so the indexes always line up.

Member	Directions	Values
Frame	FX, FY, FZ, MX, MY, MZ	floats
Column	the directions it is loaded in (e.g. FY)	floats
Wall	the directions it is loaded in	lists of distributed loads along the wall (one support, index 0)

A wall’s reaction is a list of loads like:

{"start_magnitude": -120.0, "end_magnitude": -120.0, "start_loc": 0.0,
 "end_loc": 8.5, "case": "D", "dir": "FY"}

A member that carries no load has empty reactions ({0: {}, 1: {}}), and contributes no load to the members below it.

Files

With execute_analyses(artifacts_dir=...), loadtracer writes:

• models.json: lt.models, every analysis model

• reaction_forces.json: lt.reactions

The frame models are written with pynite-tools, so they can be loaded back into PyniteFEA models.

Issues

lt.issues lists, for each member, the input that loadtracer changed in order to keep going. For example:

• a support off the end of the member, moved onto the end

• a distributed load that extends past the member end, applied there as a point load

• a distributed load with no extents, applied over the full length

• two members that support the same part of a wall (the overlap is applied to both)

None of these stop the rundown, and the total load is kept in each case (except the last, which counts the overlap twice). But each usually points to a markup that should be fixed. loadtracer issues one LoadTracerWarning at the end of a rundown that has issues.

Load conservation

A useful check on any rundown: for each load case, the total occupancy load applied to the building should equal the total of the reactions at the bottom of the graph. The examples all make this check.