@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.

@ecterrab I can't tell whether your final remark is a genuine question or a rhetorical flourish but I will take it as a sincere question and provide a complete answer.

The second paragraph of the help page says "Typically, one declares functions by using declare(f(x, y, z)) with the result that f(x, y, z) is displayed as f ...".  In the third paragraph we have: "This scheme also displays all differentiation variables as indices".  The "all differentiation variables" is ambiguous. I read that as referring to the preceding paragraph and thus was misled to assume that it pertains to declared variables. That's all.

@Ramakrishnan You have described what we see in a worksheet.  But is that consistent with the documentation?  Is that intended or is it a bug?

@vv I see that behavior in a worksheet but is that consistent with the documentation?  The documentation says that variables specified in declare(...) are displayed differently.  It does not say that the other variables are affected as well.  Is the present behavior intentional?  Is it desirable?

@Earl If the car goes around a level circle of radius R vith a constant speed v, then the balance of the gravitational and centrifugal accelerations implies that

v^2 = 2*g*h*R*(R-r) / w^2

where h, r, and w are the track's parameters as in my earlier worksheet.

It is possible to express the path followed by a car through a differential equation but that is not particularly interesting since you will need to include the force exerted by the car's engine if the goal is to approach a steady-state.  In practice, the driver controls the engine's force and the car's direction, which allows to steer the car over just about any arbitrary path.

@vv Yes, if u0 is continuous, then your formula produces a continuous extension.  Dealing with discontinuous u0 requires more effort.

The solution to the Dirichlet problem provides one answer, whether or not u0 is continuous. However, as you have noted, there is no explicit expression for that solution.

In fact, my post is motivated by the question of obtaining the solution of the Dirichlet problem LU=0 in Fourier series (where L is the Laplacian operator).  The first step in producing the Fourier series is to extend the boundary data u0 as a differentiable function u into the interior, and let w = U - u.  Then w is the solution of the Poisson problem Lw = - Lu with null boundary data.  The latter can be solved in the Fourier series in the usual way.

@vv In the "PS" part of my post where I proposed extending the 2D result to 3D, I expected that the detailed assumptions may be inferred from the 2D case.  So yes, the "PS" part taken literally is insufficiently precise.  Let me therefore state the intent fully:

Consider the cube [−1,1]×[−1,1]×[−1,1] and the continuous functions u₁, u₂, u₃, u₄, u₅, u₆ defined on its six faces. Construct a function u(x,y,z) which is continuous in the interior of the cube, and which matches the boundary data.

If the boundary patches are incompatible along the cube's edges, the requirement that u(x,y,z) is continuous in the cube's interior is not met in your proposed construction.

@Christopher2222 

applyop(Student[Precalculus][CompleteSquare]@normal, 1, (5))

where (5) is the label of the final statemenet in your worksheet.