@acer Thanks for checking this.  My problem may be due to a bug in my Linux distribution (I am using Ubuntu MATE).  I am thinking of booting another distribution of Ubuntu from a flash drive, installing Maple, and seeing how that works.

@Scot Gould Thanks again for checking my test file.  It's become a puzzle for me.

As to your dual-monitor setup, I have no experience with such things.  Perhaps if you ask support@maplesoft.com, they may offer an explanation.

Thank you Christian Wolinski, Scot Gould, and tomleslie for looking into this. I have examined the details of the troublesome plot structures and reduced them to a minimal form that still exhibits the issue.  As before, specifying two distinct colors produces the expected result but specifying two identical colors results in one of the two graph being rendered in black.  Here is the minimal file:

plot-color.mw

I have tried this on three computers with three different graphics cards, and different versions of Ubuntu Linux.  Perhaps this issue is specific to Linux?  I am stymied.

@delvin You are writing D^alpha * u(x,t) for the derivative of order alpha of u(x,t).  That's far from correct.  Here are a few observations.

1. Your notation does't say whether that's derivative with respect to x or t. How is Maple to know which do you mean?
2. The asterisk in your notation indicates multiplication.  But you don't mean to multiply D^alpha and u(x,t).  What is needed there is a differentiation operator acting on u(x,t), not a multiplication.
3. The notation D^alpha means D raised to the power alpha.  But you don't mean to exponentiate D here, do you?  You mean to compose D by itself alpha times.  The Maple notation for that is D@@alpha.
4. But knowing that won't help you since the D@@alpha notation does not say whether it is a derivative with respect to x or with respect to t.
5. Furthermore, the notation D@@alpha is valid only for integer values of alpha.  But your alpha is a fraction, so you should forget about the D operators altogether.
6. Fractional order derivatives are calculated through the fracdiff command in Maple as I illustrated in my original reply.

The problem that you are attempting to solve is far too advanced for a beginner user of Maple.  You should start with much simpler problems to learn about Maple's syntax.  Since you are interested in differential equations, you should get a firm grasp of the differential operator D.  Try analyzing some basic ordinary differential equations.  Then try some classical partial differential equation, such as the heat and wave equations and compare your results to what you have learned from textbooks.

Take up fractional differential equation only after you have gained mastery of the classical ones.  But don't expect that to happen quickly.  These things take time to learn. 

Here is what is being asked.  My brief attempt to verify the assertion was not successful.

PS: The original question does not specify the range of alpha.  I have added the conditions
alpha > 0, alpha < 1, but these may not be what is intended.
 

@nm You wrote: "but it is d'Alembert ode. Maple itself says so". 

Yes, I see that Maple says so.  But look up the definition of the d'Alembert ODE in the help page that I noted in my answer.  Compare that with your ODE.  Is yours of that form?  No!  To put it in that form, you need to square the two sides of your ODE as I explained before.  Probably that's what Maple does (unwisely) when it declares that your ODE is of d'Alembert type.

If you replace the right-hand side of your ODE by its negative, you obtain a completely different ODE.  However, the distinction between the two ODEs disappears when you square the two sides. You can have no assurance that the solution of the squared ODE is that of one or the other ODE.

It's not difficult to verify that the two solution produced by Maple's d'Alembert's method are solutions to the ODE with the changed sign.  Neither one is a solution of your original ODE.

Maple's calculation is correct, but Maple Learn's interpretation of the result is wrong.

The constraint g=x+y=0 is equivalent to y=−x, and therefore the function f = x*y subject to that constraint reduces to f = −x^2 which has a maximum at x=0, not a saddle. That's also evident just by looking at the accompanying plot.

PS: The error lies in the getVals( ) function where SecondDerivativeTest( ) is applied to f while ignoring the constraint.

@vv That's exactly how I have been solving these equations.  I had hoped that Maple may help automate the process.

@tomleslie Thanks for confirming the fix in the Physics update.  I don't have Maple 2022 which is required for that fix.  I will try it out later when I get my hands on Maple 2022.

As I had noted in my original question, my ODE of interest is significantly more complex than the toy example I had posted.  I had only partial success with applying the suggestions that I have received from Acer and Edgardo.  The following worksheet shows the issue.

Download fourth-oder-ODE.mw

Hi Edgardo, that's the quickest ever turnaround of a software fix.  Awsome!

And thanks for pointing out the [exact] option.  I didn't know about it either.

As to the documentation of the parametric option, I went to ?dsolve,details and followed the link parametric solving scheme.  That takes to a page that describes a scheme from Kamke's book.  But the focus there is on first order nonlinear equations.  I could not relate the discussion there to my second order linear equation.  Perhaps I am looking in the wrong place.

PS: I just ran into a related issue.  I will post it as a followup to my original question.  

@acer That's excellent.  I haden't used the parametric option to dsolve before, so I looked up the documentation.  On the first reading, it's not clear to me what Maple does with that option behind the scenes, but it does the right thing anyway, so I am happy.  Thanks for your answer!

If then your expression for T(t) reduces to T(t)=15.  Probably that's not what you meant.  Double-check your statement!

@Tamour_Zubair As I wrote before, expressing a nonlinear system through matrices is not very productive.  To see that, consider this simple system of nonlinear ODEs:

Can you tell me how you would like write that as a system with matrices?  And if you do so, in what way will that be useful to you?

@Joe Riel I installed the latest version of Bark.  Thanks!

I still see no examples directory but that's alright since from what I have figured out by now, this is not something that will be of very much use to me.