@Rouben Rostamian  

"What is the domain of the unknown function u(r,z,t)?   It is
0 < r < 1,    0 < z < 1,   t > 0."

Yes. Actually the book uses 0<r<a and 0<z<H.  To help Maple, I used a numerical value for both radius and height of the cylinder. Both give the same Bessel error.

"Thus, the correct boundary conditions are:
bc := u(r,0,t)=0, u(r,1,t)=0, u(1,z,t)=0, D[1](u)(0,z,t)=0;"

I did not make up the BC. This is a problem from well known book. It is at page 335 from Richard Habeman Applied Partial differential equations, 4th edition.

I see nothing wrong with these boundary conditions. They say that the temperature is zero on the all the cylinder surfaces?

I solved this PDE by hand correctly using these boundary conditions. Because the problem says that it is independent of theta, so I used "u(r,z,t)" only and not "u(r,theta,z,t)" as normally would be the case for a cylinder.  Notice the book uses "a" and "H" which I replaced by "1" each to make it is easier for Maple. Not that changes anything.

"A boundary condition on the edge r=0 is missing"

It is not missing. It is always assumed that at r=0 (center of cylinder) the solution is finite. This is an implicit assumption in such problems. This leads to discarding one of the two Bessel eigenfunctions solutions (the second kind) that results from the radial Bessel ODE since that  blows at r=0 leaving one solution  (The Bessel J_0() of order zero)

@tomleslie 

"where f(r,z) is undefined is going to cause all sorts of weird problems - because it isn't really a meaningful inital condition: it provides no useful information"

Sorry, I am not following what you are saying.

It is not meaningful at all. Initial conditions are needed to obtain the final unknowns in the series solution. This is how half the problems in the books are specified. Need an initial condition!

But thanks for the trick to get the Lapacian without theta dependency. I will use that next time instead of manually type it.

@tomleslie 

The specification of PDE itself is valid inside the domain and when time is involved, for t>0.

The solution of the PDE should ofcourse satisfy the PDE itself and also the initial and boundary conditions.  But this is how the PDE itself is always given/specified in text books:

----------------------------------------

--------------------------------

------------------------

And many more. 

I was just trying to help Maple by giving assumptions (sometimes they help and sometimes they are not needed). In this case, If I use no assumptions, or use t>0 or t>=0, it does not matter, the error in Bessel is there.

I need to check now if this error is new or not. A PDE with Laplacian in Cylinderical or Polar coordinates will generate Bessel ODE for the radial part of the solution, so need to check if this affect other PDE's as well. 

@Thomas Richard 

The Lapacian is correct.  https://en.wikipedia.org/wiki/Del_in_cylindrical_and_spherical_coordinates 

For no theta dependency, the term in red above is dropped. Which gives what I wrote because when expanding the first term above gives

expand(1/r*diff(r*diff(f(r,z,t),r),r))

So you see it is the same as what I had (wikipedica uses "f" instead of "u").

I do not like to do as you did, as it can lead to errors. First of all, time "t" is never part of Laplacian, as Laplacian is spatial only, and I could make errors making substitutions afterwords to remove it, so I type the Lapacian by hand, when there is no theta dependency. Same for Laplacian in spherical. I could not figure how to use Maple for this. But I memorized these things by now so no problem.

@Carl Love 

It does not matter if  r<1 or r<a or no assumption at all on "r".

Initially I had the radius as variable "a", then changed it to "1" just to make it simpler, that is all.

The error shows up in all cases.

@Thomas Richard 

Thanks!  Using "u(x,y__0)" to the set the IC is a nice trick which I will try it next when Maple is having hard time with IC.

your hand simplifcation can not be correct. it is easy to see why. You say it has "beta*mu^3" term at the end but if you type "collect(expr,mu)" where "expr" is your expression, Maple gives

And it is clear that the term multiplying "mu^3" is not "beta" and it does not simplify to "beta" either as your hand simplification says. 

@Mariusz Iwaniuk 

"dsolve convert second order ODE to first order ODE(to Abel)."

I am not sure how dsolve will do that, since "y" is not missing in the original ODE. One can convert second order to first order if "y" is missing.

So letting v(t)=y'(t), then what will dsolve replace y(t) by in the ode? integal of v(t)? Then it becomes integral differential equation, not Abel.

Do you have an example of how dsolve does that to look at to help learn how this is done?

@Mariusz Iwaniuk 

"This is Abel diff equation"

But this is second order ODE. Abel differential equation is first order ODE?

@Carl Love 

 that only works when the size is 2. 

Yes ofcourse. I was just answering the question itself which uses 2. Sorry I did not know they wanted it to work for something else.

I will delete my answer now then.

ps.  I can't delete my answer. When I click More... it only shows EDIT. Pease moderator: delete my answer above.

Lets say this can somehow work (which it won't)

v^2:= a^2 + b^2

Then later on, you write v:=5;   Then next you write print(v^2) 

What should Maple print? 

@radaar 

my purpose is to speed up the computation.

if you are using hardware floating points, why do you think if the numbers all have first 10 decimal points not zero, and last 5 are zero, then the calculation will be faster than if all numbers had all 15 decimal points non zero? 

Are you saying the time to do a hardware calculation depends on how many zeros there are in the the  CPU register?

I am not following how less decimal places will make hardware calculations faster?

@Carl Love 

opps, yes, I read it as evalf. Need new glasses. That is why it will be best if OP provides an example, in that case I would have copied it and not made this mistake. But it should still work with evalhf? I mean the truncation part. Will correct

@acer 

Thanks. My question remains the same which you answered. I only added explaining WHY I needed this transformation and where I wanted to use it, that is all. I did not add a new question.

Will try your suggestion on the whole Laplacian now.

Thanks for help

@ecterrab 

V 350 worked for me also, no more error.

Thanks for all your work on this.