griddedInterpolant for 3D matrix using grid vectors; not enough sample points?

I'm trying to interpolate a large 3D (time-series) double-floating-point variable in one direction efficiently by grid interpolation. Basically, my original matrix is structured as follows (block's colors are colorcoded by magnitude for illustrative purposes):

When I ran the below function on my dataset, it returned an error saying that "interpolation requires at least two sample points in each dimension" -even though my input matrix and grid vectors match (and my matrix is clearly multidimensional)... is there anything I'm doing that's obviously wrong?

Thank you in advance!

function feature = myFunction(axial, lateral, t, d1, other variables)

% "axial", "lateral", and "t" are vectors of different lengths
% "d1" is a 3-D vector (axial x lateral x t)
% "itpfctr" (interpolation factor) is derived somewhere along the lines...

dt=(t(2)-t(1))*itpfctr;
t_interp=(t(1):dt:t(end)); % upsample time vector; "dt" is named for later use
        
x=axial(:)';  y=lateral(:)';  z=t(:)'; % do these even need to be row vectors?
ZZ=t_interp(:)';

gv={x,y,z}; % the grid vector in question

F=griddedInterpolant(gv,d1,'cubic');
d1_interp=F({x,y,ZZ});

%... other calculations using d1_interp that output 2-D matrix "feature"

Answer 1

[John D'Errico]

Since we do not have your actual inputs, only you can know what you did.For exampel, IF you really have what you claim to have, then gridded interpolant has no problem.

gv = {1:4, 1:5 , 1:6}
gv =
  1×3 cell array
    {1×4 double}    {1×5 double}    {1×6 double}
>> d1 = rand(4,5,6);
>> F=griddedInterpolant(gv,d1,'cubic');
>> F({2.5 , 3.5, 1:5})
ans(:,:,1) =
      0.59227
ans(:,:,2) =
      0.16977
ans(:,:,3) =
      0.26829
ans(:,:,4) =
      0.58663
ans(:,:,5) =
       0.6637

But I would conjecture that you only think you know what is in those variables. Sorry, but sloppy programming is the cause of a huge number of mistakes, bugs, etc. People are positive they know what was done. Too often they are wrong. And we know that, because computers tend not to make random mistakes, unless, of course, you have a Pentium chip.

Use the debugger. I would recommend you either put a debug stop in this function, so when it gets called, you are there. Then step through.

If this function will be called often, and an error arises only SOME of the time it is called, then use the debugger!!!!! Issue this command at the command line.Then run your code.

dbstop if error

Check the actual sizes of these variables, not what you are certain they are.

You will find that something is not what you think.

Or, you can actually show the inputs to this code as it produces the error you indicate. Attach those variables in a .mat file to a comment. Honestly, it is easier for you to just use the debugger. You will quickly learn what is the problem, not needing to wait for someone else like me to come along and explain what you did.

[Keita Yokoyama]

I didn't realize you can attach .mat files to question submissions -and while I was preparing to attach my dataset, I realized one of my input vectors was a row of the same number (e.g. [0.25, 0.25, 0.25,... ]). I was under the impression from the documentation that this doesn't matter as long as the vector length was more than one in its long direction, but I guess that doesn't count.

Sorry, and thank you for the detailed explanation!

[John D'Errico]

That often seems to be the case when a bug like this pops up. Checking each of the inputs is a great way to verify that you actually do have what you think you have and what the code needs.

In the case where one of the inputs was a constant vector with all the same elements, griddedinterpolant will at some point need to divide by the stride between a pair of elements in that vector, so a divide by zero would occur. So if griddedinterpolant did not complain as it did, eventually you would just be wondering why an inf or NaN had resulted from your interpolation.