ecterrab

12714 Reputation

24 Badges

17 years, 263 days

MaplePrimes Activity


These are answers submitted by ecterrab

This is fixed, and the fix is available for everybody using Maple 2021.2 by installing the Maplesoft Physics Updates v.1125.

Details: the solution proposed by @mmcdara is correct, but will convert to the commutative :-`*` operator, not to the generalized product operator of the Physics package, that also handles anticommutative and noncommutative variables. The fix introduced converts to the generalized `*` instead of  :-`*`. And if what you wanted when entering [a, b] is their commutator, the solution by @Pascal4QM is the way to go.

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

There is no way you can 'change' the display of these differential operators. Being able to change the display would be equivalent to being able to change the display of - basically - everything else too. Although that is possible, it requires internal programing of the Typesetting routines. Not something for everyone.

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

The following, attempted to transform the implicit solution in explicit, hangs:

> solve(1/tan(1/2*ln(y(x)/x))-ln(x)-_C1, y(x));

I am tracking this in the bugs' database.

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


restartode := diff(w(z), z, z)+f(z)*(diff(w(z), z))+g(z)*w(z) = 0

diff(diff(w(z), z), z)+f(z)*(diff(w(z), z))+g(z)*w(z) = 0

(1)

transformation := eta = int(exp(-(int(f(z), z))), z)

eta = int(exp(-(int(f(z), z))), z)

(2)

If the above is the new independent variable eta, then in the terminology used in the help page PDEtools:-dchange your inverse transformation is of the form

ITR := {transformation, v(eta) = w(z)}

{eta = int(exp(-(int(f(z), z))), z), v(eta) = w(z)}

(3)

The problem with tthe above is that you do not have a simple representation for the direct transformation; that is: you don't know how to express z = F(eta). The best algebraic representation you have for F(eta)is using RootOf, so that the complete transformation you need to use is

TR__complicated := PDEtools:-Solve(ITR, {z, w(z)})

{z = RootOf(eta-Intat(exp(-(Int(f(_b), _b))), _b = _Z)), w(z) = v(eta)}

(4)

You can us this one, but don't expect something simple right away

PDEtools:-dchange(TR__complicated, ode, [eta, v(eta)], known = all, simplify)

g(RootOf(eta-Intat(exp(-(Int(f(_b), _b))), _b = _Z)))*v(eta)+(diff(diff(v(eta), eta), eta))*exp(-2*Intat(f(_b), _b = RootOf(eta-Intat(exp(-(Int(f(_b), _b))), _b = _Z)))) = 0

(5)

In your post, however, you mix variables by expressing g as a function of z, not eta, and ditto for the exponential. To do that, select the first transformation equation in TR__complicated

TR__complicated[1]

z = RootOf(eta-Intat(exp(-(Int(f(_b), _b))), _b = _Z))

(6)

subs((rhs = lhs)(z = RootOf(eta-Intat(exp(-(Int(f(_b), _b))), _b = _Z))), g(RootOf(eta-Intat(exp(-(Int(f(_b), _b))), _b = _Z)))*v(eta)+(diff(diff(v(eta), eta), eta))*exp(-2*Intat(f(_b), _b = RootOf(eta-Intat(exp(-(Int(f(_b), _b))), _b = _Z)))) = 0)

v(eta)*g(z)+(diff(diff(v(eta), eta), eta))*exp(-2*Intat(f(_b), _b = z)) = 0

(7)

And this is the result you show. You can still remove the intat

convert(v(eta)*g(z)+(diff(diff(v(eta), eta), eta))*exp(-2*Intat(f(_b), _b = z)) = 0, Int)

v(eta)*g(z)+(diff(diff(v(eta), eta), eta))*exp(-2*(Int(f(z), z))) = 0

(8)

 

NULL


 

Download given_inverse_transformation_of_the_independent_variable.mw

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

with(Physics); with(Vectors)

sys := {diff(x(t), t) = y(t), diff(y(t), t) = -x(t)}

{diff(x(t), t) = y(t), diff(y(t), t) = -x(t)}

(1)

This is perhaps what you are looking for when saying more automatic? The system knows about these things. Note however that, in thie context of this package, what you call polar coordinates is the 2D (x,y) part of a 3D cylindrical system of coordinates. So,

ChangeCoordinates(sys, cylindrical)

{(diff(rho(t), t))*cos(phi(t))-rho(t)*(diff(phi(t), t))*sin(phi(t)) = rho(t)*sin(phi(t)), (diff(rho(t), t))*sin(phi(t))+rho(t)*(diff(phi(t), t))*cos(phi(t)) = -rho(t)*cos(phi(t))}

(2)

solve({(diff(rho(t), t))*cos(phi(t))-rho(t)*(diff(phi(t), t))*sin(phi(t)) = rho(t)*sin(phi(t)), (diff(rho(t), t))*sin(phi(t))+rho(t)*(diff(phi(t), t))*cos(phi(t)) = -rho(t)*cos(phi(t))}, diff(({phi, rho})(t), t))

{diff(phi(t), t) = -1, diff(rho(t), t) = 0}

(3)

By the way, the documentation of the Physics:-Vectors package looks clear and complete ... if you feel it doesn't please post some suggestions (thanks) and I will take them a look.

Download ChangeCoordinates.mw

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

 

with(Physics)

g_[sc]

Physics:-g_[mu, nu] = Matrix(%id = 36893488152178629316)

(1)

Riemann[alpha, beta, mu, nu]^2

Physics:-Riemann[alpha, beta, mu, nu]*Physics:-Riemann[`~alpha`, `~beta`, `~mu`, `~nu`]

(2)

SumOverRepeatedIndices(Physics[Riemann][alpha, beta, mu, nu]*Physics[Riemann][`~alpha`, `~beta`, `~mu`, `~nu`])

48*m^2/r^6

(3)

Weyl[alpha, beta, mu, nu]^2

Physics:-Weyl[alpha, beta, mu, nu]*Physics:-Weyl[`~alpha`, `~beta`, `~mu`, `~nu`]

(4)

SumOverRepeatedIndices(Physics[Weyl][alpha, beta, mu, nu]*Physics[Weyl][`~alpha`, `~beta`, `~mu`, `~nu`])

48*m^2/r^6

(5)

For things like this, or more details, or in general related to tensors, see the help page Physics,Tensors , it is a well organized help page with sections, subsections and examples.

NULL


 

Download Riemann_and_Weyl_SumOverRepeatedIndices.mw

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

This is a portion of your worksheet, showing the operation that I think resolves your problem.

restart

with(Physics)

Setup(mathematicalnotation = true)

[mathematicalnotation = true]

(1)

Setup(noncommutativeprefix = e)

[noncommutativeprefix = {e}]

(2)

p := Commutator(e[0], e[1])

Physics:-Commutator(e[0], e[1])

(3)

expand(p)

Physics:-`*`(e[0], e[1])-Physics:-`*`(e[1], e[0])

(4)

Suppose you want to eliminate portions of it in favor of something else. That includes, for instance, going back the operation. Here is one somewhat general way of accomplishing that. In steps, you want to use

(%Commutator = `@`(expand, Commutator))(e[0], e[1])

%Commutator(e[0], e[1]) = Physics:-`*`(e[0], e[1])-Physics:-`*`(e[1], e[0])

(5)

to eliminate e[0]*e[1]. You can do this

Physics[`*`](e[0], e[1])-Physics[`*`](e[1], e[0])

Physics:-`*`(e[0], e[1])-Physics:-`*`(e[1], e[0])

(6)

simplify(Physics[`*`](e[0], e[1])-Physics[`*`](e[1], e[0]), {%Commutator(e[0], e[1]) = Physics[`*`](e[0], e[1])-Physics[`*`](e[1], e[0])}, {e[0]*e[1]})

%Commutator(e[0], e[1])

(7)

In that way, for example, your

H[2] := a^2*(e[0]*e[1]-e[0]*e[1])*zeta[2]

a^2*zeta[2]*(Physics:-`*`(e[0], e[1])-Physics:-`*`(e[1], e[0]))

(8)

becomes

simplify(H[2], {%Commutator(e[0], e[1]) = Physics[`*`](e[0], e[1])-Physics[`*`](e[1], e[0])}, {e[0]*e[1]})

a^2*zeta[2]*%Commutator(e[0], e[1])

(9)

``


NOTE AFTER ANSWERING: You can also use the command Physics:-SortProducts  with the optional argument usecommutator; see the related help page.

Download Drinfieldstuff_display_(reviewed).mw

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

___________________________________________________________________
NOTE AFTER WRITING THE REPLY BELOW
 

Taking a look, this appeared to be an issue in the flow of IntegrationTools:-Indefinite:-RationalFunction, as @acer hinted at; it is a case where the code could go into an infinite loop and was not taking preemptive action against that. It is fixed, and the fix is distributed to everybody in the Maplesoft Physics Updates v.1113 just uploaded.

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

@itsme, others

While in principle, the issue being reported in this thread is, naturally, an issue in int or subroutines called by int, fixing - say - a bug in a simplifier can trigger a change in behaviour when computing an integral, or for the case anything else.

That said, the Maplesoft Physics Updates have been around for ~ seven years or more and, systematically, improved the Maple experience: things get fixed right away in the same way they are fixed in the version under development. You just get the fixes today instead of having to wait for the new Maple release. Take A and B into account, and some will prefer not to have these fixes in advance. Others will prefer to have them (would be my case, for that reason is that I put them available).

I also recall that neither I am external to Maplesoft nor the Physics package is an add-on. Instead, I have been a Maplesoft employee since 1997, and the author not just of Physics but also the FunctionAdvisor, the symbolic-solution differential equation code, a large part of the simplifier, several parts of the integrator, symbolic and numerical code for mathematical functions, differential algebra/geometry, etc. etc. including latex and the MmaTranslator package. All code you use every day and that doesn't feel to you as an add-on. But for whatever reason, sometimes people ask me if Physics is an add-on or whether the Maplesoft Physics Updates are a Maplesoft product. No, Physics is not an add-on, and yes the Maplesoft Physics Updates is a Maplesoft product.

I will debug this int example and write again here - though I currently do not take care of the integrator, which may make it challenging to include the fix in the subsequent Physics Updates.

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

Besides @itsme answer, which is clearly the way to experiment, the issue you point at triggers more a question than an answer: when a line doesn't fit within the margins of a paper page (your comment about "fits within the margins of my screen" is not relevant, screen and paper don't have the same margins), so: what do you expect? If the line overflows, it is bad. Also not line breaking?

To my eyes, in the example you show, the line breaking performance is a fantastic "automatic" performance. However, from your post, it is clearly not satisfactory for you. For this purpose, I implemented \\ and {}, both to linebreak where you want (regardless of automatism) and avoid a line breaking where you do not want it. All this together with the setting mentioned by @itsme is explained on the help page.

In summary, @nm I don't see something to adjust further, but for a manual touch using \\ or {} plus the suggestion about tweaking the value of the linelength setting to see if you get something that you like it better.

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


Check the version of Physics you have installed in your copy of Maple 2020: it should be v.923, the last one for Maple 2020:

Physics:-Version()

`The "Physics Updates" version in the MapleCloud is 1097. The version installed in this computer is 923 created 2021, March 1, 17:27 hours Pacific Time, found in the directory /Users/ecterrab/maple/toolbox/2020/Physics Updates/lib/`

(1)

 

Now the material of your worksheet. This time I retyped everything from reading the image you posted. Please next time upload the worksheet using the Green arrow.

with(Physics)

Coordinates([C = [t, r, theta, phi], M = [t, rho, phi, z]])

{C, M}

(2)

Setup(g_[mu, nu] = -dt^2+a(t)^2*dr^2+r^2*(dtheta^2+sin(theta)^2*dphi^2))

[metric = {(1, 1) = -1, (2, 2) = a(t)^2, (3, 3) = r^2, (4, 4) = r^2*sin(theta)^2}, spaceindices = lowercaselatin_is]

(3)

Define(XX[`~alpha`] = [t, sqrt(rho^2+z^2), arctan(rho/z), phi])

{Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], XX[`~alpha`], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](C), Physics:-SpaceTimeVector[mu](M)}

(4)

Verify the contravariant and covariant components

"XX[~]"

XX[`~mu`] = Array(%id = 36893488152282539300)

(5)

XX[]

XX[mu] = Array(%id = 36893488152282530388)

(6)

All OK. Proceed with defining E

"Define(E[mu,~nu] = d_[mu](XX[~nu],M))"

{Physics:-D_[mu], Physics:-Dgamma[mu], E[mu, `~nu`], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], XX[`~alpha`], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](C), Physics:-SpaceTimeVector[mu](M)}

(7)

 

Check the components of the tensor on the right-hand side of this definition

E[definition]

E[mu, `~nu`] = Physics:-d_[mu](XX[`~nu`], [M])

(8)

TensorArray(rhs(E[mu, `~nu`] = Physics[d_][mu](XX[`~nu`], [M])))

Matrix(%id = 36893488152313132204)

(9)

 

Looks OK to me.  Check the matrix form

"E[mu,~nu,matrix]"

E[mu, `~nu`] = Matrix(%id = 36893488152299461436)

(10)

This result is correct, the same as (9), and different from what you post. Guessing about that difference, I imagine you don't have the Physics Updates installed, which provides fixes to issues that get reported, and updates (new developments). To resolve your problem just install that latest update for Maple 2020 entering:

Physics:-Version(923)

NULL


 

Download Define_issue_in_Maple_2020.mw

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

The mini-page entry for SubstituteOperators is not yet in the ?Physics,Library help page.

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

So the unexpected "division by zero" is fixed and the fix distributed within the Physics Updates v.1048.

Details: not a bug in dsolve but in the interaction between solve and simplify, as you can see entering tracelast after receiving that error message.

To the side, I see it got mentioned the difference between passing the solving variables as a list or as a set. There is a difference and this is intentional - and useful - design. In brief, when triangularizing a nonlinear system of equations, that is deriving, one at a time, a sub-system of equations that involves only one of the unknowns, to solve for it and eliminating it from the rest of the original system, it matters what unknown you try to eliminate first. I imagine everybody understands that so I won't expand.

So, when you pass the second argument as [Xc(t), Sy(t)], dsolve calls PDEtools:-casesplit with that ordering and, accordingly,  casesplit (check its help page) constructs first a subsystem that involves only Sy(t), dsolve receives that, solves for it and eliminates Sy(t), remaining to solve a system that involves only Xc(t). Of course, for this to work all the intermediate steps (calls to solve, series, int, simplify, etc. etc.) need to perform successfully.

In this particular example, for your choice  [Xc(t), Sy(t)] not all the intermediate operations are successful, so the system cannot be solved, while for  [Sy(t), Xc(t)] the intermediate operations are all doable and the system is solved to the end.

So how do you know "which ordering is better?" Generally speaking: there is no answer for that. But, experience accumulated allowed me to construct a very detailed approach to estimating what would be the best ordering for solving non-linear systems (differential or not) when using dsolve, pdsolve or PDEtools:-Solve. And that is the routine used by default when you pass the solving variables as a set, not a list. That is why you see the system solved when passing { Xc(t), Sy(t) }. Of course, this very tricky approach coded will not work all the time (I wrote it, that statement is not a guess), or otherwise, the choice of best ordering would be systematic, and we know it is not. For those cases, you can play around passing the solving variables as a list.

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

In short, there is nothing wrong with Physics:-Vectors regarding your example. Just remove the line "with(LinearAlgebra)" and everything works as expected.

Details. Physics:-Vectors includes a command, `&x`, that represents the cross product. That command is loaded when you load Physics:-Vectors. In your worksheet, however, after that, you are also loading LinearAlgebra, which also has a command `&x` to represent the cross product. Since the last package loaded is LinearAlgebra, when you input `&x` you are invoking LinearAlgebra:-`&x`, not Physics:-Vectors:-`&x`. Take a closer look at the error message you received (in the worksheet you posted) and you see it: the message comes from LinearAlgebra:-`&x`, which doesn't understand the algebraic-vector-notation used in Physics:-Vectors. 

The main difference between these two packages: in Physics:-Vectors, the vectors are algebraic structures, additions of coefficients times unit vectors, as we do when working with vectors with paper and pencil. These objects are of type algebraic, so if V_ is a vector, then type(V_, algebraic) returns true. On the other hand, in LinearAlgebra everything is a Matrix also presented as a Vector structure (internally, a Matrix with only 1 line), none of these objects are of type algebraic. They are of type rtable (check the documentation about that).

Now, with objects of type algebraic you do all sorts of algebraic operations (simplify, factor, expand, etc.). It is not the same with objects of type rtable. Additionally, with objects of type algebraic, in Physics:-Vectors you can represent a non-projected vector, as in V_, with all its properties understood by the system, while with rtables you cannot: only projected vectors can be represented. Abstract vectors are at the core of Vector Analysis. Examples of their usefulness are in the first section, on Vector Analysis, of the help page ?Physics,Examples.

 

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

@snpa 
Thanks for the worksheet. I see the problem. The code assumed x and y were scalars in one place, which is not the case in general. That is now fixed and the fix included in the latest Maplesoft Physics Updates v.1038, available for everybody using the current Maple 2021.

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

NOTE ADDED Aug/19: This issue in the MapleCloud, described below (Aug/18), is now fixed.

======================================================================
The problem is not that. The problem is in MapleCloud. When the command Physics:-Versions tries to get the version on the MapelCloud it gets this:

> PackageTools:-GetProperty(5137472255164416,"X-CloudVersion");
Error, (in JSON:-JSONParse) invalid JSON

 

This problem is not restricted to the Physics Updates. For example, the MapleCloud package "MagicPuzzles" has ID 5755630338965504 and you get the same Error:

> PackageTools:-GetProperty(5755630338965504,"X-CloudVersion");
Error, (in JSON:-JSONParse) invalid JSON

 

This problem has been reported before and is tracked so that it gets fixed. In particular, the simple instruction Physics:-Version(latest) fails to install the latest version because of this problem, though as said in the title when you click "Updates" in the MapleCloud toolbar to update "Physics Updates", it does get installed.

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

5 6 7 8 9 10 11 Last Page 7 of 52