The following lists provide a history of changes to IMAT that may impact forward compatibility.
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.