ecterrab

13431 Reputation

24 Badges

19 years, 362 days

MaplePrimes Activity


These are answers submitted by ecterrab

Hi

The simplest way to achieve this is to set u, v and w as quantum operators; that automatically makes them be noncommutative, including the indexed u[j], v[k] w[l], and you have [u[j], u[k]][-] = 0, as shown in the image below.

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

Hi nm,

Good catch; in connection with recent developments, this PDE & BC was now flowing through a branch of the code that resulted in a very complicated differential elimination problem while trying to solve the problem. That is adjusted now for everybody having Maple 2018.1 in version 75 of the Maplesoft Physics Updates.

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

Hi nm,

Indeed, this PDE & ic/bc problem is solved until the Physics Updates version 49 inclusive, then further developments starting in the update number 50 produced this problem you noticed. The issue is now fixed in the Physics Updates version 73, where the PDE & ic/b you posted is solved to the end. (Due to several changes in the flow the simplification of the solution for this example can still be improved - to be done in one of the next updates.)

In connection with Tomleslie comment, note as well that you can always install a previous version of the Physics Updates safely, due to the new MapleCloud approach. For example to install version 49, open Maple and input PackageTools:-Install("5137472255164416", version = 49, overwrite) followed by restart. Then to re-install the latest version, input PackageTools:-Install("5137472255164416", overwrite), i.e. without specifying any version.

This Version 73 of the Physics Updates includes as well a better simplification for the solutions returned, improving the one you pointed out as not simplified in your comment to Improvements in solving PDE & BC in Maple 2018.1.

Finally, the command Physics:-Version() now reports both the version number in the MapleCloud and the version number installed in your computer, so that you can tell right away whether you have or not the latest version.

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


 

Hi Leostork

 

For this computation it is simpler to use the Physics  package.

with(Physics)

 

Set the dimension to 2, the coordinates, and the metric by passing the line element you indicated

Setup(dimension = 2, coordinates = (X = (x, t)), metric = f(x)*dt*dx+h(x)*dx^2)

`* Partial match of  'coordinates' against keyword 'coordinatesystems'`

 

`The dimension and signature of the tensor space are set to: `[2, -` +`]

 

`Default differentiation variables for d_, D_ and dAlembertian are:`*{X = (x, t)}

 

`Systems of spacetime Coordinates are:`*{X = (x, t)}

 

"`
``Warning, for the signature `(-` +`)`, that is with the timelike component in position `2`, the spacetime metric indicated has `g[0,0]` = `g[2,2]` = `0`, and so the corresponding system of reference cannot be realized with real bodies (e.g. you cannot define proper time nor synchronize clocks in any infinitesimal region of space).`"

 

[coordinatesystems = {X}, dimension = 2, metric = {(1, 1) = h(x), (1, 2) = (1/2)*f(x)}]

(1)

Note the warning message, it is related only to the physics aspect of your metric. As you say, in 2D or higher this situation doesn't prevent you to compute Christoffel symbols, for instance the nonzero components of the first and second kind respectively are

Christoffel[nonzero]

Physics:-Christoffel[alpha, mu, nu] = {(1, 1, 1) = (1/2)*(diff(h(x), x)), (2, 1, 1) = (1/2)*(diff(f(x), x))}

(2)

Christoffel[`~alpha`, mu, nu, nonzero]

Physics:-Christoffel[`~alpha`, mu, nu] = {(1, 1, 1) = (diff(f(x), x))/f(x), (2, 1, 1) = (-2*h(x)*(diff(f(x), x))+(diff(h(x), x))*f(x))/f(x)^2}

(3)

By the way, note that you can compute with Christoffel  using values for the indices as well:

Christoffel[1, 1, 1]

(1/2)*(diff(h(x), x))

(4)

"Christoffel[~1,1,1]"

(diff(f(x), x))/f(x)

(5)

"seq(Christoffel[~j,mu,nu,matrix], ~j = [~1, ~2])"

Physics:-Christoffel[`~1`, mu, nu] = Matrix(%id = 18446744078430966838), Physics:-Christoffel[`~2`, mu, nu] = Matrix(%id = 18446744078430968278)

(6)

NULL


 

Download Christoffel_2D.mw

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

This was a problem in the normalizer of expressions of PDEtools, nice catch. It is fixed now in Version 71 of the Maplesoft Physics Updates for Maple 2018.1, available to everybody from the Maplesoft R&D Physics webpage.

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

Hi vv;

I uploaded a new version (67) of Maplesoft's Physics Updates that fixes the Typesetting issue you noticed (that you can reproduce outside this call to evalf@frac by entering, directly, INTERVAL();). With this Update installed,there is no more difference between having set or not printelevel := 40.

Also, `evalf/frac` is not called, regardless of whether you set or not printlevel (to see that, input stopat(`evalf/frac`); right before printlevel := 40: you see the debugger is not launched). After fixing this issue in Typesetting, you always get 23.0, not 0, regardless of the value of printlevel.

About your implicit question "The typesetting mechanism is supposed to be used for display purposes, ...". Indeed. However, when you compute with high printlevel values, the Typesetting routines are called to produce the debug lines you see on the screen, and the extended Typesetting is implemented as a Maple library, programs subject to programming issues that will result in error interruptions. This makes it easy to program the Typesetting code (good) also very easy to fix it (also good), but has this downside of error interruptions, which however could be bypassed making Typesetting resort to typesetting = standard when there is an error (because errors can be trapped and the flow redirected, you know). For some reason, this bypassing mechanism is not implemented, I suppose the intention is to detect these programming issues to fix them ... I don't know.

Regarding Acer's comment, evalf(frac(Pi^20)) is not going through evalf/frac; that is easy to explain: frac is first computed, then the result is passed to evalf, and that result does not contain frac. The same happens if you enter debug(`evalf/sin`); followed by evalf(sin(0)), and the flow does not go through `evalf/sin`.

Finally, regarding '23'as result, I see this computation is sensitive to Digits (mentioned by Carl?). This is a kernel operation: the numerical approximation of the number Pi^20-8769956796 (that is the output of frac(Piˆ20)). For Digits := 11 the value is < 1. For Digits := 15 we already have ~0.08.

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

 


 

restart; with(Physics); Setup(math = true)

[mathematicalnotation = true]

(1)

Suggestion: always give a look at the help page of a command before using it. This is one of the most important things in computer algebra. The following is a couple of comments on what you've done first,then the actual input / output regarding your question (and no there is no bug in what you show).

 

So, according to the help page for Ket , the first argument of the Ket command identifies the basis to which this ket belongs and, if it is a quantum operator, then the Ket is an eigenket of that operator. Also, to construct a Ket associated to an anticommutative operator (fractional spin) you need to indicate that the operator is anticommutative, using Setup .

 

Looking at your formulation of the problem, you used 'spin' as the first argument to Ket, but didn't set 'spin' to be a quantum operator (i.e., something that does not commute but with itself unless you set specific algebra rules for it). You also didn't set 'spin' to be anticommutative.

 

Next, about tensor products, and this is important because the notation in textbooks is sometimes not very explicit about this, you construct tensor products of states taking products of Kets that belong to different (disjointed )Hilbert spaces. Saying the same thing but reversing the sentence, you do not construct tensor products of states with Kets that belong to one and the same Hilbert space.

 

What sometimes create confusion is that, in applications, frequently, two disjointed Hilbert spaces are a replica of each other, as in two identical copies of the same Hilbert space (nevertheless disjointed), making people forget that the (tensor) product of states involves states of disjointed Hilbert spaces (identical or not).

 

Hence, in your approach, instead of (down*n1+p1*up)*(down*n2+p2*up) , where up and down in the first factor belong to one and the same Hilbert space as up and down in the second factor, you need to use (down__1*n1+p1*up__1)*(down__2*n2+p2*up__2) where you see I am using a pair of Kets {up__1, down__1}; for the first Hilbert space and a different pair  (albeit a replica of the first pair){up__2, down__2} for the second Hilbert space.

 

Finally, there is one question, not answered in the help pages because it involves new functionality (present in the just released Maple 2018.1 but not yet documented), about how do you indicate that two Hilbert spaces are disjointed (as in: they belong to universes that have no intersection whatsoever).

 

With all these things in mind, now to the input/output. I am using Maple 2018.1 with the "Physics Updates" installed.

Physics:-Version()[2]

`2018, June 20, 17:29 hours, MapleCloud version: 62`

(2)

 

 

First, to indicate that two Hilbert spaces are disjointed you indicated corresponding quantum operators that act on the different Hilbert space, and that will also serve as a Ket labels for Kets that belong to different Hilbert spaces. Setting disjointed Hilbert spaces automatically set the labels as quantum operators. For your example I will use here S__1 and S__2, that display indexed, and you see these labels appear in different color already indicating they are quantum (noncommutative) operators

 

Setup(hilbertspaces = {S__1, S__2})

[disjointedspaces = {{S__1}, {S__2}}]

(3)

Now set your kets up and down, belonging to two disjointed Hilbert spaces

up__1 := Ket(S__1, 1/2)

Physics:-Ket(S__1, 1/2)

(4)

up__2 := Ket(S__2, 1/2)

Physics:-Ket(S__2, 1/2)

(5)

down__1 := Ket(S__1, -1/2)

Physics:-Ket(S__1, -1/2)

(6)

down__2 := Ket(S__2, -1/2)

Physics:-Ket(S__2, -1/2)

(7)

Take the product you present in your worksheet but now involving Kets of both spaces, so forming a tensor product of states

(down__1*n1+p1*up__1)*(down__2*n2+p2*up__2)

Physics:-`*`(p1*Physics:-Ket(S__1, 1/2)+n1*Physics:-Ket(S__1, -1/2), p2*Physics:-Ket(S__2, 1/2)+n2*Physics:-Ket(S__2, -1/2))

(8)

Expand this product

Expand(Physics[`*`](p1*Physics[Ket](S__1, 1/2)+n1*Physics[Ket](S__1, -1/2), p2*Physics[Ket](S__2, 1/2)+n2*Physics[Ket](S__2, -1/2)))

p1*p2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, 1/2))+p1*n2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, -1/2))+n1*p2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, 1/2))+n1*n2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, -1/2))

(9)

You see the order now appears "correctly" in the sense that it is as you see in textbooks. (I note, however, that the ordering in a tensor product of kets that belong to disjointed Hilbert spaces is irrelevant;   up__1*down__2 = up__1*down__2).

 

Two other comments.

 

Since, when working with tensor products, we frequently work with Hilbert spaces that are replicas of each other, in textbooks we frequently see the Ket labels (here S__1 and S__2) omitted. For this purpose use the (yet undocumented) hideketlabel option

Setup(hide = true)

`* Partial match of  'hide' against keyword 'hideketlabel'`

 

[hideketlabel = true]

(10)

Now (9) is displayed in a more readable fashion

p1*p2*Physics[`*`](Physics[Ket](S__1, 1/2), Physics[Ket](S__2, 1/2))+p1*n2*Physics[`*`](Physics[Ket](S__1, 1/2), Physics[Ket](S__2, -1/2))+n1*p2*Physics[`*`](Physics[Ket](S__1, -1/2), Physics[Ket](S__2, 1/2))+n1*n2*Physics[`*`](Physics[Ket](S__1, -1/2), Physics[Ket](S__2, -1/2))

p1*p2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, 1/2))+p1*n2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, -1/2))+n1*p2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, 1/2))+n1*n2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, -1/2))

(11)

Since - say in the first term - each Ket belongs to a different Hilbert space, the display `&otimes;`(Ket(S__1, 1/2), Ket(S__2, 1/2)) may seem ambiguous, but it is not: the ordering in all the terms is: first the Bras and Kets of the first Hilbert space, then those of the second one taking advantage that, mathematically speaking, the ordering is not relevant. But if you forget what this ordering is you can always enter

show

p1*p2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, 1/2))+p1*n2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, -1/2))+n1*p2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, 1/2))+n1*n2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, -1/2))

(12)

and that makes visible the labels, while you continue working without displaying it

p1*p2*Physics[`*`](Physics[Ket](S__1, 1/2), Physics[Ket](S__2, 1/2))+p1*n2*Physics[`*`](Physics[Ket](S__1, 1/2), Physics[Ket](S__2, -1/2))+n1*p2*Physics[`*`](Physics[Ket](S__1, -1/2), Physics[Ket](S__2, 1/2))+n1*n2*Physics[`*`](Physics[Ket](S__1, -1/2), Physics[Ket](S__2, -1/2))

p1*p2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, 1/2))+p1*n2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, -1/2))+n1*p2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, 1/2))+n1*n2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, -1/2))

(13)

 

You can also use the macros ON and OFF to turn ON and OFF the display of the ket label during several input/output lines.

 

The second comment is about making S__1 and S__2 be anticommutative. The simplest way to accomplish that in one go is to set S to be an anticommutative prefix

Setup(anticommutativeprefix = S)

[anticommutativeprefix = {S, _lambda}]

(14)

You see that now S, and everything anticommutative, is displayed in in purple. For example:

down__1*up__1

Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__1, 1/2))

(15)

show

Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__1, 1/2))

(16)

Note however that now these Kets, themselves, are anticommutative:

map(type, [S__1, S__2, up__1, up__2, down__1, down__2], anticommutative)

[true, true, true, true, true, true]

(17)

Library:-AntiCommute(up__1, down__1)

true

(18)

(%AntiCommutator = AntiCommutator)(up__1, down__1)

%AntiCommutator(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__1, -1/2)) = 0

(19)

down__1*up__1+down__1*up__1

0

(20)

With all that in mind, perform now the same computation; the result, just that as said now the kets and corresponding operators are all anticommutative

(down__1*n1+p1*up__1)*(down__2*n2+p2*up__2)

Physics:-`*`(p1*Physics:-Ket(S__1, 1/2)+n1*Physics:-Ket(S__1, -1/2), p2*Physics:-Ket(S__2, 1/2)+n2*Physics:-Ket(S__2, -1/2))

(21)

Expand(Physics[`*`](p1*Physics[Ket](S__1, 1/2)+n1*Physics[Ket](S__1, -1/2), p2*Physics[Ket](S__2, 1/2)+n2*Physics[Ket](S__2, -1/2)))

p1*p2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, 1/2))+p1*n2*Physics:-`*`(Physics:-Ket(S__1, 1/2), Physics:-Ket(S__2, -1/2))+n1*p2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, 1/2))+n1*n2*Physics:-`*`(Physics:-Ket(S__1, -1/2), Physics:-Ket(S__2, -1/2))

(22)

NULL

 

``


 

Download tensor_product_of_spin_states.mw

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

This one is fixed with the latest Physics Updates and the fix available for everybody using Maple 2018 or the recently released 2018.1. After installing the Update you get
 

Physics:-Version()[2]

`2018, June 18, 20:21 hours, MapleCloud version: 61`

(1)

with(Physics)
Setup(noncommutativeprefix = {P, Q})NULL

[noncommutativeprefix = {P, Q}]

(2)

e1 := Q^2*P*Q+Q*P*(Q^2)

Physics:-`*`(Physics:-`^`(Q, 2), P, Q)+Physics:-`*`(Q, P, Physics:-`^`(Q, 2))

(3)

simplify(e1)

Physics:-`*`(Physics:-`^`(Q, 2), P, Q)+Physics:-`*`(Q, P, Physics:-`^`(Q, 2))

(4)

e2 := (Q^2*P*Q+Q*P*(Q^2))(t)

Physics:-`*`(Physics:-`^`(Q(t), 2), P(t), Q(t))+Physics:-`*`(Q(t), P(t), Physics:-`^`(Q(t), 2))

(5)

simplify(e2)

Physics:-`*`(Physics:-`^`(Q(t), 2), P(t), Q(t))+Physics:-`*`(Q(t), P(t), Physics:-`^`(Q(t), 2))

(6)

Both (4) and (6) are correct. Try now with an algebra rule setting P and Q to commute between themselves:

 

Setup(%Commutator(P, Q) = 0)

[algebrarules = {%Commutator(P, Q) = 0}]

(7)

simplify(e1)

2*Physics:-`*`(P, Physics:-`^`(Q, 3))

(8)

simplify(e2)

2*Physics:-`*`(P(t), Physics:-`^`(Q(t), 3))

(9)

NULL


 

Download fix_(reviewed).mw

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

Hi

You know, to compute that exponential exactly and in finite form, you need, mainly, to know whether A and B commute with their commutator. Say this is the easy case, otherwise you have an infinite product. For the easy case you can use the Maple Physics package right away, as shown in this image:

Generally speaking to compute, in a more complicated situation, either a truncated expansion or a finite form when it exists, can also be done using Physics and its Physics:-Library tools.

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


 

Hi Bland3,

Below I intercalated a few comments, all italized - the text found in the worksheet you posted is not italized, and I didn't add input (all you see below is yours).

 

restart

with(Physics): with(combinat): with(LinearAlgebra): with(ArrayTools): with(ListTools): Setup(mathematicalnotation=true):

Setup(mathematicalnotation=true):

Setup(quantumop={cre,ann}, algebrarules={%AntiCommutator(cre[j],ann[k])=I*KroneckerDelta[j,k]})

`* Partial match of  'quantumop' against keyword 'quantumoperators'`

 

[algebrarules = {%AntiCommutator(cre[j], ann[k]) = I*Physics:-KroneckerDelta[j, k]}, quantumoperators = {ann, cre}]

(1)

 Algebra handles the anti-cummutations fine of the creation and annihilations, but not annihilation-annihilation or creation-creation.

 

You didn't tell the system about the algebra rules between annihilation - annihilation, nor creation - creation, and those rules are not implicit in %AntiCommutator(cre[j], ann[k]) = I*delta[j, k].

 

It also doesn't simplify products of these (such that terms like annihilation[j] ^2 should evaluate to 0).

 

That is true if and only if the ann[j] operator is fermionic, but you didn't indicate that to the system.

 

So here it doesn't know what to do with the annihilation-annihilation Anti-Commutator, so it assumes it commutes.

AntiCommutator(cre[1],ann[1]);
AntiCommutator(cre[1],ann[2]);

I

 

0

(2)

The two results above, actually, use the algebra rule you indicated, they are correct.

 

Simplify(ann[1]*ann[1]);

Physics:-`^`(ann[1], 2)

(3)

AntiCommutator(ann[1],ann[1]);

Physics:-AntiCommutator(ann[1], ann[1])

(4)

The two results above are also correct: neither ann[1] is anticommutative nor you told the system about the Anticommutator of the ann[j]. To indicate that your ann is anticommutative you can set ann to be an anticommutative prefix, as in "Setup(anticommutativeprefix=ann)."

 

Also relevant: why not using the Annihilation Creation commands that come with the Physics package? All these algebra rules and conventions, products, etc. are understood by the system without you having to defining everything from scratch.

 

I suggest you to try these two, and see if that is sufficient for you to formulate your problem. If not, please post again, now with using proper fermionic operators (as is implicit in your expected result for ann[1]^2)  and using the full-featured Annihilation / Creation operators that already come with the Physics package.


 

Download LatticeCalcsAlgebraIssues_(reviewed).mw

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

This one is fixed in the Physics Updates version 43, available from the Maplesoft R&D Physics webpage.

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

This is fixed in the latest Physics Updates available from the Maplesoft R&D Physics webpage.

restart

with(Physics)

g_[]

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

(1)

Coordinates(X)

`Default differentiation variables for d_, D_ and dAlembertian are:`*{X = (x1, x2, x3, x4)}

 

`Systems of spacetime Coordinates are:`*{X = (x1, x2, x3, x4)}

 

{X}

(2)

"d_[~4](C(X))"

Physics:-diff(C(X), x4)

(3)

Setup(metric = `+++-`)

_______________________________________________________

 

`The Minkowski metric, with signature + + + -, in coordinates `*[x1, x2, x3, x4]

 

_______________________________________________________

(4)

g_[]

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

(5)

So, for this metric, the covariant components differ from the contravariant ones in the sign of the component number 4.

 

Now your definitions

{A[`~mu`] = [0, 0, 0, n(X)], U[`~mu`] = [u(X), 0, 0, 1]}

Define(op(%), quiet)

Checking things ...

A[definition]

A[`~mu`] = [0, 0, 0, n(X)]

(6)

"A[~]"

A[`~mu`] = Array(%id = 18446744078375541566)

(7)

A[]

A[mu] = Array(%id = 18446744078375544702)

(8)

U[definition]

U[`~mu`] = [u(X), 0, 0, 1]

(9)

"U[~]"

U[`~mu`] = Array(%id = 18446744078375550974)

(10)

U[]

U[mu] = Array(%id = 18446744078375554214)

(11)

On the signs of the operator `&PartialD;`[mu] = d/dx^mu, take for instance A^4

"A[~4]"

n(X)

(12)

"d_[mu](A[~4])"

Physics:-d_[mu](n(X), [X])

(13)

TensorArray(%)

Array(%id = 18446744078375639750)

(14)

Now if you make the index contravariant, we expect a change in the sign of the component number 4

"d_[~mu](A[~4])"

Physics:-d_[`~mu`](n(X), [X])

(15)

TensorArray(%)

Array(%id = 18446744078375654934)

(16)

All OK. Resuming with the formulas of your question:

F[mu, nu] = d_[mu](A[nu])-d_[nu](A[mu])

F[mu, nu] = Physics:-d_[mu](A[nu], [X])-Physics:-d_[nu](A[mu], [X])

(17)

Define(%, quiet)

{A[`~mu`], Physics:-Dgamma[mu], F[mu, nu], Physics:-Psigma[mu], U[`~mu`], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-KroneckerDelta[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(18)

F[definition]

F[mu, nu] = Physics:-d_[mu](A[nu], [X])-Physics:-d_[nu](A[mu], [X])

(19)

F[]

F[mu, nu] = Matrix(%id = 18446744078375529398)

(20)

"F[~]"

F[`~mu`, `~nu`] = Matrix(%id = 18446744078278073750)

(21)

The above looks OK to me. Then

"F[~0,~mu].U[mu]"

-F[mu, `~4`]*U[`~mu`]

(22)

This now returns the expected result.

TensorArray(-F[mu, `~4`]*U[`~mu`])

-(diff(n(X), x1))*u(X)

(23)

 

``


 

Download changing_signs_in_metric.mw

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

Hi nm,

Physics:-Version was written having for context the updates distributed with zips, before Maple 2018: nobody remembered the number (e.g., for Maple 2017 there were 300 updates uploaded), so looking at the date was simpler. The date of the last update was (and still is) posted at the Maplesoft R&D Physics webpage; comparing that date with the one shown by Physics:-Version(); you'd know whether you have the last version.

New in Maple 2018, the updates of physics, differential equations and mathematical functions code (that is the "Physics Updates" package) are now distributed through the MapleCloud, making the installation of the update really simpler. And the related MapleCloud version number is just the same version number you always saw in the Maplesoft R&D Physics webpage. Also new: this number can now be retrieved programmatically.

I just uploaded version 39, with several adjustments into the DE code, in connection with the use of the new (fantastic) DifferentialThomas package for performing differential elimination. In this update, I also modified Physics:-Version()so that it returns the version number as well.

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

Hi John

This problem is fixed in the Physics Updates version 37, available from the Maplesoft R&D Physics webpage. Attached is your worksheet revised, with some further comments: you do not need two LeviCivita (galilean and nongalilean) to perform this computation, because your tetrad system is already galilean (orthonormal) so that LeviCivita[a,b,c,d], with tetrad indices, is already galilean in that system of references.

 

Download MixedTypeLeviCivitas_(reviewed).mw

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

Hi Edahl,

The computation you show can be done in a simpler manner using the Physics package - check its help page (?Physics) and the help pages for Setup, g_, Christoffel, Ricci and LieDerivative. Important: if you dump things in text format, in order to help you people need to start copy & paste, prone to mistakes and more work. Instead of that, could you please upload the worksheet? For that purpose, you can use the green arrow you see when you write a question.

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

First 26 27 28 29 30 31 32 Last Page 28 of 55