Thank you, kitonum, mmcdara, and vv for your comments.  As kitonum has observed, my suggested solution is obviously wrong.  The solutions offered by mmcdara and vv essentially agree and I trust that they are correct.  I cannot claim that I understand the logic behind their solutions right now, but I will think about them.

I misread the question and that led me to the following variant.

Let the sequence a₁,a₂,…,a_n be the outcome of n (n≥6) rolls of a die.  We say that the outcome is wonderful if there is a k so that a_k=1, a_k+1=2, …, a_k+5=6.

Question 1: What is the probability of a wonderful outcome?

Question 2: What is n for which that probability is ≥1/2?

Edit:

If I am not mistaken, the answer to Question 1 is (n-5)/6^6, and therefore the answer to Question 2 is 23333.

Thank you very much, Kitonum and Acer, for your solutions.  These turned out to be much simpler than what I had expected—I had struggled quite a bit with the algebra without success before posting the question here.

@acer Thanks for your detailed comments.  I realize how plots:-display resolves/combines options from the various plot components, and in case of conflicting options it picks one.

That is the reasonable (and the only possible) behavior in general.  The light option, however, deserves to be treated as a special case since multiple light specifications need not be in conflict, but rather have additive effects.

This is not very difficult to do.  I have written graphing programs in OpenGL where multiple lights could be specified.  It may take a only a small tweaking of Maple's command parsing routines to permit multiple lights.

That works fine in Maple 2018.2.  I suggest that you upload your worksheet so that people can have a close look.

Acer and Carl, thanks so much for your comments.  It's the first time I am attempting Maple's Threads and Gird, and I did not know what to expect.

Following your suggestions, I switched from Threads:-Seq to Grid:-Seq and got my code working.  In my real application (not the skeleton one in the my question) I am getting a speedup by a factor or 3 on a quad-core CPU.  That's quite good.

@nepomukk As far as I know there is no simple way of doing that.

@José Goulart In the beam equation the E and I always occur together as the product E*I.  Therefore you don't need to define E and I speparately—define a single variable called EI whose  numerical value is the product of the values of E and I.  That way you will avoid encroaching on Maple's predefined value of I.

@nepomukk Perhaps this is what you are asking?

@Robotron1715 See if this works for you: zz.mws

@nepomukk I don't quite understand what you are asking, but perhaps this may help.

restart;
pde := diff(u(x, t), t, t)-c^2*(diff(u(x, t), x, x));
my_solution := -c^2*(d^2*a*sin(k1*(-c*t+x))/dx^2+2*d*a*k1*cos(k1*(-c*t+x))/dx);
pdetest(u(x,t)=my_solution, pde);

If the proposed solution in my_solution is correct, then pdetest() returns 0.

Verified the filename issue in Linux—same problem as you have described.

That reminds me of the occasional complaints that we read here about inability to load files whose names involve Danish characters. Could be due to the same underlying issue.

@nepomukk Maple can happily deal with expressions involving unspecified constants.  You don't need to assign them numerical values.

It may help to know more about what causes the solution to fail.  Perhaps K blows up at a certain point, or it oscilates too wildly, or beomes complex-valued.  Perhaps K itself may be modified in order to smooth out these issues instead of catching the problem through dsolve's events.

@ecterrab I am thinking that an alternative approach would be to restrict the effect to declared variables only.  To apply the effect to all variables, the user may call declare() with an empty argument.  This can help to avoid pathological cases like those noted by vv.