I-deas CAE Data Migration to NX
Jim Bernard
7/8/2008
Background
There is a large base of existing I-deas CAE customers that will be migrating to the NX
CAE product over the next several years. These customers typically will also have I-deas
part and assembly data to migrate as well.
The migration path for this design data is straightforward. I-deas TDM data is migrated to
Teamcenter where it can then be checked out into NX. I-deas CAE data cannot be
migrated using this same path since there are limitations on what CAE data can be
checked into I-deas TDM. In addition, the typical I-deas CAE user does not build their
FE Model directly on a tracked, referenced revision of the design part, but rather on an
unassociated copy of it.
Because of the breadth of solutions offered in I-deas CAE, there is no “one size fits all”
solution for migration to NX Simulation. The needs of an analyst in an integrated design
environment are different than on using I-deas for CAE only on foreign CAD data. Many
users have existing Model Solution simulations and results, while others have Ansys,
Abaqus, Nastran or TMG/ESC, etc. simulations and results. Some users only need a way
to view archived models and results, while others may need to actively modify the model
and define new analysis tasks, and so on.
I-deas CAE to NX Migration Strategies
Based on the constraints outlined above, there are three main migration paths for I-deas
CAE users moving to NX Simulation.
The first is to simply not migrate any data at all. Since I-deas and NX share license keys,
users can have both programs installed and run either from their existing license keys,
switching between the two as needed. Existing projects can be continued and completed
in I-deas, while new projects can be started in NX. This strategy has an added benefit of
allowing the user more time to come up to speed in working with NX Simulation. This is
the recommended path for most users.
The second is for users who have geometry based FE Models in I-deas and who wish to
migrate them to NX, maintaining associativity if at all possible. This is accomplished
using the CMM Native tool which operates on data stored in an I-deas Model file. Using
this tool, users can manually migrate a particular FE Model and the geometry of it’s
associated part to a NX part/fem/sim file set. The CMM Native tool exports up to 4 files
from I-deas: a Nastran bulk data deck containing the finite element model. Properties,
boundary conditions, etc.; a .xpk file containing b-rep geometry of the associated part; a
mapping file that contains geometry associativity and mesh recipe information; and
a .universal file containing analysis results, if any are present in the I-deas model file.
More details on the CMM Native process are provided in the next section.
The third is to manually migrate individual FE Models via some type of analysis input
file. Since the CMM Native tool uses a NX Nastran bulk data deck as the transfer
mechanism, settings specific to other solvers (i.e. TMG/ESC, Ansys, Abaqus) will not be
preserved. If a solver specific file (i.e. TMG/ESC universal file or Ansys/Abaqus input
deck) is manually exported from I-deas and imported into NX, more solver specific
settings and boundary conditions will be maintained. Each user must weigh the tradeoff
between mesh associativity to geometry and preservation of analysis specific settings for
each model to be migrated when determining whether to migrate via CMM Native or a
solver specific file.
CMM Native Details
The primary purpose of CMM Native is to transfer an I-deas FE Model and its associated
geometry to NX Simulation, maintaining as much of that associativity as possible. Since
there is no single mechanism in place to transfer CAE data from I-deas to NX, CMM
Native for FE data uses several methods to complete the transfer:
Part geometry, and optionally history, is transferred via a .xpk file using the same
routines that the Teamcenter embedded CMM tool uses. Details of this are
beyond the scope of this paper.
FE model data (nodes, elements, physical & material properties, boundary
conditions, solution settings, etc.) are transferred via a NX Nastran bulk data deck.
Any entity type that is supported by both the I-deas Nastran export translator and
the NX Nastran import translator can be transferred.
Any results stored in with the FE Model in the I-deas model file are exported to
an I-deas universal file, along with the node/element geometry data necessary for
the universal file to be used to display results in NX Post Processing.
Finally, node and element geometry associativity, geometry based boundary
condition data and mesh recipe (element size, pid, mid) information are exported
to a mapping file.
The CMM Native process imports all of this data into NX and uses the mapping file to
reestablish relations between FE data and the NX geometry wherever possible.
A Nastran bulk data deck was chosen as the medium to transfer CAE data because NX
Nastran is the embedded solver packaged with NX Simulation. Existing I-deas Model
Solution users can begin to migrate from Model Solution to NX Nastran as their solver
while they are still using I-deas as a pre/post processor. Once the Nastran solution is
properly defined and verified in I-deas, moving the FE data to NX via a Nastran bulk data
deck provides the most robust and reliable method for ensuring as much of the design
intent as possible is carried forward.
It is important to note that I-deas and NX are two distinct packages and as such, there are
some fundamental differences in the way they are designed that prevent full compatibility
between the two. For CAE users, there are two major areas that are impacted.
The first is that the NX Modeler does not support non-manifold geometry. The primary
of this on CAE users is that partitioned geometry from I-deas cannot be migrated to NX
with full history support. The CMM Native tool can transfer the orphaned Brep (no
history) geometry. Duplicate faces will be created at any partition locations. These faces
will be connected via a ‘Glue Coincident’ Mesh Mating Condition in the NX fem.
The second is that there is no concept similar to section meshing in NX Simulation.
Sections defined in I-deas will not be migrated to NX Simulation. Users will be able to
update or regenerate a mesh on the underlying geometry, but any edges that were merged
or suppressed in the I-deas Section will be unmerged and unsuppressed in the NX fem.
Boundary conditions defined on sections will be converged to equivalent FE based
entities before the Nastran bulk data deck is exported from I-deas.
It should also be noted that the CMM native process is a manual migration that takes
place on data in a single model file. There is no automated batch processing capability for
large scale conversion of multiple model files.
These factors should be taken in to consideration when a user is deciding which
migration path is most appropriate for his specific circumstances.