Hey there.

I've been using the threads package to parallelize some code. It's going well for the most part - my code runs way faster and I can observe with my System Monitor (ubuntu) that multiple cores are indeed being used. However, ~ 4 of every 5 times I try to run the exact same code, Maple will get stuck on a threaded calculation. If I follow the CPU usage in these instances, I see that one of the CPUs is maxed out at 100%. I am forced to quit Maple and kill the kernel process. Has anyone seen something like this before?

Thanks in advance.

Is there an option or setting to tell Maple not to return trivial solution as a solution to a PDE? Even though trivial solution is correct, it is not something I wanted, and it is making it hard for me to check if the solution is trivial or not. 

Here is an example:

pde:=I*diff(f(x,t),t)=-diff(f(x,t),x$2)+2*x^2*f(x,t):
bc:=f(-infinity ,t)=0,f(infinity,t)=0:
pdsolve([pde,bc],f(x,t))

Mathematica returns this

If there is no such option in Maple, what would be a good way to check for trivial solution using Maple code?

Just checking if rhs(sol)=0 does not work all the time, as some actual solutions are returned with 0 in rhs, like this example

pde := diff(u(x, y), x) + u(x,y)*diff(u(x, y),y) =0:
sol:=pdsolve(pde,u(x,y)):
sol:=DEtools:-remove_RootOf(sol)

So I need either find a way to tell Maple not to return trivial solution, or good robust way to check if solution returned is the trivial solution so I can reject it.

Any suggestion from the Maple experts how to handle this? I am now just interested in result from pdsolve, not dsolve.

The input is the PDE itself, read from a file. So this has to be done without visual inspection on the screen as the program reads the PDE from a file and process it. So the dependent variable and the independent variables are all included in the PDE itself. To make it more clear, I need a function such as

is_solution_trivial :=proc(pde,sol)
     #decide if sol is trivial solution or not.
     #one possibility is to find from the PDE the dependent variable
     #and the independent variables as in u(x,y,t,....) and then check
     #if sol  has the form u(x,y,t,....) =0 ?
end proc;

The above I can use until I figure how to tell Maple NOT to return trivial solution in first place!

Maple 2019.1

Hello,

I'm confused about Maple's adjoint function (in the DEtools package). When I take the adjoint of the derivative operator:

I get back simply "Dx". However, doing the calculation by hand and integrating by parts seems to indicate that this should return the negative of Dx. The inner product I'm using is . Is Maple perhaps using a different inner product? Or is this a generalization that I'm unaware of? Or is it perhaps just a bug?

Thanks!

I installed Physics package 368 and when I run a test, I found that now the latex() command fails with internal  error which I have never seen before. I think this is first time I see latex() gives an error.

Download bug_june_6_2019.mw

Is this a new bug? Why latex() command now fails? It failed on the above output. When I try latex() on simpler output. no error is generated. So something to do with the above specific output seems to be the issue.

Maple 2019.1 using Physics 368 on windows 10.

This is a new error I have not seen before.  

Trying to verify my solution for the diffusion pde in cylinderical coordinates wth no angle theta dependency.

unassign('z,t,r,u');
lap:=diff(u(r,z,t),r$2)+ 1/r*diff(u(r,z,t),r)+diff(u(r,z,t),z$2);
bc:=u(r,0,t)=0,u(r,1,t)=0, u(1,z,t)=0;
ic:=u(r,z,0) = f(r,z);
pdsolve([diff(u(r,z,t),t) = lap,bc,ic],u(r,z,t)) assuming t>0

The error is

Error, (in assuming) when calling 'BesselJZeros'. Received: '0th zero of BesselJ(0,x) not defined'

Is this a bug or Am I doing something wrong? 

update

fyi, it also fails with same error when trying boundedseries HINT

restart;
unassign('z,t,r,u');
lap:=VectorCalculus:-Laplacian(u(r, z, t), cylindrical[r, theta,z]);
bc:=u(r,0,t)=0,u(r,1,t)=0, u(1,z,t)=0;
ic:=u(r,z,0) = f(r,z);
pdsolve([diff(u(r,z,t),t) = lap,bc,ic],u(r,z,t),HINT=boundedseries(r=0))

I am using Maple 2019.1 with Physics 366 on windows 10

Maple 2019.1 with Physics version 362  gives this strange error on this pde

restart;
pde := x*diff(u(x, y), x) + y*diff(u(x, y), y) = -4*x*y*u(x, y);
ic := u(x, 0) = exp(-x);
sol:=pdsolve([pde,ic],u(x,y));

Error is

Error, (in PDEtools:-casesplit) equation of unknown type integer : 1

Is this a bug? It shows only when using exp(-x). Changing it to exp(-x^2) or exp(x) do not show the error, even though Maple can't solve it.

On windows 10.

I was trying to verify some solution to pde in textbook using Maple. The book gives the Cauchy data for this first order PDE in the form that Maple does not like when I used it as input. Here is an example

When I typed

pde:=u(x,y)*(x+y)*diff(u(x,y),x)+u(x,y)*(x-y)*diff(u(x,y),y)=x^2+y^2;
ic:=u(x,2*x)=0;
pdsolve([pde,ic],u(x,y))

Maple complained

Error, (in PDEtools:-Library:-NormalizeBoundaryConditions) unexpected 
occurrence of the variables {x} in the 2nd operand of u(x, 2*x) in the given initial conditions

In Mathematica it accepts such form of Cauchy data:

pde=u[x,y]*(x+y)*D[u[x,y],x]+u[x,y]*(x-y)*D[u[x,y],y]==x^2+y^2;
ic=u[x,2*x]==0;
DSolve[{pde,ic},u[x,y],{x,y}]

(I have not verified the above answer is correct or not).

Am I doing something wrong in Maple?

Or is there a trick or option or method to allow Maple to accepts such initial conditions? The book I am looking at has many problems where Cauch data is given on such form (i.e. u=0 on specific curve or in 3D on some specific surface). Here is another example

Which I'd like write its initial conditions as u(x,1/x)=0 but can not.

I could ofcourse solve the pde without these initial conditions, and then post process the answer to find the constants of integration from the Cauchy data given. But it will be nice if Maple would accept the IC as is.

Is it considered a bug when pdetest does not give zero for a solution given by pdsolve? 

restart;
pde := x*diff(w(x,y,z),x)+  a*z*diff(w(x,y,z),y)+b*y*diff(w(x,y,z),z)=c:
sol:=pdsolve(pde,w(x,y,z));
pdetest(sol,pde)

Gives

which is not zero.

This is the first time I've seen this happen. 

Maple 2019.1 using Physics version 362

I need to use gamma as a "free" symbol in pde that I pass to pdsolve, so that the latex comes out as \gamma OK in the solution.

in other words, the pde itself uses the symbol gamma (as it is written in the textbook and I want to keep it the same). This gamma is not the known constant gamma. Something similar to using alpha and beta or x and y. 

But gamma in a known constant in Maple and I am worried this will affect some computation inside pdsolve if I use gamma  as known number in the PDE (even though I think it should not change the result of pdsolve as there are no other numbers in the PDE input, I just wanted to be safe).

I am not able to clear gamma

unassign(gamma)  gives error since it is protected.

Is  there a way around this? Should I use wrap the name with 'gamma'  or `gamma` for example? 

Here is an example

pde := a*diff(w(x,y,z),x)+ b*diff(w(x,y,z),y)+c*diff(w(x,y,z),z)= alpha*x+beta*y+gamma*z+delta;

It is the gamma above I am worried about using in the input. What is the correct way to do this?  

I have thought that   D(y)(0)=C1  and  eval(diff(y(t),t),t=0)=C1  mean exactly the same thing which is derivative of y wr.t. "t" evaluated at specific point t=0 is C1.

If you agree they are exactly the same thing, then why dsolve works with both forms used for initial conditions if the option 'series' is not used.

When using the 'series' option, dsolve stops working when using  eval(diff(y(t),t),t=0) form? All else is the same.

ode:=diff(y(t),t$2)+3*diff(y(t),t)+2*y(t)=0;
bc_form_1:=y(0)=C1,eval(diff(y(t),t),t=0)=C2;
bc_form_2:=y(0)=C1,D(y)(0)=C2;
sol1:=dsolve([ode,bc_form_1],y(t));
sol2:=dsolve([ode,bc_form_2],y(t))

Both the above work

But now when I use the 'series' option, the first form stops working!

ode:=diff(y(t),t$2)+3*diff(y(t),t)+2*y(t)=0;
bc_form_1:=y(0)=C1,eval(diff(y(t),t),t=0)=C2;
bc_form_2:=y(0)=C1,D(y)(0)=C2;
sol1:=dsolve([ode,bc_form_1],y(t),'series');
sol2:=dsolve([ode,bc_form_2],y(t),'series')

Is this a bug? 

Just updated to Maple 2019.1  on windows 10.

I have reinstalled Maple 2019 several times, including its latest update. But when trying to graph the following:

plot(sin(x), x = -2*Pi .. 2*Pi)

But I get this:

Error, (in plot) expected a range but received x = -2*Pi .. 2*Pi

And if I enter:

sin(x)

The result is:

2.73949338633639*10^-116 + 2.73949338633639*10^-116*I

When trying this:

plot3d(x*exp(-x^2 - y^2), x = -2 .. 2, y = -2 .. 2, color = x)

I get this:

And if I try it with Graph Theory:

with(GraphTheory);
G := Graph({{a, b}, {a, c}, {b, c}});
G := Graph 1: an undirected unweighted graph with 3 vertices and 3 edge(s)

DrawGraph(G)

Error, (in GraphTheory:-DrawGraph) invalid input: modp received I, which is not valid for its 2nd argument, m
 

I do not know what is the reason for this anomalous behavior of Maple 2019, it will be some software bug or it will be an error caused by my computer...
I would like to know if this problem happens to other people or just to me. Any help or guidance on this problem will be greatly appreciated.

Best regards

In Maple 2019 it is not possible to change to "1-D Math Input".

But it is possible to convert (right mouse->convert to-> 1D Math Input)

In this mode I get the following results:

If I do:

The font that Maple uses for the Tablulate is much larger than the font used to display the Dataframe. How does one choose the font size that Tabluate() uses? 

Peter

As always, thank you all in advanced.

I found this challenge by chance.

solve 615+x^2=2^y over integers.

I rushed to Maple and tried to solve it  with “solve” and "assuming" but I did not get results.

solve(615+x^2=2^y) assuming x::integer,y::integer   did not work.

How could this equation be suitably formulated for Maple to solve it?
 

Good day,

I was recently using Maple 2019 for work on a project, and ran into an error. This error (which will be copied and pasted below for others to test) occurs when making assumptions across multiple lines (whether using the additionally function or not) while using IntegrationTools[Change]. It seems that, if during the process a variable that was within both the assumptions is subtracted from itself, the subtraction fails to happen and leaves what effectively equals 0 in the workings, making further workings impossible.

I'm wondering if anyone else is able to reproduce this error? I know the fix for it is to not disjoint the assumptions, but I am curious if others can easily reproduce it or if others have experiences with it!

As promised, below you will find my workings in order to reproduce this error!

Base Error:

restart;
assume(a>0,b>0,b>a,c>0,t>0);
interface(showassumed=0);
F := Int(sqrt(d-a*c^2*t),d=0...infinity);
assume(b>a);
IntegrationTools[Change](F,-a*t*c^2+d=-y,y)

Simple Fix:

restart;
assume(a>0,b>0,b>a,c>0,t>0);
interface(showassumed=0);
F := Int(sqrt(d-a*c^2*t),d=0...infinity);
IntegrationTools[Change](F,-a*t*c^2+d=-y,y)

Error Without Interface Change:

restart;
assume(a>0,b>a,c>0,t>0);
F := Int(sqrt(d-a*c^2*t),d=0...infinity);
assume(b>a);
IntegrationTools[Change](F,-a*t*c^2+d=-y,y)

Error When Using Additionally:

restart;
assume(a>0,b>a,c>0,t>0);
interface(showassumed=0);
F := Int(sqrt(d-a*c^2*t),d=0...infinity);
additionally(b>a);
IntegrationTools[Change](F,-a*t*c^2+d=-y,y)