Size of struct within another struct in Matlab (R2010a 64-bit linux)

Question

I'm working with a Matlab API that loads data from a proprietary format into a series of structures. Here's an example of what a dataset looks like after loading a file:

>>fieldnames(data(1))

ans =

'Grid_Point_ID'
'Grid_Point_Latitude'
'Grid_Point_Longitude'
'Grid_Point_Altitude'
'Grid_Point_Mask'
'BT_Data'

>> data(1).BT_Data

ans =

BT_Data: [1x66 struct]

>> fieldnames(data(1).BT_Data(1))

ans =

'Flags'
'BT_Value_Real'
'BT_Value_Imag'
'Pixel_Radiometric_Accuracy'
'Incidence_Angle'
'Azimuth_Angle'
'Faraday_Rotation_Angle'
'Geometric_Rotation_Angle'
'Snapshot_ID_of_Pixel'
'Footprint_Axis1'
'Footprint_Axis2'

I want to loop over all data(i).BT_Data(j). I've already got the length of data fine, but I can't get the size/length of BT_Data (which varies for each data(i)):

>> length(data(1).BT_Data)

ans =

 1

>> size(data(1).BT_Data)

ans =

 1     1

My expected result here is ans = 66 (or equivalent array for size()).

I'm not terribly familiar with the structure data format, which may be part of my struggles. But length(data) worked fine, so I'm confused why it won't work on BT_Data (I've also tried BT_Data(:)).

The most relevant previous answer I can find is 1757250, but I couldn't get it to work (I think it doesn't apply here). Thanks for any insight you can provide.

------ EDIT ------

Here's a little more insight into how I have to use the API to even get to the point where I'm at:

>> system('ln -sf /opt/rwapi-matlab/lib/rwapi/smos/config/xml_rw_api.usr_conf.xml .');
setenv('XML_RW_API_HOME','/opt/rwapi-matlab/lib/rwapi');
path(path,'/opt/rwapi-matlab');

>> prod = RWAPI.product('SM_OPEB_MIR_SCLF1C_20110202T013659_20110202T014642_346_060_1')

Array SMOS Matlab Interface version 1.4
(c) 2010 Array Systems Computing Inc. of Canada (http://www.array.ca)
Distribution or modification of this software requires written permission from Array

prod =

RWAPI.product handle
Package: RWAPI

Properties:
     filename: 'SM_OPEB_MIR_SCLF1C_20110202T013659_20110202T014642_346_060_1'
       header: [1x1 struct]
xml_datablock: []

Methods, Events, Superclasses

>> data = prod.dataset(2)

data =

RWAPI.dataset handle with no properties. Package: RWAPI

Methods, Events, Superclasses

>> data(1)

ans =

       Grid_Point_ID: 251721
 Grid_Point_Latitude: 25.5000
Grid_Point_Longitude: -102.2590
 Grid_Point_Altitude: 1.4714e+03
     Grid_Point_Mask: 2
             BT_Data: [1x66 struct]

>> data(1).BT_Data

ans =

BT_Data: [1x66 struct]

>> data(1).BT_Data(1)

ans =

                     Flags: 6229
             BT_Value_Real: 262.5275
             BT_Value_Imag: 0
Pixel_Radiometric_Accuracy: 6160
           Incidence_Angle: 31966
             Azimuth_Angle: 10299
    Faraday_Rotation_Angle: 65277
  Geometric_Rotation_Angle: 58605
      Snapshot_ID_of_Pixel: 65752530
           Footprint_Axis1: 19649
           Footprint_Axis2: 14625

>> whos
Name Size Bytes Class Attributes

ans 1x1 1 logical
data 1x19091 112 RWAPI.dataset
prod 1x2 112 RWAPI.product

Answer 1

Okay, I really suspect it's an oddity in an overrridden subsref method in those RWAPI classes. I was able to reproduce all your observed behavior by defining a class with a slightly pathological subsref.

classdef stupidref
    %STUPIDREF Reproduce odd indexing behavior that jpatton saw. Buggy.
    properties
        BT_Data = repmat(struct('foo',42, 'bar',42), [1 66]);
    end
    methods
        function B = subsref(A,S)
            s = S(1);
            subs = s.subs;
            chain = S(2:end);

            switch s.type
                case '()'
                    B = builtin( 'subsref', A, s );
                    if ~isempty(chain)
                        B = subsref(B, chain);
                    end

                case '.'
                    % Non-standard behavior!
                    if ~isempty(chain) && isequal(chain(1).type, '()')
                        B = subsref(A.(s.subs), chain);
                    else
                        B = struct(s.subs, A.(s.subs));
                    end
            end
        end
    end
end

This is consistent with the weird difference between data(1).BT_Data and fieldnames(data(1).BT_Data(1)), and the tab-completion that repeatedly adds ".BT_Data".

>> data = stupidref;
>> data(1).BT_Data
ans = 
    BT_Data: [1x66 struct]
>> fieldnames(data(1).BT_Data)
ans = 
    'BT_Data'
>> fieldnames(data(1).BT_Data(1))
ans = 
    'foo'
    'bar'
>> length(data(1).BT_Data)
ans =
     1
>> data(1).BT_Data.BT_Data.BT_Data.BT_Data.BT_Data.BT_Data % produced by tab-completion
ans = 
    BT_Data: [1x66 struct]
>> 

Your workaround is good - once you call a = data(1).BT_Data, you've got a normal struct, and the nonstandard subsref is out of the way. You can get the same effect in a one-liner with getfield.

>> btdata = getfield(data(1).BT_Data, 'BT_Data')
btdata = 
1x66 struct array with fields:
    foo
    bar

I would report this as a possible bug to the RWAPI library authors.

Feel free to just edit this code in to your own workaround answer; it's not really an answer so much as supporting diagnostics.

Answer 2

I've found a workaround, though it's not terribly satisfying:

>> a = data(1).BT_Data

a =

BT_Data: [1x66 struct]

>> length(a.BT_Data)

ans =

66

I'll mark this as the answer for now because I doubt there will be any other "proper" way to do it.

Andrew's answer really nailed down the issue (and why this workaround works).

Answer 3

Some of your results seem contradictory. For starters, if the field BT_Data contained a 1-by-66 structure array, I would expect to see output like this:

>> data(1).BT_Data

ans =

1x66 struct array with fields:
     Flags
     ...    %# etc.

The fact that you see this:

>> data(1).BT_Data

ans =

BT_Data: [1x66 struct]

suggests to me that BT_Data is actually a 1-by-1 structure with one field called BT_Data, and that field contains a 1-by-66 structure array. This would explain what you see when you get the length and size of the first BT_Data (a 1-by-1 structure). If this is the case, you should get the following results:

>> size(data(1).BT_Data.BT_Data)

ans =

     1     66

However, this still doesn't explain the output you see when you do:

fieldnames(data(1).BT_Data(1))

That's throwing me off. You may want to check that BT_Data is actually a structure and not some other type of object that may have different indexing and display behavior by doing this:

isstruct(data(1).BT_Data)

And this should return a 1 if BT_Data is a structure.