@maple2015 It's taking a long time to compute but I'm really not sure that I entered all the many values correctly. It's onerous to re-enter them.

Could you simply upload a worksheet that contained an explicit definition of KFF? (You might lprint it, or lprint it to a text file.)

Or could you remove the Maplets and hard-code the supplied values?

@basha 666 I don't see any explanation of your use of the term "contour", or any actual description of what precisely you want.

If you have additional details, then please add them as a Comment/Reply to your Question above.

But please don't spam this forum with more duplicates of the question. I'll flag them as duplicates, for deletion.

Are you trying to find the (smallest positive, real) eigenvalues of the Matrix, for each particular numeric value of the parameter?

If so then could you not write a procedure that admitted the Matrix and a value for the parameter, instantiated the Matrix at that value, and computed the floating-point eigenvalues? (If it's symmetric then you might even avoid production of small imaginary artefacts.)

That could be fast, and is also (generally) more robust numerically than computing the float roots of the instantiated determinant of the original Matrix.

There are some options which can speed up the execution of the procedures produced and returned by the call to dsolve (numeric), sometimes at the cost of a slightly more expensive call to dsolve itself. You might try the compile option, but whether you can utilize that will depend on the particular example. Or you might try the option optimize=true , but again the applicability will depend upon the particular example.

Why not tell us more about your intended examples?

I must have been asleep to not see that it is a bvp and the second derivative is present and easily isolated from the de. Coffee time.

@Carl Love Don't you see Adri's original display( Array([P1,P2]) ) as showing the plots side-by-side?

For fun, an edit of Kitonum's code, which works in Maple 17.01 and 2018.1. Without an indexed Cube.

Download cuberoll.mw

@basha 666 In your latest example the differential equations have the independent variables x and eta, and those are used in the associated contour plot.

But your differential equations have the single independent variable y. So what would be the other independent variable in your desired contour plot?

Do you want the contours as curves of points with equal U values? Or (like your latest example's psi) do you want contours of some more complicated function of y, U, C, T, or W?

Do you want the fourth (only) iterate of R, for each Ha in L?

Why don't you answer my other queries, and give a detailed explanation?

@basha 666 

Don't you have any intention of explaining how your determinates C,T,U, and W might correspond to R,X and(?) Ns in the picture?

And why don't you respond to my comment about the role of Ha in your code? Your original code iterated 4 times (thus changing R), for a particular fixed Ha. Do you want each of those iterates (for several Ha values), or just the fourth?

Which of your parameters do you want to vary, as for Beta and epsilon in the picture?

@basha 666 Why do you not say what you mean by "contour" in this context?

The help-page for plottools:-rotate says, "The result of a call to rotate is a 2-D or 3-D plot structure or object that can be displayed with the plots[display] command."

That can only hold if the second argument to plottools:-rotate evaluates to something of type realcons. Otherwise the result would not be a plot stucture that can be displayed with the plots[display] command. There are no examples in that help-page with an unassigned symbolic name being passed as the second argument.

But the supplied code calls plots:-animate with arguments containing things like F[1](t) for unassigned t. And the code is set up so that it then calls plottools:-rotate with unassigned t as the second argument.

So it looks to me like it is one or the other of these cases (but not both):

1) It's a bug that plottools:-rotate does not throw an error when its second argument is not of type realcons, and another bug that its help page does not specifiy that requirement. And the supplied code above worked (previously) in part because of the incorrect lack of argument checking by plottools:-rotate. But the code is wrong to not protect against premature evaluation.

2) It's a bug that the plottools:-rotate help-page claims that the output of that command can necessarily be displayed as is (without any need for substitution of a numeric quantity to replace whatever was actually passed as the second argument, if that was not actually realcons). And it's a regression bug that the second argument can no longer be something not of type realcons. And the supplied code is correctly formed.

I suspect that it is case 1) which holds. I have a hazy recollection of a similar situation some years back, where another plotting routine was "corrected" to no longer admit some arguments which could not be taken as numeric.

But it is unclear, because there are other plottools commands whose help-pages are equally vague about any type restrictions on some arguments, but which also make the same claim that the output is a displayable plot structure. The following seems plain inconsistent:

plottools[line]([x1,y1], [x2,y2]);

            CURVES([[x1, y1], [x2, y2]])

plottools[polygon]([[a,b], [c,d], [e,f]]);
Error, (in Plot:-Structure:-Polygons) points cannot be converted to floating-point values

@tomleslie I agree.

@Honigmelone I got it to work without redefining everything. But using alist (or something done to it) rather than eval(alist,1) was key.

Unfortunately I'm away from a computer for two weeks, sorry.

@mmcdara Yes, using unapply can work here.

Did you mean   unapply('P'(i,1,1,x), x)  so that a procedure P doen't get its call evaluated there?

Using unapply is simpler. You may find it not easy to remember, but it's more convenient than applying subs to an anonymous procedure.

Using subs on a procedure is more powerful, but also more advanced.

That's a common dynamic: flexibility and power versus complexity of usage.

There are other ways, eg. codegen[makeproc] which has some additional kinds of generality.

What is the reason for using eval(alist,1) in the second argument passed to makeproc?

Your attempts to remove assumptions on x and y don't clear this.

hasassumptions(eval(alist,1));
                              true
about(eval(alist,1));
[x, y]:
  is used in the following assumed objects
  [x] assumed real
  [y] assumed real