The following lists provide a history of changes to IMAT that may impact forward compatibility.
FEMAP
The COM interface with FEMAP works again in R2024b, but there is one subtle difference. When you create a FEMAP entity object such as feNode, feResults, etc., MATLAB now returns a generic Interface.femap_model_Handle_Unknown object. You can interact with these objects the same way as in previous versions, but IMAT needs to know what type of entity they reference. As a result, femap_invoke now returns a femap_entity object that contains the generic MATLAB object along with the type of FEMAP entity it references. femap_invoke requires this object to work properly.
This new behavior should be seamless to the end-user. The only difference is that now when you create an entity object, you must use femap_invoke and not invoke. For example, to create a feNode object, use the following code:
>> happ = actxserver('femap.model')
happ =
COM.femap_model
>> feNode = femap_invoke(happ,'feNode')
feNode =
Interface.femap_model.feNode (femap_entity)
>> set(feNode,'ID',1234);
The writeblk function has changed. The default operation is to no longer write the BEGIN BULK and ENDDATA cards. To enable writing these cards, you must now pass 'addbegin' in as an input.
cmif was returning the reference and response coordinates of the reference shapes REFSHP transposed from the contents of the ordinate data. This has been corrected, so that now REFSHP reference and response coordinates is the transpose of what was returned in previous versions of IMAT.
MATLAB R2024a
The FEMAP COM interface does not work with R2024a due to a bug in MATLAB. This affects both the MATLAB builtin invoke method and IMAT's femap_invoke method. Unfortunately, at this time there are no workarounds other than to use a different version of MATLAB. We have submitted bug reports to Mathworks and are hoping for a fix in a future release of MATLAB.
readnas
CBUSH stress/strain output is now ordered with IMAT component ordering of Sxx,Sxy,Syy,Sxz,Syz,Szz to be consistent with other results. Previously they were ordered as stored in the Output2, which is Sxx,Syy,Szz,Sxy,Sxz,Syz. If you have code that was relying on the output being in a specific index instead of extracting it based on the component number, you will need to modify your code.
We also fixed a bug in CBUSH force output where the node 1 forces were negated when they should not have been. If you have code that was relying on the sign of the CBUSH force output for node 1, please review your code carefully and make appropriate changes. Note that this change does not affect imports using the 'Femap' program mask (opt.global.femap = true).
There are no known compatibility considerations between this release of IMAT and the previous release.
There are no known compatibility considerations between this release of IMAT and the previous release.
In previous IMAT releases, the default plot figure size and placement was hard-coded to be a fraction of the screen size. Users did not have a way of changing the default size and would have to resize the figures after the fact (programmatically or interactively).
Starting in this release, IMAT uses the MATLAB default figure properties for sizing. Users can easily change the default figure position, units, and so on by setting the relevant properties on the groot object. Some examples are shown below. Please see the MATLAB documentation on groot for more details.
>> set(groot,'DefaultFigureUnits','inches'); % Set the default figure units to inches
>> set(groot, 'DefaultFigurePosition', [1 1 6 4]) % Set the default figure lower left corner and size in inches
>> set(groot,'defaultFigureColor',[1 1 1]) % Set the default figure color to white
Starting in Femap 2020, Siemens deprecated the Output class for accessing output vectors. Replacing it is the Results class. This class existed in older versions of Femap, but provided only read-only access to output vectors.
The default behavior in IMAT v8.0.0 is to retain the previous behavior. If you wish to use the new API, you must first initialize femap_invoke by passing in the string 'new', as shown below. All subsequent usage of femap_invoke will use the new API.
>> femap_invoke('new')
If at a subsequent time in your MATLAB session you wish to use the old API, you must first clear femap_invoke from memory using the following command.
>> clear femap_invoke femap_invoke_new_mex % Use this after using the new API
>> clear femap_invoke femap_invoke_mex % Use this after using the old (default) API
There are no known compatibility considerations between this release of IMAT and the previous release.
In previous versions of IMAT, temperature records imported from PCH were imported as a structure whose .data field is a Nx2 matrix, where the first column was the set ID and the second column was the temperature. The record in the PCH file consists of TEMP* bulk data cards.
>> nas = readnas('ndlha001.pch'); % Read the temperature record -- OLD FORMAT
>> nas.records{1}
ans =
title: ' NASHA001 -- UNITS = IN'
subtitle: ''
label: ''
id: [5×1 double]
item: [2 3]
entitytype: 0
seid: 0
datatype: 5
subcase: 1
modenum: 0
zvalue: []
eigenvalue: []
acode: 14
data: [5×2 double]
datachar: []
>> nas.records{1}.data
ans =
2.0000 491.6700
2.0000 634.2838
2.0000 816.3151
2.0000 491.6700
2.0000 614.5751
To produce more consistent handling with OP2 records and OP2 internal storage, starting in this release of IMAT, PCH file temperatures are returned as an Nx6 matrix. Because the record is a nodal record (entitytype = 0) and is Nx6, readnas automatically converts the record to an imat_shp as shown below. The X DOF contains the temperature, and the set ID is found in IDLine4 as the Subcase ID.
>> nas = readnas('ndlha001.pch'); % Read the temperature record -- NEW FORMAT
>> nas.records{1}
ans =
IMAT Shape with the following attributes:
OrdNumDataType IDLine1 NumberNodes
------------------- ------------------- -------------------
Temperature NASHA001 -- UNITS 5
>> list(nas.records{1})
Shape 1 - 1.000000 Hz, 0.000000 %Cr damping
ID Line 1: NASHA001 -- UNITS = IN
Node Disp-X Disp-Y Disp-Z Rot-X Rot-Y Rot-Z
----------------------------------------------------------------------------------------
1 491.67 0 0 0 0 0
2 634.28 0 0 0 0 0
3 816.32 0 0 0 0 0
4 491.67 0 0 0 0 0
5 514.58 0 0 0 0 0
The response directions of many of the SORT2 records have changed to better reflect how they are labeled by Nastran. If you are filtering records by response direction you may need to update the response directions to reflect the new output.
The matrix name for matrices imported from OP2 and PCH used to be a cell containing a string with the name, where matrices imported from OP4 were simply a character array. In this release all of the matrix names have been changed to import as character arrasy to be consistent with OP4 import. Code you have written to use the matrix name may need to be updated to reflect this change.
Below is an example of the previous behavior. Note that the matrix name character array is enclosed in a cell.
>> op2_import.matrix
ans =
struct with fields:
name: {'MATK'}
phase: 0
symmetric: 1
matrix: [96×96 double]
matpool: 1
dof: {[96×1 imat_ctrace] [96×1 imat_ctrace]}
dti: []
Below is an example of the new behavior. Note that the matrix name is simply a character array.
>> op2_import.matrix
ans =
struct with fields:
name: 'MATK'
phase: 0
symmetric: 1
matrix: [96×96 double]
matpool: 1
dof: {[96×1 imat_ctrace] [96×1 imat_ctrace]}
dti: []
NASTRAN has two fundamental matrix formats -- DMI and DMIG. DMI specifies a matrix size, form, and non-zero contents, but does not define row and column DOF. DMIG specifies non-zero contents using DOF. In previous versions of IMAT, DMI matrices were returned as the size bounding the non-zero content, and the DOF were numerical indices into the original matrix. The expandDMI function could be used to expand the matrix back to the full size. The problem with this approach is that the original matrix size was lost, so if the matrix did not have non-zero content in the last row and/or column, it was not possible to expand the matrix to the actual original size. In addition, the matrices would import differently depending on the data source. For example, a given matrix imported from OP2 would import as its full original size with empty DOF fields, but the same matrix imported from PCH format would import as the non-zero content size with numeric index DOF.
Below is an example of the contents of a DMI matrix from previous versions of IMAT.
>> pch.matrix(strcmpi([pch.matrix.name],'MQMGM'))
ans =
struct with fields:
name: {'MQMGM'}
phase: 0
symmetric: 0
matrix: [12×233 double]
matpool: 0
dof: {[12×1 imat_ctrace] [233×1 imat_ctrace]}
dti: []
>> ans.dof{1}
ans =
{'25'}
{'26'}
{'27'}
{'31'}
{'32'}
{'33'}
{'37'}
{'38'}
{'39'}
{'43'}
{'44'}
{'45'}
>> matrix = expandDMI(pch.matrix(strcmpi([pch.matrix.name],'MQMGM')),false);
>> size(matrix) % The original matrix size was 240x233
ans =
45 233
Starting in this version of IMAT, DMI matrices are returned as their original size, and the DOF fields are blank. Thus expandDMI is no longer needed . Matrices also import consistently from OP2, OP4, and PCH formats.
>> pch.matrix(strcmpi([pch.matrix.name],'MQMGM'))
ans =
struct with fields:
name: 'MQMGM'
phase: 0
symmetric: 0
matrix: [240×233 double]
matpool: 0
dof: {[] []}
The physical property import has changed to be more Nastran-centric by default. Previously, to be compatible with I-deas, readnas created additional physical properties for elements that defined their properties directly on the element card rather than on a separate physical property card. Some examples include CELAS2 (stiffness, damping, stress coefficient) CONM2 (mass properties), and CQUAD* and CTRIA* (corner thickness). The new default is to return those properties in the imat_elem .extra property directly with the element rather than creating new physical properties that don't exist in the original Nastran data. The primary advantage to the new behavior is that the readnas import is much more closely correlated with the Nastran contents, allowing for better round-tripping and comparison to Nastran.
It is still possible to import data from Nastran in the previous manner. If you set the global option to use the I-deas program mask, readnas will import properties the same way as previous releases. In the readnas GUI, you can set this option by setting the Program Mask to I-deas in the OP2 Options form). From the command line, set this optionthis option looks like this:
>> opt = []; opt.global.ideas = true;
>> nas = readnas('filename.dat',opt);
There are no known compatibility considerations between this release of IMAT and the previous release.
The following changes have been made to OP2 import using the Femap analysis mask (opt.global.femap=true)
A change in Siemens SimCenter Nastran 2019.1 causes SPOINTs in DMIG matrices to be labeled as DOF 1 in the columns, but DOF 0 in the rows. In previous versions of Nastran the DOF were correctly labeled as 0 in both rows and columns. To work around this, readnas now sets the DOF for all SPOINTs in DMIG matrices to 1 so that they are handled properly (it is impossible otherwise to tell that the DOF is an SPOINT in a DMIG, so we cannot set the DOF to 0). This change could cause issues if you have code that specifically looks for DOF in the DMIG output with a DOF of 0.
There are no known compatibility considerations between this release of IMAT and the previous release.
The imat_node class has a new property called type that stores the entity type. A value of 1 specifies that the entity is a node (NASTRAN GRID), and 2 specifies that the entity is a NASTRAN SPOINT. This should not cause any compatibility issues unless you are expecting a fixed number of properties (that does not include type) in your code. Previously, the only way to tell the difference between a node and an SPOINT was to check the coordinates and the color. An SPOINT had coordinates of 0, 0, 0, and a color of 8. Nodes were returned from readnas with color set to 11.
The imat_elem class has a new property called extra that stores extra element-specific data. Examples of this type of data include CBEAM offsets, orientations, and pin flags, and CQUAD4 element based shell thickness values. Currently only extra properties for certain NASTRAN-defined elements are supported. The supported extra data is documented on the readnas page.
The addition of this property should not cause any compatibility issues unless you have written code that expects a specific list of properties with imat_elem.
The output of readnas when importing PCH files is now different for complex results that are not nodal quantities (e.g. stress). In the PCH file, the real and imaginary (or magnitude and phase) components of a complex result are stored as separate item codes, which are separate columns in the .data matrix in the structure returned by readnas. Previously, readnas combined the two columns into a single column containing complex-valued data, converting magnitude and phase output into complex numbers if the results were written this way. This resulted in data that was processed from the original PCH file contents, and also created an inconsistency between the .item vector (which contained the list of original item codes stored in the .data matrix) and the number of columns in the data matrix (which corresponded to the number of item codes minus the number of imaginary/phase item codes).Starting in IMAT v7.0.0, the data is returned in the original format found in the PCH file, and the .item vector is now always the same length as the number of columns in .data.
The reasons for this change is to keep results even closer to the original NASTRAN format, and also to be more consistent with the output from parseop2table_raw2nas.
This may be better demonstrated by an example. The example below shows the output from a SOL111, modal frequency response analysis. The result shown below is strain output for CBEAM elements. The output below is from IMAT 7.0.0. The .item field contains 110 item codes, and the .data matrix has 110 columns, the contents of which correspond to the item codes in .item.
>> data.records{1}
ans =
struct with fields:
title: ' CANTILEVER BEAM EXAMPLE'
subtitle: ' FREQ RESP SOLUTION'
label: ' X SINE SWEEP 0.1 - 20 HZ'
id: [2×1 double]
item: [1×110 double]
entitytype: 2
seid: 0
datatype: 3
subcase: 1
modenum: []
zvalue: 0.6000
eigenvalue: []
acode: 54
data: [2×110 double]
datachar: []
In contrast, below is the same output as it was imported by previous versions of IMAT. The .item field contains 110 item codes, but the .data matrix only contains 66 columns. All of the item codes corresponding to the imaginary or phase component of a result were combined with the item code corresponding with the real or magnitude component.
>> data.records{1}
ans =
struct with fields:
title: ' CANTILEVER BEAM EXAMPLE'
subtitle: ' FREQ RESP SOLUTION'
label: ' X SINE SWEEP 0.1 - 20 HZ'
id: [2×1 double]
item: [1×110 double]
entitytype: 2
seid: 0
datatype: 3
subcase: 1
modenum: []
zvalue: 0.6000
eigenvalue: []
acode: 54
data: [2×66 double]
One other notable change to PCH file output is the addition of the .datachar field of non-nodal output. Some results contain character strings among the items stored. Previously, readnas returned these as double values, which would then need to be typecast to strings to be used. Starting in IMAT 7.0.0, these are returned in the .datachar field of the output structure. If the result contains character-based items, they are returned in the appropriate column(s) of the cell array of strings contained in .datachar, and the corresponding column in .data is assigned Nan values. If the data type did not contain any character-based items, the .datachar field is set to an empty matrix.
The OEFIT datablock now reads in as Data At Nodes On Elements, rather than Data On Elements. This was done to be consistent with support for the failure index datablocks OEFIIP and OEFIIS, which can contain centroidal and nodal results. OEFIT failure indices are labeled as centroidal (node 0), starting at layer 1.
There are no known compatibility considerations between this release of IMAT and the previous release.
There are no known compatibility considerations between this release of IMAT and the previous release.
The imat_filt data type has been enhanced so that it can work with imat_shp in addition to imat_fn. There are no compatibility issues with existing code, as it defaults to an imat_fn-compatible filter, but there is a new calling sequence to use it with imat_shp. When an imat_filt is created, you must specify (either explicitly or implicitly) what data type it will work with. You cannot change the target data type once the filter has been created.
To create an imat_filt for use with imat_shp, pass in an imat_shp as the first input argument to imat_filt. You can either pass in imat_fn or pass in just the filter criteria to create an imat_fn-based filter. See the code snippet below for examples.
>> zs = imat_filt(imat_shp,'ShapeType','=','Real') % Create an imat_filt specifically for imat_shp
zs =
...for objects of type 'imat_shp'
ShapeType == 'Real'
>> zf = imat_filt(imat_fn,'FunctionType','=','Time Response') % Create an imat_filt specifically for imat_f
zf =
...for objects of type 'imat_fn'
FunctionType == 'Time Response'
>> zf = imat_filt('FunctionType','=','Time Response') % Old calling format, functionally equivalent to the above
zf =
...for objects of type 'imat_fn'
FunctionType == 'Time Response'
There are no known compatibility considerations between this release of IMAT and the previous release.
The global Cartesian, or basic, coordinate system ID has been renumbered from 1 to 0 to be consistent with NASTRAN nomenclature. This affects import and export operations in IMAT as well as plotting and coordinate transformations.
Several IMAT functions have been modified, and the changes are described below.
FEM entities will automatically be updated when loading from a MAT file. Coordinate systems with an ID of 1 whose transformation matrix is the identity matrix and whose origin is at (0,0,0) will be renumbered to 0. Nodes that reference a coordinate system of 1 will change the reference to 0.
readnas import defaults have changed. Not the OPT structure field OPT.global.renumbercsys has a default of FALSE. In addition, this field is modified as appropriate if you select the OPT.global.ideas or OPT.global.Femap options.
readunv modifies any references to CS1 in the node and coordinate system datasets to 0 on import.
writeunv modifies coordinate system IDs of 0 in node and coordinate system datasets being exportd to 1. If a coordinate system ID of 1 already exists, it will be renumbered to the maximum ID present + 1.
imat_fem/xform, imat_shp/xform, and imat_fn/xform now display a warning if you call it with a TO coordinate system ID of 1, to alert you that if you are attempting to transform to the global Cartesian system, the calling arguments have changed. Please see the section below on migrating code to IMAT 6.0.0 for more information.
To migrate your code to the new coordinate system nomenclature, it is likely that all you will need to do is search your code for instances of using XFORM to transform coordinate systems to global Cartesian (basic), and replace 1 with 0, as in
xform(...,1);
changes to
xform(...,0);
Code that references coordinate system IDs in both imat_cs and imat_node may also need to be modified.
IMAT's element type numbering has been changed from I-deas-centric numbering to NASTRAN-centric numbering. The primary reason for this change is so FEM elements in IMAT use the same element types as the results returned by readnas. A secondary reason is that I-deas usage is declining, and its users are migrating to Siemens NX and Femap, both of which are more NASTRAN-centric.
Several IMAT functions have been modified, and the changes are described below.
Only users who have developed scripts and functions that use the element type number will be affected by this change. One migration path is to modify your code to use the NASTRAN-centric numbering, which is documented here. Another path is to use the imat_elem method elemtype_n2i. to convert the new numbering to the old. This method has the disadvantage that the element types do not always map cleanly.
There are no known compatibility considerations between this release of IMAT and the previous release.
There are no known compatibility considerations between this release of IMAT and the previous release. However, the graphics engine in MATLAB R2014b is significantly different from previous releases, so graphical user interfaces may look and behave slightly differently.
The Reaction Force data type value for AbscissaDataType, OrdNumDataType, OrdDenDataType, and ZAxisDataType has been renamed to Force. If you attempt to set any of these to Reaction Force, a warning message will issue but the attribute will be set to Force.
The Reaction Force data type value for OrdNumDataType and OrdDenDataType has been renamed to Force. If you attempt to set any of these to Reaction Force, a warning message will issue but the attribute will be set to Force.
Starting in IMAT v4.4.0, imat_result's Frequency attribute returned the damped natural frequency for complex modes. In this release, the Frequency attribute now returns the undamped natural frequency, and the ViscousDamping attribute returns the correct viscous damping value.
The method list_shape has been renamed to list. list_shape will be removed in a future release of IMAT.
There are no known compatibility considerations from this release to the previous release.
The 'records' input argument for readnas is now obsolete. To read a subset of results from an Output2 file, previously you would pass in the string 'records' followed by a list of record numbers to read. For example:
f = readnas('modes_run.op2','blocks',{'BOUGV1'},'records',[5 7:10 15])
This functionality has changed act more like a filter. Currently you can filter by mode number and/or subcase. Typically dynamic results (e.g. SOL103) will use the mode number filter, and static results will use the subcase filter. For example, to read select modes from a file (for all subcases):
f = readnas('modes_run.op2','blocks',{'BOUGV1'},'modes',[5 7:10 15])
To filter by subcase, use the 'subcases' argument. For example, to read all of the displacement results for subcase 2,
f = readnas('modes_run.op2','blocks',{'BOUGV1'},'subcases',2)
You can also filter by both subcase and mode number simultaneously. To read modes 2 and 4 for subcase 3, call readnas like this:
f = readnas('modes_run.op2','blocks',{'BOUGV1'},'modes',[2 4],'subcases',3)
The previous IMAT release introduced the imat_result data type. In this release, the old result data type has been deprecated and replaced by the imat_result data type. While mostly compatible, there are some key differences between the two data types. Please read the user guide page on how to use the imat_result data type, even if you are already familiar with the old result data type. This section only highlights the key differences between the two.
The imat_result class is mostly compatible with the result class. The descriptive attributes are the same, but accessing the components and data is different. This section highlights the differences. The table below shows the different ways to get and set components and data for result and imat_result objects.
| Get Attributes | |
| result | imat_result |
| r.NumericComponents | r.data.component |
| << No equivalent >> | r.data.node, r.data.element, r.data.comp, r.data.layer, etc. |
| r.Data | r.data.data |
| r.Component | << No equivalent >> |
| << No equivalent >> | getComponents() |
| Set Attributes | |
| result | imat_result |
| .NumericComponents | setComponents() |
| << No equivalent >> | r.data.node, r.data.element, r.data.comp, r.data.layer, etc. |
| r.Data | r.data.data |
The primary difference between the old and new data types is how data and components are accessed. With the result object, specifying the DataLocation involved setting the DataLocation attribute, as shown in the examples below.
>> r=result(1,'DataLocation','Data at nodes on elements');
>> r=result(1);
>> r.DataLocation = 'Data at nodes on elements';
With imat_result, the components and data are objects stored in the .data property of the imat_result. As such, the DataLocation is specified simply by passing in the appropriate object.
>> r=imat_result(1,imat_result_danoe);
>> r=imat_result(1);
>> r.data = imat_result_danoe;
DataLocations can no longer be modified after data and components have been set.
The imat_result DataLocation classes introduce components that were not available in the result object. The component lists for each DataLocation class are shown in the table below. New components are highlighted in blue.
| DataLocation class | Component | Description |
| imat_result_dan | node | Node ID |
| dir | Direction | |
| seid | Superelement ID | |
| imat_result_doe | element | Element ID |
| layer | Layer ID | |
| seid | Superelement ID | |
| eltype | Element type | |
| imat_result_dap | point | Point ID |
| imat_result_danoe | element | Element ID |
| node | Node ID | |
| comp | Component | |
| layer | Layer ID | |
| seid | Superelement ID | |
| eltype | Element type | |
| imat_result_doean | node | Element ID |
| element | Node ID | |
| comp | Component | |
| eltype | Element type |
The result object provided two separate attributes for accessing components. The .Component attribute returned a cell array containing string representations of the components. The .NumericComponents attribute returned a numeric matrix containing the attributes. The columns in this matrix depended on the DataLocation.
The imat_result object only has the equivalent of the .NumericComponents attribute. The .component property is available from the appropriate DataLocation object, and is accessed through the .data property of the imat_result, as shown below.
>> r(1).data.component
ans =
1 1 11 1 0 0
1 1 12 1 0 0
1 1 22 1 0 0
1 1 13 1 0 0
1 1 23 1 0 0
1 1 33 1 0 0
1 1 11 2 0 0
1 1 12 2 0 0
1 1 22 2 0 0
1 1 11 2 0 0
Components can be accessed by retrieving the individual columns directly, as shown in the example below. Each DataLocation object defines different columns.
>> [r(1).data.element(1:4) r(1).data.comp(1:4)]
ans =
1 11
1 12
1 22
1 13
Setting components can be done by setting the individual components directly. However, the preferred way is to use the setComponents method, as shown below.
>> r = imat_result(1;)
>> r.data = imat_result_dan;
>> r.data= setComponent(r(1).data,[1 1 1],[1 2 3],[0 0 0],false,11:13);
>> r.data
ans =
Data At Nodes: 3DOF global translation vector
================================================
Node Dir SEID Data
------------------------------------------------
1 1 0 11
1 2 0 12
1 3 0 13
------------------------------------------------
Number of Values: 3 Number of Nodes: 1
================================================
This release of IMAT has introduced a new attribute, .CSType. This stores the type of coordinate system in which the shape coefficients are stored: 'Displacement', 'Basic', or 'Other'.
When importing shapes from readnas, .CSType will be set to 'Displacement' unless the datablock name starts with 'B' or the TransformToBasic option was turned on. In this case, .CSType will be set to 'Basic'.
When importing from Universal file with readunv, .CSType is always set to 'Basic', since this attribute is not defined in the Universal shape datasets (55 and 2414). I-deas stores shape coefficients in the global coordinate system by default in Universal files. Also, since there is no place to store this attribute in the Universal formats, it will be lost when round-tripping shapes through a Universal file.
ADFs by default store their shape coefficients in the displacement coordinate system(s). The ASH format does not have an official location to store the .CSType attribute in the shape header blocks. However, there are unused locations in the header, so ATA has appropriated word 39 in the header for this attribute. Since ATA does not control the ADF format, it is possible that this information could be lost in the future. However, ATA does not believe this is too likely. ASH files created by Siemens NX or I-deas software (or any other 3rd party software) will not have this attribute set, so when IMAT imports these, the .CSType attribute will be set to 'Displacement'. ASH files written by IMAT will write the attribute to the file appropriately. This attribute should survive access by other software, but ATA cannot make any guarantees.
The behavior of shape transformation is slightly different with the introduction of the .CSType attribute. Previously, if CSFROM was not supplied, xform would assume that the "from" coordinates were the displacement coordinates found in column 2 of the fem.node.cs attribute. Now, xform uses the .CSType setting. It also sets this attribute accordingly after transforming the shape coefficients. Note that if the .CSType attribute is set to 'Other', the CSFROM argument must be supplied.
In previous versions of IMAT, coordinate trace directions could not contain digits. This limitation has been lifted starting in this release of IMAT. The only known compatibility issue is that I-deas is not compatible with these coordinate directions, so do not use them when exporting files that will be used by I-deas.
There are no known compatibility issues between v4.0.0 and v4.1.0.
New with this release, the FEM structures have turned into classes (objects). There are 5 new classes: imat_fem, imat_cs, imat_node, imat_elem, and imat_tl. These classes operate more or less like the structures they replaced, so the transition should be fairly seamless. In most cases your existing code should continue working as-is, though you may see some warning messages about obsolete functions. The function names beginning with fem_ have been renamed.
The new classes do consistency checking in the property setting. This ensures that your FEM data is coherent. However, if you are used to appending FEM data by simply expanding the structure field contents, this will no longer work. To work around this, you have one of two options. The first is to convert your objects into structures, append to the fields, and then convert it back to the object. The other solution is to use the appropriate ADD method. The following code block demonstrates both methods for an IMAT_NODE object.
>> % OLD STRUCTURE-BASED METHOD
>> ns
ns =
id: 1
cs: [1 1 1]
color: 11
coord: [0 0 0]
>> ns.id(end+1)=2;
>> ns.cs(end+1,:)=[1 1 1];
>> ns.color(end+1)=11;
>> ns.coord(end+1,:)=[1 1 1];
>> ns
ns =
id: [1 2]
cs: [2x3 double]
color: [11 11]
coord: [2x3 double]
>> % FIRST NEW APPROACH
>> n
n =
IMAT_NODE - Nodes
ID Def CS Disp CS Store CS X Y Z Color
-------- ---------- ---------- ---------- ------------ ------------ ------------ --------
1 1 1 1 0 0 0 11
>> ns=struct(n);
>> ns.id(end+1)=2;
>> ns.cs(end+1,:)=[1 1 1];
>> ns.color(end+1)=11;
>>ns.coord(end+1,:)=[1 1 1];
>> n=imat_node(ns)
n =
IMAT_NODE - Nodes
ID Def CS Disp CS Store CS X Y Z Color
-------- ---------- ---------- ---------- ------------ ------------ ------------ --------
1 1 1 1 0 0 0 11
2 1 1 1 1 1 1 11
>> n=imat_node(ns)
>> % SECOND NEW APPROACH
>> n
n =
IMAT_NODE - Nodes
ID Def CS Disp CS Store CS X Y Z Color
-------- ---------- ---------- ---------- ------------ ------------ ------------ --------
1 1 1 1 0 0 0 11
>> n=n.add(2,[1 1 1],11,[1 1 1])
n =
IMAT_NODE - Nodes
ID Def CS Disp CS Store CS X Y Z Color
-------- ---------- ---------- ---------- ------------ ------------ ------------ --------
1 1 1 1 0 0 0 11
2 1 1 1 1 1 1 11
To see the list of available properties in the imat_fem object or any of its component objects, use the properties() method.
>> fem = imat_fem;
>> properties(imat_fem)
Properties for class imat_fem:
cs
node
elem
tl
>> properties(fem.node)
Properties for class imat_node:
id
cs
color
coord
Prior to this release, groups were loosely supported from Universal files by three sample readunv plugins. In this release, a new IMAT_GROUP object has been introduced. Its format and contents largely follow the group structure imported previously, except that the 2 columns of data are stored in reverse order from what was returned from the plugins. If you are using groups stored in the old group structure, be sure to swap the data columns when creating the IMAT_GROUP object.
The function plotting architecture has been completely overhauled. Instead of PLOT returning a uipanel handle as it did previously, it now returns an IMAT_FNPLOT object. This object gives you significant control over the plot display, allowing you to modify the plot after it has been generated. As a result, set_fnplot_style has been deprecated, because the imat_fplot object provides all of the functionality this function used to provide, and more.
PCH file result blocknames have been renamed to reflect theirSORT type, and to make the naming consistent with Output2. For example, OUG has been renamed to OUGV1 for SORT1 format. Smilarly, OEF has been renamed to OEF1. The implications of this are that if you read in results using blocknames using the'blocks' specifier, you will need to rename the blocks you are specifying.
The sign on CELAS force output has been reversed, to be compatible with Ideas dataset 2414 and PCH.
The imat_fn class adds the LoadCase attribute back. There are no compatibility issues with this change.
The readnas 'blocks' specifier for PCH file import has been modified. Previously the specifier had to be a 1x2 cell array, where the first cell contained 'PCH' and the second cell contained the numeric indices of the records to read. The string 'PCH' is no longer required. The old format is still supported, but a warning will issue.
For example, the old format for reading records 1, 3, and 5 from the PCH file was
f=readnas('file.pch','blocks',{'PCH' [1 3 5]})
The new calling method is
f=readnas('file.pch','blocks',{[1 3 5]})
Another enhancement to this specifier is that now you can also use block names instead of numeric indices. For example,
f=readnas('file.pch','blocks',{{'OUGV1' 'PCHBULK'}})
The ideas_fn, ideas_shp,ideas_filt and ideas_ctrace classes have been obsoleted and replaced with imat_fn, imat_shp, imat_filt and imat_ctrace. The new classes come with a lot of benefits, including the ability to easily subclass. If you don't know what this means, don't worry. The net change for users is simply that the old class names have been replaced with new class names. The old classes will continue to work for the time being, although they will be removed in a future release of IMAT.
Please see below for specific changes to each class.
There is no functional difference between ideas_ctrace and imat_ctrace. Simply replace all references of ideas_ctrace with imat_ctrace.
To convert between an ideas_ctrace and an imat_ctrace, simply recast one to the other. An example is shown below.
>> t = ideas_ctrace('1x','2z','3qq')
t =
'1X+'
'2Z+'
'3QQ'
>> t2 = imat_ctrace(t)
t2 =
'1X+'
'2Z+'
'3QQ'
>> t2.name = 'test'
test
t2 =
'1X+'
'2Z+'
'3QQ'
>>
When using imatctrace in a struct call, you will need to wrap the imat_ctrace in curly braces. Previously with ideas_ctrace this was not necessary. For example, the following code
>> s = struct('field1',ideas_ctrace('1x'),'field2','text')
s =
field1: [1x1 ideas_ctrace]
field2: 'text'
>>
will no longer work. You will see an error message like this:
>> s = struct('field1',imat_ctrace('1x'),'field2','text')
??? Error using ==> imat_ctrace.struct
Too many input arguments.
Instead, do this:
>> s = struct('field1',{imat_ctrace('1x')},'field2','text')
s =
field1: [1x1 imat_ctrace]
field2: 'text'
>>
There is no functional difference between ideas_filt and imat_filt. Simply replace all references of ideas_filt with imat_filt.
To convert between an ideas_filt and an imat_filt, simply recast one to the other, as shown in the example above.
Generally speaking, there are very few functional differences between ideas_shp and imat_shp. Simply replace all references of ideas_shp with imat_shp. Internally the order of the numeric and string attributes have changed, but if you are not accessing these attributes directly by converting the shape into a structure, you will not be impacted by this change.
One difference in behavior is the outcome of calling the constructor with no input arguments. The ideas_shp class returns an empty object, but imat_shp returns a scalar object. To create an empty imat_shp, pass in an empty matrix, as shown below.
>> ideas_shp
ans =
I-DEAS Shape (empty)
>> imat_shp([]) % Equivalent to calling ideas_shp with no input arguments
ans =
IMAT Shape (empty)
>>
To convert between an ideas_shp and an imat_shp, simply recast one to the other, as shown in the example below.
>> s=ideas_shp(3)
s =
3x1 I-DEAS Shape with the following attributes:
Row Frequency Damping NumberNodes
--- ------------------- ------------------- -------------------
1 1 0 0
1 1 0 0
1 1 0 0
>> t=imat_shp(s)
s =
3x1 IMAT Shape with the following attributes:
Row Frequency Damping NumberNodes
--- ------------------- ------------------- -------------------
1 1 0 0
1 1 0 0
1 1 0 0
>>
Another important change involves how attributes are returned from the get and set methods. The ideas_shp class had some inconsistencies with what it returned from get, between scalar and array outputs for attributes stored internally as numeric and those stored as strings. The former were returned as strings for scalar output, while the latter were returned as a single cell. imat_shp returns all of these attributes consistently, where scalar output is returned as a string, and array output is returned as a cell array of strings.
Finally, when using imat_shp in a struct call, you will need to wrap the imat_shp in curly braces. Previously with ideas_shp this was not necessary. For example, the following code
>> s = struct('field1',ideas_shp(1),'field2','text')
s =
field1: [1x1 ideas_shp]
field2: 'text'
>>
will no longer work. You will see an error message like this:
>> s = struct('field1',imat_shp(1),'field2','text')
??? Error using ==> imat_shp.struct
Too many input arguments.
Instead, do this:
>> s = struct('field1',{imat_shp(1)},'field2','text')
s =
field1: [1x1 imat_shp]
field2: 'text'
>>
Generally speaking, there are a few functional differences between imat_fn and imat_fn. The differences that do exist are highlighted below.
Several attributes that no longer serve a useful purpose have already been removed.
| ideas_fn attribute |
imat_fn attribute |
| AbscissaOffset | <removed> |
| MaxOrdValReal | <removed> |
| MaxOrdValImag | <removed> |
| MinOrdValReal | <removed> |
| MinOrdValImag | <removed> |
| OrdOffsetReal | <removed> |
| OrdOffsetImag | <removed> |
| OrdScaleReal | <removed> |
| OrdScaleImag | <removed> |
| OctaveOverallRMS | <removed> |
| OctaveWeightedRMS | <removed> |
| LoadCase | <removed> |
| CoordSys | <removed> |
| ResponseEntity | <removed> |
| ReferenceEntity | <removed> |
Another difference in behavior is the outcome of calling the constructor with no input arguments. The imat_fn class returns an empty object, but imat_fn returns a scalar object. To create an empty imat_fn, pass in an empty matrix, as shown below.
>> ideas_fn
ans =
I-DEAS Function (empty)
>> imat_fn([]) % Equivalent to calling imat_fn with no input arguments
ans =
IMAT Function (empty)
>>
To convert between an ideas_fn and an imat_fn, simply recast one to the other. Some examples are shown below.
>> f=ideas_fn(3)
f =
3x1 I-DEAS Function with the following attributes:
Record Name FunctionType AbscissaSpacing NumberElements
--------------------------- ---------------- ---------------- ----------------
1_(1X+,1X+) Time Response Even 0
2_(1X+,1X+) Time Response Even 0
3_(1X+,1X+) Time Response Even 0
>> g=imat_fn(f)
g =
3x1 IMAT Function with the following attributes:
Record Name FunctionType AbscissaSpacing NumberElements
--------------------------- ---------------- ---------------- ----------------
1_(1X+,1X+) Time Response Even 0
2_(1X+,1X+) Time Response Even 0
3_(1X+,1X+) Time Response Even 0
>> g.responsenode=1:3
g =
3x1 IMAT Function with the following attributes:
Record Name FunctionType AbscissaSpacing NumberElements
--------------------------- ---------------- ---------------- ----------------
1_(1X+,1X+) Time Response Even 0
2_(1X+,2X+) Time Response Even 0
3_(1X+,3X+) Time Response Even 0
>> h=imat_fn(g)
h =
3x1 IMAT Function with the following attributes:
Record Name FunctionType AbscissaSpacing NumberElements
--------------------------- ---------------- ---------------- ----------------
1_(1X+,1X+) Time Response Even 0
2_(1X+,2X+) Time Response Even 0
3_(1X+,3X+) Time Response Even 0
>>
Another important change involves how attributes are returned from the get and set methods. The ideas_fn class had some inconsistencies with what it returned from get, between scalar and array outputs for attributes stored internally as numeric and those stored as strings. The former were returned as strings for scalar output, while the latter were returned as a single cell. imat_fn returns all of these attributes consistently, where scalar output is returned as a string, and array output is returned as a cell array of strings.
Finally, when using imat_fn in a struct call, you will need to wrap the imat_fn in curly braces. Previously with ideas_fn this was not necessary. For example, the following code
>> s = struct('field1',ideas_fn(1),'field2','text')
s =
field1: [1x1 ideas_fn]
field2: 'text'
>>
will no longer work. You will see an error message like this:
>> s = struct('field1',imat_fn(1),'field2','text')
??? Error using ==> imat_fn.struct
Too many input arguments.
Instead, do this:
>> s = struct('field1',{imat_fn(1)},'field2','text')
s =
field1: [1x1 imat_fn]
field2: 'text'
>>
readnmat has been deprecated and will be removed in a future release of IMAT. The readnmat functionality is available in readnas. The current readnmat functionality actually calls readnas internally. Since the calling arguments and outputs are slightly different between the two functions, the source code for the readnmat wrapper is provided.
Three functions have been renamed. In all cases the function name is different, but the calling sequence is identical. You can simply search/replace in your code to change the function names. The old function names are ideas_progress, ideas_getfile, and ideas_putfile, and the corresponding new function names are imat_progress, imat_getfile, and imat_putfile.