Post: Output Request

Model ElementPOST_REQUEST defines an output request entity in MotionSolve. POST_REQUESTs are written to MotionSolve output files so that they may be used for plotting and signal processing by HyperGraph and HyperGraph 3D.

Format

POST_REQUEST has five variations:

As built-in marker-based functions.
As built-in element force-based functions.
As a set of expressions based on the MotionSolve run-time expression language.
As a user subroutine written in a compiled language Fortran, C or C++.
As a Python or MATLAB script.

For the sake of clarity, the formats for these five variations are shown separately below.

Built-in marker based functions

<Post_Request
     id             = "integer"
     type           = "MARKER_DISPLACEMENT" | "MARKER_VELOCITY" | "MARKER_ACCELERATION" | "MARKER_FORCE"
     i_marker_id    = "integer"
   [[
     j_marker_id    = "integer"
     ref_marker_id  = "integer"
     label          = "string"
     comment        = "string"
   ]]
/>

Built-in element force based functions

<Post_Request
     id             = "integer"
     type           = "ELEMENTAL_FORCE"
     elem_type      = "string"
     jflag          = "integer"
  [[ ref_marker_id  = "integer"
     label          = "string"
     comment        = "string"
  ]]
/>

As a set of expressions based on the MotionSolve run-time expression language

<Post_Request
     id      = "integer"
     type    = "EXPRESSION"

   [[
     expr1   = "motionsolve_expression"
     expr2   = "motionsolve_expression"
     expr3   = "motionsolve_expression"
     expr4   = "motionsolve_expression"
     expr5   = "motionsolve_expression"
     expr6   = "motionsolve_expression"
     expr7   = "motionsolve_expression"
     expr8   = "motionsolve_expression"
     
     label   = "string"
     comment = "string"
   ]]
/>

As a user subroutine written in a compiled language Fortran, C or C++

<Post_Request
     id                   = "integer"
   [[
     label                = "string"
     comment              = "string"
   ]]
     type                 = "USERSUB"
     usrsub_dll_name      = "valid_path_name"
     usrsub_param_string  = "USER(par_1, ..., par_n)"
     usrsub_fnc_name      = "custom_fnc_name"
/>

As a Python or MATLAB script

<Post_Request
     id                   = "integer"
   [[
     label                = "string"
     comment              = "string"
   ]]
     type                 = "USERSUB"
     script_name          = "valid_path_name"
     interpreter          = "PYTHON" | "MATLAB"
     usrsub_param_string  = "USER(par_1, ..., par_n)"
     usrsub_fnc_name      = "custom_fnc_name"
/>

Attributes

id: Element identification number (integer>0). This number is unique among all Post_Request elements.
label: The name of the Post_Request element.
comments: A character string that describes the signals being measured. The string can be of any length.
type: Specifies the type of Post_Request element. Select from MARKER_DISPLACEMENT, MARKER_VELOCITY, MARKER_ACCELERATION, MARKER_FORCE, EXPRESSION, ELEMENTAL_FORCE and USERSUB.
i_marker_id: Specifies the Reference_Marker ID at which the information is being calculated. Use only when type is MARKER_DISPLACEMENT, MARKER_VELOCITY, MARKER_ACCELERATION, or MARKER_FORCE.
j_marker_id: Specifies the Reference_Marker ID from which the information is being calculated. The information is typically some vector relating to IM_ID and JM_ID, such as displacement, velocity, acceleration or force. Use only when type is MARKER_DISPLACEMENT, MARKER_VELOCITY, MARKER_ACCELERATION, or MARKER_FORCE.
ref_marker_id: Specifies the coordinate system in which the components of the vector between IM_ID and JM_ID are expressed. Use only when type is MARKER_DISPLACEMENT, MARKER_VELOCITY, MARKER_ACCELERATION, or MARKER_FORCE.
expr1, expr2,…., expr8: Specify the eight signals that are calculated with function expressions. Use only when type is EXPRESSION.
elem_type: Specifies the type of the element for which force is requested. Select from BEAM, BUSH, CONTACT, COUPLER, FIELD, FORCE, GFORCE, JOINT, JPRIM, MATE, MOTION, SFORCE, SPDP, VFORCE, VTORQUE and YFORCE.
elem_id: The ID of the element for which force is requested.
jflag: An integer that specifies whether force acting on the I or the J marker is requested. jflag = 0 returns force acting on the I marker and jflag = 1 returns force acting on the J marker.
usrsub_param_string: The list of parameters that are passed from the data file to the user-defined REQSUB. Use this keyword only when type = USERSUB is selected.
usrsub_dll_name: Specifies the path and name of the DLL or shared library containing user subroutine. MotionSolve uses this information to load the user subroutine REQSUB in the DLL at run time.
usrsub_fnc_name: Specifies an alternative name for the user subroutine REQSUB.
script_name: Specifies the path and name of the user-written script that contains the routine specified by usrsub_fnc_name.
interpreter: Specifies the interpreted language that the user script is written in. Valid choices are MATLAB or PYTHON.

Example

In 1996, STS-75, a tethered satellite, was launched from the space shuttle Columbia. The satellite was extended 19.7 kilometers from the shuttle when the tether broke near the boom. The satellite and tether drifted away from the orbiter and were lost.

A MotionSolve simulation is to be performed to understand the cause of the failure. As a part of the simulation, the satellite trajectory, angular momentum and the tether force time histories are to be calculated.

The satellite is roughly spherical, with a radius of 2 meters. Its mass properties are as follows:

mass = 300Kg, inertia = 20Kgm², 22Kgm², 25Kgm²

The center of mass of the satellite is identified as Reference_Marker 1101. Reference_Marker 1102 specifies the tether attachment point on the satellite; the attachment point on the spaceship by Reference_Marker 1972. The image below illustrates the system during deployment.

Figure 1. STS-75, a tethered satellite being deployed

The first example shows how the time history of the satellite trajectory is calculated. Note the use of zero IDs to indicate that the global coordinate system is to be used for JM_ID and RM_ID.

<Post_Request
    id                   = "1"
    comment              = "Satellite trajectory time history"
    type                 = "MARKER_DISPLACEMENT"
    i_marker_id          = "1101"
    j_marker_id          = "0"
    ref_marker_id        = "0"
/>

The second example shows how the time history of the satellite angular momentum is calculated. Note that the angular momentum is calculated about the center of mass of the satellite in the satellite coordinate system. 20, 22, and 25 are the moments of inertia of the satellite.

<Post_Request
    id                   = "2"
    comment              = "Satellite trajectory angular momentum"
    type                 = "EXPRESSION"
    expr1                = "0"
    expr2                = "20*WX(1101,0,1101)"
    expr3                = "22*WY(1101,0,1101)"
    expr4                = "25*WZ(1101,0,1101)"
    expr5                = "0"
    expr6                = "0"
    expr7                = "0"
    expr8                = "0"
/>

The last example shows how you may calculate the time history of the tether forces. The tether force components are calculated in the coordinate system of Reference_Marker 1972.

<Post_Request
     id                  = "1"
     comment             = "Tether force time history"
     type                = "MARKER_FORCE"
     i_marker_id         = "1102"
     j_marker_id         = "1972"
     ref_marker_id       = "1972"
/>

Comments

A POST_REQUEST may be one of the following types:

Type

Description

Marker Displacement

Outputs a set of displacement measures.

Marker Velocity

Outputs a set of velocity measures.

Marker Acceleration

Outputs a set of acceleration measures.

Marker Force

Outputs a set of force measures.

Elemental Force

Outputs a set for force measures specific to the element specified.

Expression

Outputs a set of measures defined as user-expressions in the XML input file.

User Subroutine

Outputs a set of measures computed in a user-written subroutine.

This generality allows almost any information of interest to be computed during a simulation and written to an output file for future review
TYPE = MARKER_DISPLACEMENT.
This request computes the translational and rotational displacement of one Reference_Marker (IM) with respect to a second Reference_Marker (JM). The results are calculated in the coordinate system of a third Reference_Marker (RM). The following eight components are returned:
- DM(IM,JM), DX(IM,JM,RM), DY(IM,JM,RM), and DZ(IM,JM,RM) describing translation.
- PSI(IM,JM), THETA(IM,JM) and PHI(IM,JM) or YAW(IM,JM), PITCH(IM,JM) and ROLL(IM,JM) describing rotations. You can select the angle type to output in the RESOUTPUT command. When not specified, the Euler Angles, Psi, Theta and Phi are output.
TYPE = MARKER_VELOCITY.
This request computes the velocity of one Reference_Marker(IM) with respect to a second Reference_Marker (JM). The results are calculated in the coordinate system of a third Reference_Marker (RM). The time derivative is always taken in the ground reference frame. This is a quick way of specifying the following eight function expressions:
- VM(I,JM,0), VX(IM,JM,RM,0), VY(IM,JM,RM,0), VZ(IM,JM,RM,0), WM(IM,JM), WX(IM,JM,RM), WY(IM,JM,RM), and WZ(IM,JM,RM).
TYPE = MARKER_ACCELERATION.
This request computes the acceleration of one Reference_Marker (IM) with respect to a second Reference_Marker (JM). The results are calculated in the coordinate system of a third Reference_Marker (RM). All time derivatives are taken in the ground reference frame. This is a quick way of specifying the following eight function expressions:
- ACCM(IM,JM,0), ACCX(IM,JM,RM,0), ACCY(IM,JM,RM,0), ACCZ(IM,JM,RM,0), WDTM(IM,JM,0), WDTX (IM,JM,RM,0), WDTY(IM,JM,RM,0), and WDTZ(IM,JM,RM,0).
TYPE = MARKER_FORCE
This request computes the sum total of the forces acting at a Reference_Marker (IM) due to all applied and reaction forces and torques between IM and a second Reference_Marker (JM). The results are calculated in the coordinate system of a third Reference_Marker (RM). This is a quick way of specifying the following eight function expressions:
- FM(IM,JM), FX(IM,JM,RM), FY(IM,JM,RM), FZ(IM,JM,RM), TM(IM,JM), TY(IM,JM,RM), and TZ(IM,JM,RM).
TYPE = ELEMENTAL_FORCE
This request generates eight channels of information that contain the force magnitude, X, Y, and Z forces, torque magnitude, and the X, Y and Z torque values in each channel for the element ID that is specified. The results are calculated in the coordinate system of the reference marker that is specified (RM). The forces are reported on the I or J body depending on what is specified in the j flag (JFLAG). This is a quick way of specifying the following eight function expressions (for a spring as an example):
- SPDP(ID,jflag,1,RM), SPDP(ID,jflag,2,RM), SPDP(ID,jflag,3,RM), SPDP(ID,jflag,4,RM), SPDP(ID,jflag,5,RM), SPDP(ID,jflag,6,RM), SPDP(ID,jflag,7,RM), SPDP(ID,jflag,8,RM)
TYPE = EXPRESSION
This type of request allows you to compute eight channels of information. The quantities to be calculated are defined as MotionSolve expressions that are evaluated at run-time. See the Functions topic for more information about function expressions and how to use them.
TYPE = USER SUBROUTINE
This type of request allows you to compute eight channels of information using a user-defined subroutine REQSUB. You may write the REQSUB in C/C++/FORTRAN and create a DLL from it. Alternatively, you may use a script to do the same in Python. MotionSolve loads the DLL/script automatically and calls REQSUB as needed to get the information it needs.
For POST_REQUESTs of type "MARKER_DISPLACEMENT", the angular displacement is in degrees. For all other rotational outputs, the rotation units are in radians.
TYPE = MARKER_FORCE option includes both applied as well as reaction forces and torques between the specified marker pair.
If you want to compute time derivatives for your signals in a reference frame other than Ground, use type = expression. This is much more general, although it involves slightly more work.
If your output signal computation involves a fair amount of logic, use a REQSUB. You can program the REQSUB in C/C++/Fortran or Python. Since the code is compiled and linked or byte-compiled, computations with a REQSUB are faster than computations with EXPRESSIONs.
POST_REQUESTs are meant only for output. You may not feed a signal calculated in a REQSUB back to the model via another user-subroutine, for example, GFOSUB.