@dharr I agree with your observation regarding user-friendliness of error messages.  As much as it is tempting to perform type-checking at the level of parsing a proc's args, that can lead to cryptic error messages as you have noted.

Customized parsing of the args adds a few extra lines of code but that can be worth the effort in a proc which is meant to be called at the top-level by other users.  And as you have noted, that "other user" can be you!

That said, Carl in his responses has pointed out that there are cases where type-checking at the argument level can be justified.  That's something to have in mind when writing a general-purpose code that's expected to have a lifetime of more that a few days.

@Carl Love That's a great overview of Maple's algebra of types, and now I clearly see the logic behind the solution that you had offered to my question.  It would have been difficult for me to deduce all that by reading the help pages.

Among other things, I was surprised to learn that {f}(x) is equivalent to {f(x)}.  Very curious.

I am saving your mini-tutorial for future reference.

@Carl Love That's excellent but a bit over my head.  But that's a good thing—it motivates me to dig into the manuals to figure it out.

@acer That's excellent.  Thanks!

@abdulganiy Your PDE is nonlinear, and consequently the system of ODEs produced by the Method of Lines is also nonlinear.  There is no such a thing as a "matrix representation" for a nonlinear system.

@Hnx You have 

hz3 := subs(phi2 = hz2, hz1);

That should be

hz3 := subs(phi2(t) = hz2, hz1);

Additionally, the assumptions on your first line don't seem to be essential but they result in clutter in the displayed formulas.  I suggest removing them.  Here is what we get (in the worksheet mode with 1D input, which is my preference):

Download mw.mw

@Earl I don't see how that can be done.

@acer Yes, I too have noticed that statement regarding plot3d,viewpoint in the help page, but I haven't run into problems in the few instances where I have combined animation with viewpoint.

As to the number of viewpoint's frames, it appears that it is automatically inherited from the underlying animation.  The animation in this post consists of 181 frames.  In the last line, changing the viewpoint=circleleft to viewpoint=[circleleft, frames=100] (or any other number instead of 100) does not seem to affect the animation.  That's good if it's actually the case.

On an unrelated note, I want to point out that the polyhedron proc in the original post can be shortened quite a bit, like this:

polyhedron := proc(V::list, F::list)
  local f;
  plots:-display([seq(plottools:-polygon(V[f]), f in F)]);
end proc:
 

@Joe Riel You are right.  I don't know why I thought I was getting zero.

@janhardo I suggest that you post your attempts at solving those exercises, otherwise it is not clear what level of help will be beneficial to you.

@Kitonum That's very good.  Vote up!  But do you know why that doesn't work when we replace posint with integer?

int(cos(m*t)*cos(n*t), t=-Pi..Pi, allsolutions) assuming integer;

This one returns 0 in Maple 2020.

@Thomas Richard Thanks for looking into this.

@Hamza Brhl 

Download mw.mw

@Mariusz Iwaniuk As Lopez has pointed out, Maple's numeric PDE solver handles time-dependent equations in one space dimension.  This class of problems are particularly easy to solve since the domain of the unknown function is a strip
D = { (x,t),  a < x < b,  t > 0}
in which the derivatives may be readily discretized through finite differences.

In the same way, elliptic equations in 2D are also easy to solve through finite differences provided that the domain is a rectangle.  But a rectangular domain is too limiting to be of general interest.  To be useful, an elliptic equation solver should be able to handle domains of more or less arbitrary shapes (at least in 2D).  That makes applying a finite difference discretization difficult, if not impossible.

That's why essentially all elliptic equation solvers are implemented through finite elements which is a whole different ball game.  If Maplesoft goes in that direction, it will need to add a dedicated department, and staff to implement the software and to deal with what I predict will be a never-ending stream of requests for enhancements and additional features.

@mary120 From the little information that you have provided, it appears that you are using the symbol f in two different senses: (a) as one of the unknowns in your system of differential equations, and (b) as a parameter that you have defined as 0.42. 

In the future post your complete worksheet; that's more informative than merely showing the error message.