MotionView User's Guide

Exporting MDL Model Files to Abaqus

Exporting MDL Model Files to Abaqus

Previous topic Next topic No expanding text in this topic  

Exporting MDL Model Files to Abaqus

Previous topic Next topic JavaScript is required for expanding text JavaScript is required for the print function  

MotionView MDL models can be exported to an Abaqus .inp file.

 

Gravity, Units, and Solver Parameters


This section explains how MotionView works with gravity, units, and solver parameters for Abaqus.

Gravity

Gravity is an implicit data set, meaning that its definition is created automatically by MotionView.  The values for gravity can be accessed through the Forms panel while in the Misc system of a model.  Default values for gravity are set in the std_inc file that is part of the MotionView installation.  A Templex template is also included in std_inc.  This template allows you to write the gravity to the Abaqus input file.    

Units

Although MotionView is a "unitless" interface, it is often required that the units you are working with be communicated to the solver input deck. Similarly, it may be necessary to ensure that the units are consistent. Therefore, the definitions of mass, length, time, and force are automatically generated by MotionView.  To access this, go to the Forms panel and select Units under the Misc system.  The default values as well as the Templex template used for exporting units to Abaqus are generated from the std_inc file.

Solver Parameters

Solver parameters vary considerably between different solvers and are stored in datasets.  There are two ways to generate solver parameter datasets:

Data sets and their corresponding forms are created within the analysis task in the MDL library.  If you are creating your own MDL library, you need to verify that the solver parameter datasets are defined in each analysis task.
No library is used to construct a model.  This includes interactive model construction and the manual editing of .mdl files, or a combination of both.  For this case, MotionView automatically generates the system containing the solver parameters based on a definition within the std_inc file.   \

 

MDL Statement Mapping


The mapping between MDL and the corresponding Abaqus entities are described below.

Note

All property data for these entities are set in corresponding *Set() statements

 

MDL Statement

Abaqus Entity

*ActionOnlyForce()

CLOAD, AMPLITUDE (Time Function only)

*ActionReactionForce()

CLOAD, AMPLITUDE (Time Function only)

*AtPointJoint()

Joint (Connector Section)

*BallJoint()

Joint (Connector Section)

*Beam()

B31(Timoshenko beam)

*Body()

Rigid Body

*Bush()

Connector Behavior

*CoilSpring()

Connector Behavior

*ControlSISO()

None

*Coupler()

None

*Curve()

AMPLITUDE

*CVJoint()

Joint + Constant Velocity (Connector Section)

*CylJoint()

Slot + Revolute (Connector Section)

*FixedJoint()

Weld (Connector Section)

*Graphic()

None

*HookeJoint()

Joint+Universal (Connector Section)

*InlineJoint()

Slot (Connector Section)

*InplaneJoint()

Slide-Plane (Connector Section)

*Marker()

NODE + ORIENTATION

*Motion()

Connector Motion (Time Function only)

*OrientJoint()

Align (Connector Section)

*Output()

Output, History

*ParallelAxisJoint()

Revolute (Connector Section)

*PerpAxisJoint()

Universal (Connector Section)

*PlanarJoint()

Slide-Plane + Revolute (Connector Section)

*Polybeam()

B31(Timoshenko Beam)

*RevJoint()

Joint + Revolute (Connector Section)

*SetFlexbodyComplaince()

Substructure Element

*SolverArray()

None

*SolverDiffEquation()

None

*SolverString()

None

*SolverVariables()

None

*TorsionSpring()

Connector Behavior

*TransJoint()

Slot + Align (Connector Section)

*UniversalJoint()

Joint + Universal (Connector Section)

 

MDL CommandSet Mapping


CommandSets do not apply to the Abaqus solver.

 

Templex Templates and Solvermode


Templex templates can be used to export syntax directly to the solver input deck, including parametric substitution if required.  For the Abaqus solver, the location of statements within the solver input deck is important.  The four keywords listed below allow you to position the extra text.  These keywords must be the first line of the Templex template.  The remaining text of the template is written according to the position specified.

<@ABAQ/MODEL/HEAD>

Designates text that is written at the top of the model data.

<@ABAQ/MODEL/TAIL>

Indicates the end of the model data.

<@ABAQ/HISTO/HEAD>

Indicates the top of the history data.

<@ABAQ/HISTO/TAIL>

<@ABAQ/HISTO/STEP/HEAD>

<@ABAQ/HISTO/STEP/TAIL>

Indicates the end of the history data.

Indicates that data will be written at the start of the first step.

Indicates that data will be written at the end of the first step.

One MDL model can be used to export to more than one solver.  In this case, create the instance of the Templex template using the solvermode reserved keyword.  This can be done in two ways:

For example, an MDL model containing:

if( solvermode == "Abaqus" )

*Template(.....1...)

else

*Template(.....2...)

endif

results in the entire template 1 being used when Abaqus is selected from the Solvers menu.  When another solver is selected, template 2 is used.  When a template is used, it means that it is displayed in the interface on the Templates panel and is acted upon when saving the solver input deck.

To use the keyword, put the required string in the first line of the template.  For example, an MDL model containing:

*DefineTemplate(........)

<@ABAQ/MODEL/HEAD>

 text for abaqus

*EndDefine()

results in "text for abaqus" being exported to the input deck when you select Abaqus as the solver.  The same applies for the portion of template that is displayed in the user interface.

Template Types

A Templex template can have several destinations as well as a unique default behavior.
A USER template does not get exported into any solver file but can be useful for getting parametrically based text into another file (by using the Templex Open and Close commands) or for text targeted for the GUI only.
A SOLVER_INPUT template results in the template text being exported to the .inp file for Abaqus.

The following templates do not apply to the Abaqus solver:

SOLVER_PARAM

GRAPHICS

ADAMS

ACF

 

CommandSets


CommandSets do not apply to the Abaqus solver.

 

Function Expressions


MotionView supports function expressions for many of its entities.  These expressions can be a function of time and state variables.  You can create function expressions that are exported directly as part of a corresponding solver entity.

The solver neutrality is somewhat limited because the solver needs to handle the syntax that MotionView exports.  For the Abaqus solver, supported expressions and curves must be a function of time.  Expressions that are a function of an axial distance between two points are also supported.  MotionView converts these to an XY curve before writing to the input deck.

 

Flexbodies/Substructures


Pre-processing

MotionView allows you to represent an MDL body as an Abaqus substructure.  Before implementing the flexbody into an MDL model, you have to create an Abaqus substructure for each component that you plan on representing as a flexbody.  (Please see Abaqus help for this process).  In addition, you should export an .h3d file of this same component from HyperMesh which will later be used for graphics within MotionView pre-processing.  The base name (basename.ext) of the .h3d file must match that of the substructure files for each component.

To utilize an Abaqus substructure within MotionView, simply toggle a body to Flexbody in the Properties tab.  Identify the .inp and .sup file for the substructure and use the Nodes button to connect the flexbody to the MDL model.  You can choose to align the MDL point to the exact location of the Abaqus connection node or you can enter a tolerance that will be exported to the final Abaqus input deck.

Post-processing

To obtain an animation of the entire model, overlay the animations based on the .odb files corresponding to each sub-structure.  Overlay one animation consisting of MODEL = .mdl and RESULTS = .mrf, where .mrf comes from converting an Abaqus .fil file using Tools > Custom Wizard > Abaqus Fil to Altair Formats.

Note:It is recommended that new bodies are not introduced through Templex templates as doing so can break the mapping required for successful animation.

 

User Subroutines


User subroutines do not apply to Abaqus.  Entities with a reference to user subroutines are not used when exporting to the solver input deck.

 

Launching Solvers from MotionView


MotionView allows you to launch a process automatically after the solver input deck is exported.  For Abaqus, the installation contains default launch scripts located in altair/utilities/mbd/launch_scripts.  One or more of these launch scripts can be registered through the preferences.mvw file and then selected from the Run panel by using the *RegisterSolverScript()preference statement.

Post-Processing

Animation - Transient with Rigid Bodies Only

To animate the results of an Abaqus run that was performed on a model exported directly from MotionView:

1.From the Load Model panel in the Animation window, select the MDL model for the Model field.
2.Select the converted .mrf file for the Result field.

The converted .mrf file can be obtained by running the translator fil2mrf from the Tools > Custom Wizards menu. MotionView does not support the .odb format for rigid body animations at this time.

This method automatically captures all graphics that were set up in the pre-processed model.  Animation depends on mapping, which holds as long as no extra bodies were added in Templex templates, or edited manually from the .inp file.  

Plotting

To plot results from an Abaqus run, you can use the fil2mrf translator to create an Altair binary format (.abf) file.  This file can be loaded directly into the Plot window.  The abf file contains the translational and rotational displacements of all bodies. Any output requests for displacement, velocity and acceleration are written out to the Abaqus ODB file.  Output requests of other kinds are not supported.

 

Defining Stiffness and Damping Characteristics for Springs and Bushing Elements


MotionView allows you to define stiffness and damping characteristics for coil and torsion springs and bushing elements by:

Constant
Curve
Expression

The Abaqus solver does not support expressions.  If you use the Abaqus solver, you can only define stiffness and damping characteristics by a constant or curve.

If you define stiffness and damping characteristics by a constant, your model will run correctly using the ADAMS or Abaqus solver.

If you define stiffness and damping characteristics by curve, use the following conventions to obtain a model that will run correctly using the ADAMS or Abaqus solver.

Spring Damper - Coil Spring- Stiffness

Verify that the independent variable does not contain a minus sign, "-", in the expression.

coil_spring_stiffness_1

Set the characteristic curve with same trend as the curve below:

coil_spring_stiffness_2

Spring Damper - Coil Spring - Damping

Verify that the independent variable does not contain a minus sign, "-", in the expression.  By default, MotionView writes the independent variable with a minus sign, `-{sd_.VR}`, instead of `{sd_.VR}`, as required for a solver independent model.

coil_spring_damping_1

Set the characteristic curve with same trend as the curve below:

coil_spring_damping_2

Spring Damper - Torsion Spring - Stiffness

Verify that the independent variable does not contain a minus sign, "-", in the expression.  By default, MotionView writes the independent variable with a minus sign, `-{sd_.AZ}`, instead of `{sd_.AZ}`, as required for a solver independent model.

torsion_spring_stiffness_1

Set the characteristic curve with same trend as the curve below:

torsion_spring_stiffness_2

Spring Damper - Torsion Spring - Damping

Verify that the independent variable does not contained a minus sign, -, in the expression.  By default, MotionView writes the independent variable with a minus sign, `-{sd_.WZ}`, instead of `{sd_.WZ}`, as required for a solver independent model.

torsion_spring_damping_1

Set the characteristic curve with same trend as the curve below:

torsion_spring_damping_2

Bushing Elements - Translational Characteristics - Stiffness

Verify that the independent variable does not contain a minus sign, "-", in the expression.  By default, MotionView writes the independent variable with a minus sign, `-{bsh_.DX}`, instead of `{bsh _.DX}`, as required for a solver independent model.

This applies to the Y and Z direction as well.

translational_stiffness_1

Set the characteristic curve with same trend as the curve below:

translational_stiffness_2

Bushing Elements - Translational Characteristics - Damping

Verify that the independent variable does not contain a minus sign, "-", in the expression.  By default, MotionView writes the independent variable with a minus sign, `-{bsh_.VX}`, instead of `{bsh_.VX}`, as required for a solver independent model.

This applies to the Y and Z direction as well.

translational_damping_1

Set the characteristic curve with same trend as the curve below:

translational_damping_2

Bushing Elements - Rotational Characteristics - Stiffness

Verify that the independent variable does not contain a minus sign, "-", in the expression.  By default, MotionView writes the independent variable with a minus sign, `-{bsh_.AX}`, instead of `{bsh_.AX}`, as required for a solver independent model.

This applies to the Y and Z direction as well.

rotational_stiffness_1

Set the characteristic curve with same trend as the curve below:

rotational_stiffness_2

Bushing Elements - Rotational Characteristics - Damping

Verify that the independent variable does not contain a minus sign, "-", in the expression.  By default, MotionView writes the independent variable with a minus sign, `-{bsh_.WX}`, instead of `{bsh_.WX}`, as required for a solver independent model.

This applies to the Y and Z direction as well.

rotational_damping_1

Set the characteristic curve with same trend as the curve below:

rotational_damping_2

 

See also

Interfacing with Solvers

SolverMode