I am trying to see if I can get speed up by using dsolve inside thread.

I made very simple example of global list of two differential equations to start with.

Next, created two threads where each picks one ode from the global list to process. So they should in theory run in parallel. The list of ode's is a global list in the worksheet for now.

But I keep getting error when calling dsolve 

               Error, (in dsolve) type `System` does not exist

I tried also passing the actual ode to the thread, still, same error.

Next, I did not pass anything, but called dsolve directly from inside thread proc on same ode. The ode is local variable inside the proc. I still get same error.

                        Does this mean dsolve is not supported by threads? 

But when I searched this subject, AI says it works in threads:

Everything works OK when I run dsolve in worksheet outside thread (i.e. normally).

I will show below worksheet showing these cases. I must not be doing something right. But what? Can one not pass data from global worksheet to the thread this way? Or does one needs to load something in each thread to make this work?

Download error_dsolve_using_threads_dec_26_2024.mw

This is an ode from textbook. dsolve gives new error I have not seen before. 

Maple 2024.2 on windows 10.

Download dsolve_factor_dec_24_2024.mw

tracelast;  gives long output with this at end

#(IntegrationTools:-Indefinite:-Polynomial,14): return poly/primitivepart*thisproc(primitivepart,var)
 IntegrationTools:-Indefinite:-Polynomial called with arguments: (8*I)*x*KummerM(3/4+((1/8)*I)*2^(1/2), 3/2, I*2^(1/2)*x^2)*x1*2^(1/2)-(3*I)*2^(1/2)*KummerM(3/4+((1/8)*I)*2^(1/2), 3/2, I*2^(1/2)*x^2)*y+(7*I)*2^(1/2)*KummerM(((1/8)*I)*2^(1/2)+7/4, 3/2, I*2^(1/2)*x^2)*y+12*x^2*KummerM(3/4+((1/8)*I)*2^(1/2), 3/2, I*2^(1/2)*x^2)*y+8*x*KummerM(3/4+((1/8)*I)*2^(1/2), 3/2, I*2^(1/2)*x^2)*x1+4*KummerM(((1/8)*I)*2^(1/2)+7/4, 3/2, I*2^(1/2)*x^2)*y, x1, nofactor = false
 #(IntegrationTools:-Indefinite:-Polynomial,8): newpoly := factor(poly)
Error, (in factor) too many levels of recursion
 locals defined as: p = p, primitivepart = primitivepart, base = base, exponent = exponent, subpolys = subpolys, change = change, newpoly = newpoly, u = u

Also, this error can not be cought using try/catch. 

Maple's Student:-ODEs:-ODESteps solves an ode by doing change of variable on the independent variable, but the resulting ode is wrong and final answer is wrong.

Here is one such example

restart;
ode:=diff(diff(y(x),x),x)*sin(x)^2 = 2*y(x);
Student:-ODEs:-ODESteps(ode):

But this result is wrong. First of all, we can not have both x and t  in the same ode. This is what dchange gives

ode:=diff(y(x),x$2)*sin(x)^2-2*y(x)=0;
tr:={PDEtools:-Solve(t=ln(x),x)};
simplify(PDEtools:-dchange(tr,ode,[t]))

It looks like Student:-ODEs:-ODESteps is trying to solve  sin(x)^2*y'' + 2 y=0 as EULER type ode.

But Euler type ode will look like  x^2*y'' +2 y=0  

It seems to have confused sin(x)^2 with x^2. This change of variable it used only works for EULER type ode with polynomial coefficient, not trig coefficients.

Maple 2024.2 on Windows 10

These two issues probably came up before, but I can't find where and when searching Maple primes.

So I thought to summarize the issues I see with odetest in one post, in the hope to get clarification on current status on these from the powers who know.

The first issue

The order in which odetest returns the answer. When odetest is called to check the ode and IC, as in 

the_status := odetest(sol,[ode,IC])

One would expect the_status to be a list, where the first entry tells if sol verifies the ode, and the second entry tells if sol verifies IC.

i.e. the order is the same as in the input. right? Since ode is first and IC is second in the input list.

But Maple sometimes mixes the order. See example 1 below. This makes it impossible to determine if the solution verifies the ode or IC,  when one of the entries in the_status is zero and the other is not, since order can be reversed sometimes.

Second issue:

When the solution is implicit, Maple gives invalid odetest result on the IC, unless one rewrites the solution using (lhs-rhs)(sol)=0.

i.e. move everything to the left side of the equation with RHS zero. This happens sometimes and when the solution is implicit.

I have thought this was fixed in current Maple, but it is not.  I remember this came up before, but can't find when and where.

Example 2 below shows an example.

Will these two issues hopefully be fixed in Maple 2025? Sometimes one forgets to rewrite the solution using (lhs-rhs)(sol)=0 and this results in false negative. 

Please see worksheet below. ps. I hope forum manager does not delete this question.

Download issues_with_odetest_dec_16_2024.mw

What is the correct syntax to do this change of variable from the text book:

The problem is that using PDEtools:-dchange, it wants the transformation to have form { old = new}, i.e. x=...  so I can not write  z=g(x) in the transformation. 

For example

ode:= diff(y(x),x$2)+diff(y(x),x)+y(x)=sin(x);
PDEtools:-dchange({z= g(x)},ode,known={x},unknown={z});

Error, (in dchange/info) missing a list with the new variables
And if I first solve for x so that I can write the transformation with x on left side, it still does not work

ode:= diff(y(x),x$2)+diff(y(x),x)+y(x)=sin(x);
PDEtools:-dchange({x=RootOf(g(_Z) - z)},ode,known={x},unknown={z});

Where RootOf(g(_Z) - z) was result of solve(z=g(x),x);

I am sure this can be done in Maple, I just do not know the right syntax to use with dchange.

Maple 2024.2