2340 Reputation

4 years, 302 days

[ ] and assumptions...

Try removing the square bracket in D1. Square brackets are used in Maple to create a list.

For inequalties you might need assumptions as well depending on the expression.

Methods...

I have tried to verify G1 with odetest which worked for + but not for -

y(x) = -sqrt(-epsilon)*tanh((x+lambda)*sqrt(-epsilon)):
odetest(%,ode);

/         /                         (1/2)\\
2 epsilon \-1 + cosh\2 (x + lambda) (-epsilon)     //
- -----------------------------------------------------
/                         (1/2)\
1 + cosh\2 (x + lambda) (-epsilon)     /

So maybe the list is incorrect in some details.

Here are other solutions (without lambda) that can be obtained straight out of the library using the option method.  Anything else, I am afraid, requires advanced skills and/or manipulation by hand. Were you looking for something like that?

 > restart;kernelopts(version); with(DEtools): ode := diff(y(x), x) = epsilon - y(x)^2;                                    sol := dsolve(ode);                        P := particularsol(ode);
 (1)
 > indices(`dsolve/methods`)
 (2)

 > [entries(`dsolve/methods`[1])]; seq([%[i],dsolve(ode,%[i])],i=1..nops(%));
 (3)
 > [entries(`dsolve/methods`[1,high_degree])]; seq([%[i],dsolve(ode,%[i])],i=1..nops(%));
 (4)
 > [entries(`dsolve/methods`[1,semiclass])]; seq([%[i],dsolve(ode,%[i])],i=1..nops(%));
 (5)
 > [entries(`dsolve/methods`[1,extra])]; seq([%[i],dsolve(ode,%[i])],i=1..nops(%));
 (6)

Comma...

I cannot run your worksheet because

with(Syrup);
Error, invalid input: with expects its 1st argument, pname, to be of type {`module`, package}, but received Syrup

However, what I see in your assumptions is too restrictive. Instead of "and" try comma

assumptions := 0 < `&omega;0p`, 0 < `&omega;0s`, 0 < Lp, 0 < Ls, 0 < k, 0 < Rp, 0 < Rs, 0 < omega, 0 < L, 0 < Idc, 0 < Vbat

Two more variants...

Maple tries to evaluate your integral symbolically. You can force it to integrate numerically by

evalf(Int(Int(F[1](x,y),x=0..1.),y=0..1.));

or

int(int(F[1](x,y),x=0..1.,numeric=true),y=0..1.);

See ?evalf,Int

dharrs version seems to switch automatically to numerical integration.

length...

In your worksheet you compute coeff from expression (5) which is the length of the expression.

If you remove the length statement, you can compute some coefficients from the third operand of the product

mover...

Using Typesetting you can textplot items above each other. Here gamma2 is printed over an invisible character which provides the space to the point.

display(point(Pgamma2,symbol=solidcircle,symbolsize=14),textplot([Pgamma2[],Typesetting:-mover(Typesetting:-mo("&InvisibleTimes;"),Typesetting:-mo("&gamma;2")),align={above}]))

solve...

It is solve that cannot deal with the two solutions in the same way.

In the "good" case solve returns a warning

solve(ln(x)-c__1-(1/2)*ln((y(x)^2-6*x)/x)-3*ln((3^(1/2)*y(x)+((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2))/x^(1/2))+(1/12)*3^(1/2)*6^(1/2)*2^(1/2)*arctanh((1/2)*(-16*x^(1/2)+3*y(x)*6^(1/2))*2^(1/2)/(((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2)))+(1/12)*3^(1/2)*arctanh((1/2)*(16*x^(1/2)+3*y(x)*6^(1/2))*2^(1/2)/(((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2)))*6^(1/2)*2^(1/2), y(x));
Warning, solutions may have been lost

and stops searching for "further" solutions. In the "bad" case solve tries hard to find an explicit solution (which I  doubt exists). This way odestest can never apply methods for implicit solutions.

solve(ln(x)-c__1-(1/2)*ln((y(x)^2-6*x)/x)-3*ln((3^(1/2)*y(x)+((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2))/x^(1/2))+(1/2)*arctanh((1/2)*(-16*x^(1/2)+3*y(x)*2^(1/2)*3^(1/2))*2^(1/2)/(((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2)))+(1/2)*arctanh((1/2)*(16*x^(1/2)+3*y(x)*2^(1/2)*3^(1/2))*2^(1/2)/(((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2))), y(x)); #hangs

 > interface(version);
 (1)
 > Physics:-Version();
 (2)
 > restart;
 > ode:=4*x*diff(y(x),x)^2-3*y(x)*diff(y(x),x)+3 = 0;
 (3)
 > bad_sol:=ln(x) - c__1 - 1/2*ln((y(x)^2 - 6*x)/x) - 3*ln((sqrt(3)*y(x) + sqrt((3*y(x)^2 - 16*x)/x)*sqrt(x))/sqrt(x)) + 1/2*arctanh(1/2*(-16*sqrt(x) + 3*y(x)*sqrt(2)*sqrt(3))*sqrt(2)/(sqrt((3*y(x)^2 - 16*x)/x)*sqrt(x))) + 1/2*arctanh(1/2*(16*sqrt(x) + 3*y(x)*sqrt(2)*sqrt(3))*sqrt(2)/(sqrt((3*y(x)^2 - 16*x)/x)*sqrt(x))) = 0;
 (4)
 > good_sol:=ln(x) - c__1 - 1/2*ln((y(x)^2 - 6*x)/x) - 3*ln((sqrt(3)*y(x) + sqrt(x)*sqrt((3*y(x)^2 - 16*x)/x))/sqrt(x)) + 1/12*sqrt(3)*sqrt(6)*sqrt(2)*arctanh(1/2*(-16*sqrt(x) + 3*y(x)*sqrt(6))*sqrt(2)/(sqrt(x)*sqrt((3*y(x)^2 - 16*x)/x))) + 1/12*sqrt(3)*arctanh(1/2*(16*sqrt(x) + 3*y(x)*sqrt(6))*sqrt(2)/(sqrt(x)*sqrt((3*y(x)^2 - 16*x)/x)))*sqrt(6)*sqrt(2) = 0;
 (5)
 (6)
 > trace(solve);
 (7)
 {--> enter solve, args = ln(x)-c__1-(1/2)*ln((y(x)^2-6*x)/x)-3*ln((3^(1/2)*y(x)+((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2))/x^(1/2))+(1/12)*3^(1/2)*6^(1/2)*2^(1/2)*arctanh((1/2)*(-16*x^(1/2)+3*y(x)*6^(1/2))*2^(1/2)/(((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2)))+(1/12)*3^(1/2)*arctanh((1/2)*(16*x^(1/2)+3*y(x)*6^(1/2))*2^(1/2)/(((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2)))*6^(1/2)*2^(1/2), y(x)
 <-- exit solve (now in \`ODEtools/Solve/EnvDropMultiplicity\`) = }
 (8)
 {--> enter solve, args = ln(x)-c__1-(1/2)*ln((y(x)^2-6*x)/x)-3*ln((3^(1/2)*y(x)+((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2))/x^(1/2))+(1/2)*arctanh((1/2)*(-16*x^(1/2)+3*y(x)*2^(1/2)*3^(1/2))*2^(1/2)/(((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2)))+(1/2)*arctanh((1/2)*(16*x^(1/2)+3*y(x)*2^(1/2)*3^(1/2))*2^(1/2)/(((3*y(x)^2-16*x)/x)^(1/2)*x^(1/2))), y(x)
 (9)
 >
 >

2 errors...

In your code you need to add colons (yellow) to assign y1(x) and y2(x) to names. You also had a space too much (red)

Alternativley, if you do not want to assign to names, you can use subs

y1(x) = 2*sin(x) - sin(2*x) + cos(2*x);
y2(x) = 4*sin(x) + sin(2*x) - cos(2*x);
1/2*(diff(y1(x), x)^2 + diff(y2(x), x)^2) + 1/2*(3*y1(x)^2 - y1(x)*y2(x) + y2(x)^2);
simplify(subs(%%%, %%, %));

Yes...

I just did it with a Maple 2024.0 installer file that I still had in my download folder. You have to download a full installation (not an upgrade) from here and intal Maple in a separate folder.

Now I have 2024.0 and 2024.1 in my start menu on Windows and both are running.

classify <> suggest...

Concerning methods:

odeadvisor (according to ?DEtools,odeadvisor) tries to classify an ODE and to suggest solution methods.

This could be interpreted in the way that each classification (i.e. a displayed type) has a corresponding method named similarly. This is, IMO, not the case, for several reasons:

• Entering a classification (as outputted from odeadvisor) as method for dsolve often leads to the error message that this method is not implemented. With some edits dsolve might accept the input, which does not mean that the method is appropriate.
• Some types copied literally from odeadvisor as method for dsolve produce solutions that do not pass odetest.
• odeadvisor output does not suggest directly: Starting from odeadvisor output to ?odeadvisor to ?odeadvisor,<TYPE> leads to the help page of a type where Maple suggests how to solve this type. Rarely (if at all) a method is used explicitly on these help pages in a call for dsolve. Sometimes more than on way to solve a particular ode is described.

Concerning the ode:
I cannot match Maples definition

dAlembert_ode := y(x)=x*f(diff(y(x),x))+g(diff(y(x),x));

with the ode.

The solution y(x) = x - 1 is also obtained by

dsolve(ode,[dAlembert]);

which tells me that the IC is not used with that method (I remember a similar case we discussed before).

Where is the information comming from that this ode is also of type dAlembert? I see "Abel 2nd type class A" listed for which I find it difficult to identify the appropriate method under dsolve\method.

No match...

I was expecting a more knowledgeable user than me to reply.

Anyway, I assume that the classification is wrong based on the following.

The method homogeneous is not appropriate for second order ode's because it solves first oder ode's under which it is also listed.

`dsolve/methods`[1];

homogeneous, Chini, lin_sym, exact, Abel, pot_sym]

Contrarily

dsolve(ode,[dAlembert])

solves the ode.

(Edit: there seems to be no homogenous,Class A method

`dsolve/methods`[1,high_degree];
dsolve(ode,y(x),%);
dsolve(ode,y(x),%%[-2..-1]);

Only two mehtods provide solutions)

Further, I do not see a match between

and

where I cannot convert the right hand side to an expression that exclusively depends on y(x)/x.

(Edit: It can be converted. See above reply to Carl.)

Also, the term homegeneous as introduced in the vocabulary in Advanced Engineering Mathematics with Maple

"A linear equation is homogeneous if, when the unknown function and all its derivatives are placed on the left side of the equation, the right side is then zero.  A linear equation is nonhomogeneous (inhomogeneous) otherwise.  Thus, the terms homogeneous and nonhomogeneous rightly apply to linear equations."

does not match the ode. Neither the right hand side is zero nor the left hand side represents a linear ode.

By the way, since there is no 1:1 correspondance between ode types and methods I used to look-up the methods

indices(`dsolve/methods`);
entries(`dsolve/methods`)

incompelte snippet...

The code snippet is incomplete. I have higlighted in orange what I have added to understand what is going on.

I have stopped at the point where I found the name i not beeing assinged to a value.

 > with(geometry); Sq := proc(n::integer) local aS, oS, aC, oC, s, dr, pc, u; aS := -i/n; print(aS); oS := sum(1/s, s = 1 .. n); aC := 1/2*aS; oC := oS - 1/2*1/((n + 1)*n); point(S, aS, oS); point(C, aC, oC); print(S); MakeSquare(K, [S, 'center' = C]); u := (x, i) -> sum(exp(-x*k)/k, k = 1 .. i); pc := plot(u(x, n), x = 0 .. 4, color = green); print([K]); dr := draw([K]); plots:-display({dr, pc}); end ;Sq(1);

Risch...

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;
 (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);
 (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
 (3)

indets?...

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]));

 1 2 3 4 5 6 7 Last Page 1 of 13
﻿