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 = 20Kgm2, 22Kgm2, 25Kgm2

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

  1. 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

  2. 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.
  3. 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).
  4. 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).
  5. 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).
  6. 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)
  7. 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.

  8. 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.

  9. For POST_REQUESTs of type "MARKER_DISPLACEMENT", the angular displacement is in degrees. For all other rotational outputs, the rotation units are in radians.
  10. TYPE = MARKER_FORCE option includes both applied as well as reaction forces and torques between the specified marker pair.
  11. 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.
  12. 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.
  13. 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.