## 7374 Reputation

14 years, 77 days

## Alternative Christoffel, Ricci, Riemann...

I may not be understanding your question precisely - what do you mean by "ignoring the Christoffel symbols with coefficients of order Omega(r)^2". Given the metric , you cannot force the Christoffel symbols be something different than their definition

 >
 (1)

So assuming you meant to depart from  and create another tensor, say  with the same dimensions and components but where all the ones with degree > 1 in  are equal to 0, below you see one way of doing that. Using the definition of other tensors that are functions of  you can compute the equivalent ones based on .

 (2)

In the worksheet, you posted you forgot to set the coordinates, and from trial an error I can see you also changed the signature to be (+ - - -). I am adding that line here:

 (3)

This is the metric you indicated

 (4)

 (5)

These are the nonzero components

 (6)

You can tell the system to make equal to zero the components having degree > 1 in , and use that Array to define another tensor, . For that purpose, take a closer look at the structure (6): you want to operate on all algebraic expressions (note that equations `=` are not of type algebraic). Also, the degree command will get confused with  but not with  which is the same derivative but represented using D  notation. You switch from the diff  and D notations using convert . The command is subsindets . Puting all together,

 (7)

In the above you see, for instance, that the component (1,1,3) is now equal to 0. As said, you cannot define  to be something different than its definition, but you can  Define  another tensor with these components.

 (8)

Set a macro for  to avoid having to use the palette all the time

 >

Check it out

 >
 (9)
 >
 (10)

Of course, you can do the same with Ricci, Riemann, etc. to have versions of them where all the terms with degree > 2 in Omega(r) are discarded. The following is also not something you asked but illustrates well how to work with  and reusing definitions of other tensors; take for instance Ricci

 >
 (11)

You can now define an alternative , say based on :

 >
 (12)
 >
 (13)

Create a macro for R to skip the palette

 >
 >
 (14)

From Riemann[definition]

 >
 (15)

applying the same procedure you can get one defined in terms of , and using the approach to discard terms used for Christoffel you can discard terms in this one too.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

## Fixed in V.428...

This is fixed in V.428 or higher of the Physics Updates; you get

 >
 (1)
 >
 (2)
 >

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functuions, Maplesoft

## Fixed in v.427...

Hi

This is fixed in the Physics Updates version 427 or higher. In version 426, unfortunately a file of the version under development got loaded inadvertently, creating an out of sync issue. Thanks for posting the problem.

Best
Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

## Try PDEtools:-casesplit...

Below I intercalated comments italized, showing how to use casesplit to tackle the problem. Note also that through casesplit you can choose to use rifsimp, DifferentialAlgebra or DifferentialThomas as differential elimination engines. By default, for this problem it uses rifsimp (the non-integer powers are replaced by auxiliary functions satisfying differential equations).

 >
 (1)
 >

The command PDEtools:-casesplit handles no only non-integer powers but also known functions and arbitrary compositions of all of those. Now, your system involves 4 unknown functions

 >
 (2)

Your call to DEtools[rifsimp with  is equivalent to take A, B  and F as arbitrary functions. For arbitrary values of them, the only solution to your system is

 >
 >
 (3)

More interesting, you can split this problem into cases if you take all of A, B and F as solving variables ranked lower than Lambda1 (see discussion on rankings in the help page for PDEtools:-casesplit )

 >
 (4)

The caseplot option gives a pictorial view of the splitting into cases

 >
 (5)

From the pivot information you see the problem split into three cases depending on whether A or B are equal to 0, and when both are different from zero only the first case (equivalent to all of A, B and F being arbitrary). By the way, if this is the determining system of a PDE problem you may be interested in giving a look at the help page for PDEtools:-DEtermininingPDE  and all the related symmetry commands.

 >

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

• Be more specific regarding 3) and 4); itemize the three things you think are more important than anything else for each of them, be clear enough for people to understand, unambiguously, what you are talking about. Giving an example for each of your points always help.

Then, people may or not agree with you, as usual, that is natural, and Maplesoft may or may not have other plans, that is also natural, but people are listening, and chances are that your opinions (yours and others that may add material to your post) are taken into account, entirely or to some point.

Regarding the Heun functions, the original topic of this question, I agree with you nm when you say "given the small [amount of] resources ... I would prefer Maplesoft put its important resources on things that can impact many more users".

For example, this year is one with a heavy dedication to the integral transforms (the inttrans package) in connection with further developments on the exact solutions of PDE & Boundary Conditions, where these transforms are a key part of the strategies. The integral transforms numerical evaluation, differentiation rules, and several fixes and improvements (all that included some versions ago in the Physics Updates for Maple 2019 - and there is more coming) have the potential for significantly bumping up the utility of these valuable functions.

The Heun functions, by the way, are implemented - I wrote the Maple implementation many years ago, and I think it is a thorough implementation. True, their existing numerical evaluation routines can be improved at this point, and the Lame and spheroidal wave functions are not implemented. I know all that. Nobody forgot. What is happening is that other things pop up year after year that appear to me more relevant and of more impact than enhancinthe existing (and in my opinion already sophisticated) numerical evaluation routines of Heun functions, or implementing Lame. I realize others may not agree with me, and that is also natural.

And about that comment "... esoteric parts of the physics package", it looks to me highly subjective - despite the way the comment is written as if it were an indisputable truth. My opinion is that nothing currently found in the Physics package is esoteric. We all need to be respectful of others opinions. And that is all that I'll say in this thread about the original question.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

## PDEtools-dchange...

The command for applying a change of variables (transformation) to an algebraic expression (differential or not) is PDEtools:-dchange

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

## Not a bug; you re changing the conventio...

The convention explained in dsolve's help page is that the integration constants introduced by dsolve are of the form _Cn with n an integer. If you change that by something else, odetest has no way to know what is the integration constant that dsolve introduced. That information is relevant to test implicit solutions, as the one you show in your question. As explained in an answer to another of your questions, the technique is simple: solve for the integration constant introduced by dsolve (_C1, identified by odetest because of the _Cn convention) then differentiate with respect to the independent variable (in your example that is x) and you will get 0 modulo the ODE.

In summary: no bug here, and if you want the code to work as indicated in the help page, you cannot change its conventions. Alternatively, you change the conventions, and then test this result manually, not using odetest. The technique is simple, explained in the previous paragraph.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.

## It works fine in Maple 2019...

From the version of Physics you are using I assume you are using Maple 2018?

I'm unable to reproduce the problem in Maple 2019, this is what I get:

 >
 (1)
 >
 >
 (2)
 >
 (3)
 >
 (4)
 >
 (5)
 >
 (6)

Note that in Maple 2019 you can also indicate the indices to make clear what determinant are you computing:

 >
 (7)

And that is Maple 2019.

Regarding previous versions of Maple, unfortunately I cannot help you with that, but in case this information is of use for you, from reading the code in Maple 2018 I can see it is computing the determinant of :

 >
 (8)
 >
 (9)
 >
 (10)
 >
 (11)

That is, in Maple 2018 you are getting

Edgardo S. Cheb-Terrab
Physics, Differential Equations andMathematicalFunctions, Maplesoft

• When odeavisor returns a list of types (or classifications) of an ODE. This must mean the ODE can be of any one of these types?

Yes, when odeavisor "returns a list of types (or classifications) of an ODE" it means the ODE is of all of those types.

• When Maple is given an ODE to solve, and it can be of number of types, how does it select which type to use to solve the ODE?

See the help page ?dsolve,setup. That page is old, by now incomplete, for instance it does not mention the method of integrating factors for ODEs of differential order > 1, a method as powerful as the Lie symmetry method. See also ?dsolve,education and ?dsolve,algorithms.

• Is there any detailed document that explains more how odeadvisor determines the type of the ODE? This is a very powerful and a useful command but I can't find in help any hints on how it determines the type of ODE.

I wrote the odeavisor to be a sort of interactive e-book for ODEs: you pass an ODE and it not only determines the ODE types but also pops-up help pages explaining the solving methods available for those types. The point is that I wrote dsolve and the odeavisor at the same time, structuring the code so that the latter could take advantage of the subroutines of the former. The odeadvisor is thus a sort of "dsolve half of the way" plus the set of explanatory help pages on the corresponding solving methods for the ODE you passed, and its ability to pop-up these pages automatically. The implementation details are too many, and also this is not public software, even when at Maplesoft we are incredibly open regarding that - you can always read the code.

In general, about possibly more questions on the structure of Maple commands or the help pages mentioned above: I don't intend to make the help pages mentioned more complete/detailed. The competition copied some of our algorithms, for dsolve, pdsolve and also other stuff, e.g. the assuming and FunctionAdvisor commands, albeit they did a poor job at all that in my opinion.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

As pointed out by you, Oliveira, this was an issue visible only when the Physics setting assumingusesAssume was equal to true . The problem was actually within assuming, not  Physics:-Assume, and not noticed before because the old assume command redefines assumed variables, something that the more modern Physics:-Assume does not do. The issue is now fixed at its root and so assuming works as expected with the Physics setting assumingusesAssume. The adjustment is distributed for everybody within the Maplesoft Physics Updates v.416 or higher.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

## Two different things...

Hi

First of all: no, there is no leakage with regards to use and any other package  (Physics included). What this is: most packages have initialization files that set a few things here and there. That is not always documented properly. When you invoke use Package that initialization is executed, and whatever got set remains set after end use. That accounts for what Rouben Rostamian mentioned, about the use of the dot to display derivatives with respect to t . Historically, this was a Maple default, which however changed one or two releases ago, and I decided to keep that default in place when you load Physics, for natural reasons.

Second, there is a bug, not a leakage, with regards to the Physics's default setting 'assumingusesAssume'. When you load (or use) Physics, that setting is set to true, also for obvious reasons (Physics:-Assume does not redefine assumed variables, representing a significant advantage all around). This bug was mentioned as such yesterday, in this other Mapleprimes post by you, Oliveira. But this has nothing to do with leakages or use .

It is important to recall here that the implementation of both old and more modern ideas (e.g. assuming using either assume or the more modern Physics:-Assume), as every portion of code, is only as good as the amount of hours tested / debugged. Finding an issue in the interaction of assuming and Physics:-Assume is rare, I'm glad that the problem got uncovered. I noticed, however, that were not for Carl Love extra comments, you (Oliveira) were not going to mention the origin of your problem (that dsolve was returning only one branch instead of three, in connection with loading Physics and its automatic setting assumingusesAsume = true). Having good mathematical software is a collective endeavour. Reports of things not working as expected, with the necessary details for reproducing them, is perhaps the most important thing / contribution to the project.

Note after post: That problem in assuming when using Physics with the setting assumingusesAssume is fixed and the adjustment distributed for everybody within the Maplesoft Physics Updates v.416 or higher.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.

## Fixed, Maplesoft Physics Updates v.411 a...

Hi Rouben

Good catch, tricky problem, this issue is fixed and the fix available to everybody within the Maplesoft Physics Updates version 411 or higher. What follows is your worksheet, your text, with any added text in italic style. and the new result and its verification.

We solve Laplace's equation in the domain
in polar coordinates subject to prescribed Dirichlet data.

Maple produces a solution in the form of an infinite sum,
but that solution fails to satisfy the boundary condition
on the domain's outer arc.  Is this a bug or am I missing
something?

The issue is resolved, the solution, shown below, is correct.

 > restart;
 > # kernelopts(version);
 >
 (1)
 > with(plots):
 > pde := diff(u(r,t),r,r) + diff(u(r,t),r)/r + diff(u(r,t),t,t)/r^2 = 0;
 (2)
 > a, b, c, d := 1, 2, Pi/6, Pi/2;
 (3)
 > bc := u(r,c)=c, u(r,d)=0, u(a,t)=0, u(b,t)=t;
 (4)

We plot the boundary data on the domain's outer arc:

 > p1 := plots:-spacecurve([b*cos(t), b*sin(t), t], t=c..d, color=red, thickness=5);

Solve the PDE:

 > pdsol := pdsolve({pde, bc});
 (5)

Try pdetest, and verify that what remains is actually 0 in the region of interests (see boundary conditions passed in (4))

 >
 (6)
 >
 (7)
 >
 (8)

The following verifies OK, the plot is sufficiently close to 0 in the region of interest,

 >

Next 'remains' to be verified

 >
 (9)

The following also verifies OK, the plot is again sufficiently close to 0 in the region of interest,

 >

Try your verification approach just changing 'value' by eval at Sum = add  and using 100 terms instead of just 20; also change the orientation a bit to make the comparison more evident

Truncate the infinite sum at [20] 200 terms, and plot the result:

 >
 > p2 := plot3d([r*cos(t), r*sin(t), %], r=a..b, t=c..d, orientation=[32, 40, 20]);

Here is the combined plot of the solution and the boundary condition.
We see that the proposed solution [after installing the Maplesoft Physics Updates v.411 or higher] does satisfy the boundary condition.

 > plots:-display([p1, p2], orientation=[32, 40, 20]);
 >

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

## pdsolve's solution is correct and issue ...

The solution returned by pdsolve is correct, the starting term with  should be computed taking limits (see vv's reply). On the other hand, I can also see the issue you are pointing at: it is standard to compute the sum by just evaluating the summation index, and if you do so you receive division by 0.

A change in the code that resolves that issue, presenting the special cases computed as branches in a piecewise, is distributed within the Maplesoft Physics updates v.410 and higher, so that after installing that Update you get

 >
 >

 >
 (1)

Another example

 >
 >
 >
 (2)
 >

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

## No bug...

Hi
I see no bug here. In
> ee := (((Q(a)^3)^(5/4))^(15/7))^(6/8);

you have a four times nested anything^rational type object. So, for the call on the left-hand side of what you posted, for any P, the call

> subsindets(ee, anything^rational, P)

will be applied, from the inside to the outside, 4 times, resulting in

P(P(P(P(Q(a)^3)^(5/4))^(15/7))^(3/4))

But then on the right-hand side of what you posted, I see subsindets applied to objects of type specfunc(Q)^rational, that is a different thing, and within ee I see only one object of that type, so the call

> subsindets(ee, specfunc(Q)^rational, P);

results, again as expected, in

((P(Q(a)^3)^(5/4))^(15/7))^(3/4)

Make now P be

> P := proc(x) if type(x, specfunc(Q)^rational) then 'Q(x)' else 'x' fi end

and you see the two results you got, all this is as expected.

Note as well that if you don't want subsindets to be applied recursively, you can use its option 'flat'. Also, to see subsindets at work (after you have assigned the procedure P) it suffices to trace P, entering trace(P); then call subsindets again

> subsindets(ee, anything^rational, P);
{--> enter P, args = Q(a)^3
<-- exit P (now at top level) = Q(Q(a)^3)}
{--> enter P, args = Q(Q(a)^3)^(5/4)
<-- exit P (now at top level) = Q(Q(Q(a)^3)^(5/4))}
{--> enter P, args = Q(Q(Q(a)^3)^(5/4))^(15/7)
<-- exit P (now at top level) = Q(Q(Q(Q(a)^3)^(5/4))^(15/7))}
{--> enter P, args = Q(Q(Q(Q(a)^3)^(5/4))^(15/7))^(3/4)
<-- exit P (now at top level) = Q(Q(Q(Q(Q(a)^3)^(5/4))^(15/7))^(3/4))}

while for the other type you used you have

> subsindets(ee, specfunc(Q)^rational, P);
{--> enter P, args = Q(a)^3
<-- exit P (now at top level) = Q(Q(a)^3)}

In summary that I see no bug here.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

## Identities...

Have in mind that pFq, more than most functions actually, satisfy a myriad of identities (try FunctionAdvisor(identities, hypergeom([a, b], [c], z)), each of which has an apparently different integral representation. This is the same simplification problem mentioned in your previous post, two things that are the same but look different, making zero recognition difficult, not algorithmically possible in all cases.

Besides, the solution returned by dsolve uses Intat, not Int. There is no conversion to Intat, a more intelligent comand (think of it as an integral evaluated at a point - the equivalent to a derivative evaluated at a point represented in Maple by the D command).

As for your comment about odetest "does not give zero", its help page explains that a solution could be correct but, because of zero recognition, odetest will not find zero. I thought it was clear in the replies you received for the previous post you made today. I also showed, in one of those replies, what you could do in those cases: test the solution with a plot (equivalent to saying "numerically"). You could copy the input lines I posted in reply to your previous post and try to apply them for this your hand_solution.

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