Hello,

I am attempting to check solutions to a system of ODEs using odetest. However, odetest only appears to partially substitute the provided solution. Furthermore, it appears to be related to the alphabetical order of the functions.

For instance, here I have two functions, phiL and phiM, that satisfy Laplace's equation and are coupled through the boundary conditions, BCs.

laplace := {-phiL(z) + diff(phiL(z),z$2)=0, -phiM(z) + diff(phiM(z),z$2)=0}:
BCs := {phiL(d1)=0,phiM(-d1)=0,phiL(0)=phiM(0), D(phiL)(0)-D(phiM)(0)=-n}:
sol := {
phiM(z) = n/2/coth(d1)*(cosh(z)+coth(d1)*sinh(z)),
phiL(z) = n/2/coth(d1)*(cosh(z)-coth(d1)*sinh(z))
}:

odetest(sol, laplace union BCs,{phiL(z),phiM(z)});

This returns

{0, 1/2*(2*phiL(0)*coth(d1)-n)/coth(d1), D(phiM)(0)-1/2*n}

Here, phiL(0) and phiM(0) are unevaluated even though the provided solutions are valid there.

Furthermore, while renaming phiL to an alphabetically earlier name (eg, phiJ) causes the corresponding change in the output. However, renaming it to something alphabetically after phiM (eg, phiN) causes the terms in the output to switch. That is, changing phiL to phiN in the above code results in

{0, 1/2*(2*phiM(0)*coth(d1)-n)/coth(d1), D(phiN)(0)+1/2*n}

Therefore, it seems to be related to the way Maple internally stores the list of variables.

Is this a bug? Or is there something I'm missing?

Thanks!

Hello,

     I'm trying to simplify an expression involving signum and sqrt using assumptions:

assumptions := { A>0,psi::real,1+A*cos(psi)<sqrt(1+sin(psi)),1+sin(psi)>0 }:
signum(1+A*cos(psi)-sqrt(1+sin(psi))):
simplify(%) assuming op(assumptions);

It seems to me that, given these assumptions, we can safely conclude that the result should be -1. However, I can't get Maple to show this. Interestingly, setting A=1 does allow maple to simplify the result to -1. Is there something I'm missing?

Thanks!

Hello,

      I've noticed a strange phenomenon involving simplify: given the exact same input, its output varies between two different results depending on memory usage patterns.

      I've attached a sample code. There, I have an equation which should simplify to 0=0. If I run the code with garbage collection gc uncommented, it will correctly give 0=0. However, with gc commented out, it gives the unsimplified result result ~80% of the time (with 0=0 the remaining 20%):

1/2*A1*k*epsilon*p*(-I*exp(I*psi__p)*(2-2*cos(2*psi__p))^(1/2)+exp(2*I*psi__p)-1)*exp(-I*psi__p-1/2*2^(1/2)*k^(1/2)*(-k*p*cos(psi__p)+(k^2*p^2+2*k*p*
cos(psi__p)+1)^(1/2)-1)^(1/2)*t)*(-exp(-I*k*x-1/2*I*2^(1/2)*k^(1/2)*(k*p*cos(psi__p)+(k^2*p^2+2*k*p*cos(psi__p)+1)^(1/2)+1)^(1/2)*t)+exp(I*k*x+1/2*I*
2^(1/2)*k^(1/2)*(k*p*cos(psi__p)+(k^2*p^2+2*k*p*cos(psi__p)+1)^(1/2)+1)^(1/2)*t)) = 0

For my particular machine, it seems that when the memory usage is <98.4MB, it gives 0=0, and the unsimplied case otherwise.

      Any idea why this is? It seems odd that simplify would return different results depending on garbage collection, especially since use of gc is now discouraged.

example.txt

A few notes:

• It seems replacing gc with a simple call to kernelopts(memusage) also produces the correct output
• This is a snippet of a larger body of code I wrote: there, even without gc, it will sporadically (with the exact same input) produce the correct answer ~50% of the time
• Only the last 4 lines are relevant; the beginning of the attached code is simply to generate appropriate memory usage and doesn't affect the relevant, final 4 lines

Hello,

      I've found that, occasionally, solve won't work if the solving variables are specified---but it will work if the variables aren't specified. For instance:

eqns:=
[x=1, -1/(exp(h)+1/exp(h))^(1/2)/(exp(h)-1/exp(h))^(1/2)*(exp(h)^2-2+1/exp(h)^2)^(1/2)*x = tanh(h)^(1/2)]:

# Works
solve(eqns);

# Doesn't work
solve(eqns, x);

I was wondering why this is, and if there is a workaround?

(I want to specify the solving variables so that solve doesn't attempt to solve for parameters---like h in this case. Also, I'm using solve as opposed to a consistency checker because, in general, I'm applying the same code to larger systems with additional variables to solve for).

Thanks!

Hello,

      I've been using frontend in conjuction with pdsolve to handle a very large system of PDEs; namely the system has many irrelevant functions that can be frozen with frontend, allowing pdsolve to solve it much quicker.

     However, I ran into a strange case, which I've included in the attached file. Namely, for this particular system of equations, the system is a PDE with respect to t, so I freeze functions of x. However, doing so produces incorrect results (labelled bad) compared to the unfrozen case (labelled good). The frontend command is working as expected (this can be verified by uncommenting the frontend/print commands); it seems that pdsolve is treating the frozen and unfrozen cases differently.

     Any idea why this behavior is occuring? (The obvious solution is to simply not use frontend here; again, I'm using this same code for much larger PDEs and frontend speeds up exceution by an order of magnitude).

Thanks!

MWE.txt