C_R

2230 Reputation

19 Badges

4 years, 277 days

MaplePrimes Activity


These are answers submitted by C_R

Maple behaves deterministically until it applies the ParallelRisch method. I encountered a Maple crash while investigating this using the attached file. After further attempts on older files using printlevel commands, I experienced a severe system crash that necessitated two reboots to get my system, including mouse control, (believe it or not) back working.

Regarding your question "what is going on," I can offer a potential explanation:

Maple consistently enters ParallelRisch but appears to have challenges handling the integrand. Assuming "parallel" means Maple creates subtasks processed through multithreading (potentially on separate cores), variations in completion timings between subtasks could be a possibility. This might explain the observed behavior where timelimit stops processing in two instances, while the maple server completely freezes in another. I could test this hypothesis running Maple on a single core, which so far only produced the PDEtools/NumerDenom error and only one time a total freeze (this is not conclusive enough).

Other factors on CPU time variations might include additional tasks occasionally performed by mserver.exe alongside the integration process.

Since timelimit is a built-in routine, further investigation into it are not possible from my side.

I don't know whether it makes sense to invest more time in the combination of this special integrant and ParallelRisch. My understanding of ParallelRisch is that is does not more than Risch does. If so, ParalleRisch should have returned the input unevaluated as Risch does.

Can the below be reproduced? And OS different form Windows would be of interest. In any case, better to save your work before trying...

infolevel[int]:=5;

5

(1)

expr:=-4*(1-exp(I*x))^(-4*x)*(exp(I*x)+1)^(4*x)*exp(4*I*(polylog(2,exp(I*x)))-polylog(2,-exp(I*x) ))*csc(x)*x*(tan(x)^2-1);

-4*(1-exp(I*x))^(-4*x)*(exp(I*x)+1)^(4*x)*exp((4*I)*polylog(2, exp(I*x))-polylog(2, -exp(I*x)))*csc(x)*x*(tan(x)^2-1)

(2)

int(expr,x,method=ParallelRisch);
(* This command makes mserver "unresponsive" after a while: interrupt from the GUI does not work, Time in the status bar is not updated, private bytes = system alloacted memory jump 64 Gb, physical memory (visible in Windows task manager) still piling up*)

int: Beginning integration with _EnvContinuous=_EnvContinuous, _EnvAllSolutions=_EnvAllSolutions, and _EnvCauchyPrincipalValue=_EnvCauchyPrincipalValue.

 

Degree to be used when constructing the parallel integration system = 11

 

(* this input froze Maple GUI*, output was backed up before excecution of input
- might required sereval attempts to reproduce, which was possible*)
printlevel:=10;
st:=time[real]():
timelimit(60,int(expr,x,method=ParallelRisch));
print("time taken ",time[real]()-st);

int: Beginning integration with _EnvContinuous=_EnvContinuous, _EnvAllSolutions=_EnvAllSolutions, and _EnvCauchyPrincipalValue=_EnvCauchyPrincipalValue.

 

Degree to be used when constructing the parallel integration system = 11

 

Error, (in PDEtools/NumerDenom) time expired

 

"time taken ", 82.701

(3)

NULL

Download untitled2150_MAS.bak.mw

Its not fully clear what the unknows are that you want dsolve to solve for.

nops(sys)
                               12

tells us that you have 12 equations.

indets(sys);
 /                                      (1/2)   d           
{ exp, omicron, t, theta, (42.3 - theta)     , --- i[h](t), 
 \                                              dt          

   d            d            d            d           
  --- i[v](t), --- j[v](t), --- r[h](t), --- s[h](t), 
   dt           dt           dt           dt          

   d           
  --- s[v](t), 
   dt          

     /                                                  2\  
  exp\0.02366863905 (-0.0464 omicron + 1.046 theta - 23) /, 

     /                                                     4\  
  exp\0.00002055229087 (0.01 omicron + 1.01 theta - 21.211) /, 

  exp(0.0054 theta + 0.6737), i[h](t), i[v](t), j[v](t), r[h](t), 

                  \ 
  s[h](t), s[v](t) }
                  / 


lists additional to 12 unknown functions of t the parameters omicron and theta. These are not functions of t as you have defined them in the first two input lines. As such sys cannot be solved numerically.

Also: The frist two input lines do not use the assignement operator to define theta and omicron.

This works as well

map(X->(odetest(X,ode) assuming x>0),[sol])

The parenthesis group terms. In that way the solutions are mapped onto an expression that inculdes the assumption.

Afterwards odetest is excecuted with the assumptions.

Without parentheses the parser does not spot the second argument.

This one works as well

eval(map(X->'odetest(X,ode) assuming x>0',[sol]));

The reason "why Maple gives this internal error" is that Maple applies the procedure SolveSeparable which provides a result that gives an error because it computes ln(0) for the IC y(0)=1.

Only for this IC the result does not work.

In a similar case the Student,ODEs package had an appropriate method on board but the case (method not appropriate for a particular IC) could be solved by fixing the false classification "exact" to "NONE".
For this case it seems that there is no Student,ODEs method.

dsolve solves this IVP differently with an implicit method.

infolevel[dsolve]:=5;
dsolve({ode,ic},implicit);
solve(%,{y(x)})[];
dsolve({ode,ic});

Since I don't see that an implicit method is implemented in ODESteps, I'm curious if it's really a bug or a current limitation of ODESteps.

You can extract the polygons (vertical bars) from the plot structure which decribe the xy data.
The polygons have four corners. You probably want not xy data from all corners.
In the below I have extracted the very left x coordinate of the polygons and added the most right corner of the histogram.

[op(op(1, Q))];
%[1 .. nops(%) - 1];
seq(%[i][1][1], i = 1 .. nops(%)), %[nops(%)][2][1];

You can do the same for y coordinates or pairs of x,y whatever you are interesed in.

This is a crude example how you could filter subexpressions still using indets

indets(eqn) minus indets(eqn,name):
subexpr:=map(op,%) minus indets(%,fraction):# remove of root terms - instead of filtering for `^`
rpl:=[A,B,C,`&D;`,E,F]:
Subs2:=[seq(subexpr[i]=rpl[i], i=1..nops(subexpr))]:
simplify(subs(Subs2,eqn));

This could be refined and put into a procedure.( I am not quite sure if you are looking for something like that.)

ODESteps does not apply an adequate method although it has one on board:
Student:-ODEs:-Solve:-FirstOrderLinear. Instead "homotopy method" is applied.

When tracing ODEstep I got the impression that ODEstep tries to follow dsolve closely and adds comments step by step. Programming this is probably non trivial because essential steps in the execution of a sophisticated command (that was initially not designed for the purpose of education) have to be identified and attributed to a mathematical correct instruction to a student.

Assuming no bug in the program flow, the answer to your question “Why ODEStep is unable” could be: FirstOrderLinear is not implemented yet. This is likely because it is not listed here under “Step-by-Step Computation”.
I guess we will see it implemented in the future.

 

Update:
The old link did not work because of a special character in the file name.
first_order_quadrature_ode_with_odesteps.mw

(now v1749 can compute the integral using two methods )

Maple distinguishes between many units because they either are in use or they have been. For some units the context is important. ?Units,annotations provides some examples. If you find them strange or exotic it’s probably because you use the SI system and do not have to deal with, for example, historic units.
Maple also provides energy conversions ?Units,EnergyConversions which seem to be useful in certain areas but are not known at all in others domains.

The units package has grown over the years and includes allot of options and functions users have requested but other users do not need. For this reason the package has become powerfull but not straighforward to use (at least it was for me).
Up to you to use Grays or not.

 

Personally, I use the default unit settings in combination with convert and simplify. The context panel is usefull too.
If you have any particular calculation or conversion problems consider uploading a file with


 

2*Unit('gray')

2*Units:-Unit(Gy)

(1)

Using the context panel and conversion to E0/em and erg

2*Units:-Unit(Gy)

2*Units:-Unit(Gy)

(2)

2*Units:-Unit(Gy)

2*Units:-Unit(Gy)

(3)

Now: Remove the context

convert(2*Units:-Unit(Gy), units, J/kg)

2*Units:-Unit(J/kg)

(4)

` `After that, the context pannel does not offer conversion to Gray anymore (but to other units)

2*Units:-Unit(J/kg)

2*Units:-Unit(J/kg)

(5)

NULL

Lets do a calculation

2*Units:-Unit(Gy)-2*Units:-Unit(J/kg)

2*Units:-Unit(Gy)-2*Units:-Unit(J/kg)

(6)

simplify(2*Units:-Unit(Gy)-2*Units:-Unit(J/kg))

0

(7)

NULL


 

Download Unit_conversion.mw

The problem with your algorithm is the break statement that terminates the inner loop without defining a condition for t[j+1].