@jthress1 

Leaving eigenvectors aside for the moment, your symbolic Matrix A appears to have an exact eigenvalue with multiplicity of four. That is, there are only three distinct eigenvalues. Are you saying that is not what you expect? If that contradicts your expectations then perhaps you should resolve that issue before proceeding to eigenvector computation.

For many numeric values of the parameters there can still be six linearly independent eigenvectors, however. It's not clear whether that alone satisfies all your requirements, irrespective of how many distinct eigenvalues your Matrix might have.

@dharr Please see the edit in my followup Comment to my Answer.

It seems to me that the manual solution of the Nullspace (of the CharacteristicMatrix instantiated at each eigenvalue) provides six independent eigenvectors, as computed in my Answer.

It may be only the computation using Eigenvectors -- with forced Normalizer -- that returns the two zero-vectors. Given the presence of radicals in two of the eigenvalues then forcing Normalizer=normal may have been a mistake of mine in the followup..

It seems as if the slow behavior of the LinearAlgebra:-Eigenvectors command (for this example) can be improved by assigning a (straightforward) particular simplifier to Normalizer -- and thus bypassing any "smart" deduction of the normalizer.

Some commands use Normalizer and Testzero to keep down expression swell during row reduction, as well as guard against inadvertant division by hidden zeros while pivoting.

For this example plain old normal is adequate to obtain reasonably short expressions for the eigenvectors.

[edited]
Member dharr points out that two columns of evecsA as computed in the attachment below -- by the Eigenvectors command with Normalizer=u->normal(u) -- are all-zero, which seems to indicate a dearth of independent eigenvectors and a defective Matrix. Yet in the earlier Answer I gave above there appear to be 6 independent non-zero Vectors computed, which each satisfy the definition appropriately. This suggests that the zero-vectors provided by Eigenvectors in the attachment below are incorrect, and those in the Answer above are correct.
Download eigs_LA.mw
[end of edit]

@jthress1 No, the eigenvectors associated with each of the evalsA[ii] are in the sets assigned to evecsA[ii].

There are 4 eigenvectors associated with one of the eigenvalues, which is the same eigenspace for the evalsA[ii], ii=3..6 which are all equal. On the other hand, there is just one eigenvector associated with evalsA[1], and also just one associated with evalsA[2].

That last part of the worksheet is just a verification that the (associated pairs of) eigenvalues and eigenvectors satisfy the definition:
   A . evec = lambda*evec
which all produce the expected zero vectors.

I computed the eigenvectors evecsA[ii] associated with each eigenvalue evalsA[ii] by computing the nullspace (kernel) of the characteristic Matrix (ie. A-evalsA[ii]*IdentityMatrix).

@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