Why am I getting "Dimensions of matrices being concatenated are not consistent." after 53 successful reads?

I'm puzzled about this error message after 53 successful reads using the same setup. "Spoiler" inputs print out as "2nd Control Surface" inputs. I've made certain that the input (from an old FORTRAN card deck) has separators (',' or ' ' ), but suddenly it stops working. Also, I did not ask to skip any lines of input.

    -.0014 -.0008 -.0153 -.0187 -.0063 -.0207 -.012  -.0064 -.0052 -.0046 SPOILER,ALSP
  -.0009  .00123 .0014 -.00085-.00438 .0058  .00295 .00297 .0063  .00838   INPUTS,CMSP
     .001      0      0      0      0      0      0      0      0      0  2ND CONTROL,ALFLAP
     .001      0      0      0      0      0      0      0      0      0   SURFACE,CMFLAP
           fmt_num1='%7f%7f%7f%7f%7f%7f%7f%7f%7f%7f'; % 10F7.0
           fgetl(fid);
           XYc=textscan(fid,fmt_num1,1);
           XY=cell2mat(XYc); % line 373
           for i=1:L
               ALSP(i)=XY(i);
           end    

Error using cat
Dimensions of matrices being concatenated are not consistent.
Error in cell2mat (line 75)
          m{n} = cat(2,c{n,:});
Error in CNSMTX (line 373)
         XY=cell2mat(XYc);

[dpb]

Without the data file to look at the precise reason isn't knowable, but the short answer is "because the 54th record doesn't have the same number of elements returned from the internal parser in some element".

Why, we can only guess, but perhaps there's a control character (tab?) or some other non-displaying character in the record or the spacing isn't as you think or whatever but there's something different in that record vis a vis the previous.

BTW, your loop over i on XY is going to overwrite the LHS ALSP on each record; just guessing that should be a 2D array, maybe???

[Walter Roberson]

You can expect these kinds of problems to continue until you switch to the parsing method I already described and gave you several different code sequences for.

[dpb]

Or, as I suggested, mex the Fortran input routine(s) and then can use the existing input files unaltered would be another way...

[Kenneth Lamury]

I misprinted my example (FORTRAN) input data. That read "4 -.0052' in the 9th field. This printing shows the correct input.

-.0014 -.0008 -.0153 -.0187 -.0063 -.0207 -.012  -.0064 -.0052 -.0046   SPOILER
-.0009  .00123 .0014 -.00085 -.0044 .0058  .00295 .00297 .0063  .00838   INPUTS
   .000      0      0      0      0      0      0      0      0      0 2ND CONTROL
   .000      0      0      0      0      0      0      0      0      0   SURFACE

I'm suppose to be reading a 1D row array of 10 fields defined as '%7f'. Each line is a separate array, ie ALSP, CMSP, ALFLAP & CMFLAP, read from a file 1 line at a time. It is then converted from a cell read to numeric data. These 3 lines of code have worked, up to this failed attempt, at least 53 times with positive output. I have previously shown my program & its input file, but I will show them again.

Parsing is new to me. I will have study it more to comprehend its meaning(s). Until then, I will keep "hammering" at a solution.

Thanks for your advice.

[Stephen23]

This question is a continuation of these questions:

http://www.mathworks.com/matlabcentral/answers/293547-can-one-read-one-line-of-string-title-followed-by-multiple-lines-of-numeric-data-like-fortran

http://www.mathworks.com/matlabcentral/answers/294010-what-is-wrong-with-this-fortran-to-matlab-conversion

http://www.mathworks.com/matlabcentral/answers/295153-does-matlab-permit-the-entrance-of-a-loop-from-some-point-outside-of-the-loop

As has been commented many times, the simplest solution would be to call this FORTRAN code from MATLAB.

Answer 1

[dpb]

It fails after the 53rd record because the format changes...

...
49 8.5713 7.0532 6.9459 6.6719 6.915  6.9    6.9    7.4086 9.703 10.7462  M0
50 .0193  .0248  .0414  .003   .0073  .0198  .031   .0249  .0097  .0081   ALPHA
51 -.06   -.0490 -.0526 -.0564 -.0294 -.0384 -.0315 -.0218 -.0138 -.0115   CM0
52 .0913  .0843  .0814  .0608 -.0858 -.1498 -.1954 -.2034 -.2603 -.3058   DCMDCL7
53    0.0                                                               TMACH=0
54 -.0014 -.0008 -.0153 -.0187 -.0063 -.0207 -.012  -.0064 -.0052 -.0046   SPOILER
55 -.0009  .00123 .0014 -.00085 -.0044 .0058  .00295 .00297 .0063  .00838   INPUTS
56   .000      0      0      0      0      0      0      0      0      0 2ND CONTROL
57   .000      0      0      0      0      0      0      0      0      0   SURFACE
58     .5      0      0                                                 THRPIT°
59 .10                                                                   1
60 -.00200  .0665-.00100  .0292
61 -.00340  .0716-.00140  .0292
...

Where I added the line numbers before the records. This includes the header line in the count. Note the group line 49ff is four records of 10 followed by 1 record of one. That's the preceding pattern as well but beginning at record 54 there are the four records but then there's a record of three before the single entry; a different pattern.

After that, the pattern changes again.

Glancing at the m-file, it appears you've done precisely what I recommended most strongly against in trying to literally write the Fortran code in Matlab--instead, spend the time on either Walter's or my suggestions and you'll come out far ahead; I really don't see if you have the existing files why not just use the Fortran with a Matlab wrapper...

Alternatively, if you're adamant on moving the application entirely to Matlab, write it in Matlab from scratch using the features that make Matlab what it is--vectorize the operations and convert the input files into something that can be easily handled with the C i/o routines that are the basis for Matlab's formatted i/o. What you'll end up on the route you're currently embarked upon will be a nightmare going forward for any purpose.

[Kenneth Lamury]

I downsized the number of format statements to one primary (10F7.0) & one or two secondaries ('%80c'). Out of 185 lines I'm able to correctly read/write 158 of them with my 3 lines of code. Yawl mentioned to reduce format options as much as possible. That I understood, but parsing is still beyond my skill level as a Student user. I might re-post my source code at a later date if yawl don't mind.

[dpb]

One question...is the text at end of record of any consequence or is it "comments only"?

"...to one primary (10F7.0)..."

NB: This may work for the given file but it isn't robust to all allowable input files so even if you get it to read this one it could easily break on the next as Walter's example illustrated. (I had thought I remember it worked ok as long as didn't have a missing field but had forgotten about the "don't count characters until a nonblank is found, even if in a counted field" rule. I don't even yet fully understand all the parsing rules under C but I think the only reason the above works as well as it does is that the values all have an explicit decimal point in each field and at least one blank between fields which means you can actually do without the counted width because the blank ends up being the separator between fields, not the counted width.

Consider the following that is a valid input for two records--

l='  0014.101.008';  % two values in F7 
>> [l(1:7); l(8:end)]  % show the two 7-character fields
ans =
0014.
101.008
>> v=sscanf(l,'%7f')   % read with counted width
v =
 14.1000
  1.0080
>>

Note we didn't get what we should've and to make things worse it didn't error; we just got drastically wrong values!

The problem is that it counted seven characters for the first field, it just didn't start until the first nonblank character was found so what it actually read was '0014.10' followed by '1.008'.

Relying on the input to be formatted properly in every possible future case for something like the above to never happen is just asking for trouble of the worst sort--possibly grossly wrong answers from what appears to be correct input looking at the input file.

Note that the

[Walter Roberson]

parsing is still beyond my skill level as a Student user

Earlier, I posted code that only needed to have the vector of field widths adjusted, and which would automatically create the appropriate format and convert the fields to numeric. You decided not to use it, and then spent the next several days continuing to try to solve the same difficulties that my code would have had no trouble with. :(

[Kenneth Lamury]

I'm still not understanding your parsing, but do not fear for I think the attached CNSMTX script file shows my success at reading FORTRAN fixed field formatting (ZLS918_KCR_Test_Dwn.m) and output on the screen and a storage file.

I'm still not relating types of variables, classes, etc. I'm still struggling to remember as many keywords as I can. Rather than playing flying simulator games, learning MATLAB & MathCad are becoming my enjoyments.