ecterrab

13431 Reputation

24 Badges

19 years, 358 days

MaplePrimes Activity


These are replies submitted by ecterrab

@Preben Alsholm 

That is definitely a bug in int. Your use of assuming deviated the attention at first but no: expr2 has no locals while res := int(expr2, p) contains a[5], where a is a local variable, and that is not related to the use of assuming before or after calling int:


 

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

@Jean-Michel Collard 

OK. Please check all these things in order to resolve the issue. Maple is always installed in the directory shown via

> kernelopts(mapledir);  # <- could you please enter this and show the output?

From what you show for libname, apparently, in your computer Maple is installed under "C:\Maths\Maple". The main libraries of the Maple system are then in the directory "lib" below kernelopts(mapledir), that would be "C:\Maths\Maple\lib".

The message you see from Physics:-Version() is telling you that the active version of Physics is found in "C:\Maths\Maple\lib" and not where you have the Physics Updates installed, which is the directory shown by

> kernelopts(':-toolboxdir' = "Physics Updates");

Expected is  "C:\Users\jm\maple\toolbox\2020\Physics Updates", or "C:\Users\jm\maple\toolbox\Physics Updates" without the 2020. So please follow the instructions in this comment I made regarding a similar question. It is key that the file override_maple.txt is present because it tells Maple that the directory should go first in the sequence in libname. 

So after following those instructions, close and reopen Maple, and input

> libname;

It should show the directory "lib" under the directory kernelopts(':-toolboxdir' = "Physics Updates"). If so, everything is correct and when you enter Physics:-Version(); it will show the latest version active. 

From there on, you should be able to get the next versions of the Updates using the icons of the MapleCloud or directly entering Physics:-Version(latest);

I hope these guidelines resolve your problem, which of course it is not "yours" but a problem in the Maple installer; I understand it is going to be fixed in a Maple 2020.1.1 to be released.

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

@DarkMath 
Yes. That is also mentioned in the help page - see ?convert,VectorCalculus, the same page opens via ?convert,PhysicsVectors.

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

@Jean-Michel Collard 
Next, install the Updates using the MapleCloud icons. Then close Maple, open Maple, and show please the output for

Physics:-Version();
libname;
 

If Version tells the update is installed but not active, please discover where is it installed (probalby under C:\Users\jm\maple\toolbox) and put all that information your next reply, thanks.

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

@tomleslie 

There is no "PhysicsUpdates installer". There is the PackageTools Maple package, which is used by the MapleCloud and other commands to install things. Unfortunately, there is an issue in PackageTools such that the 2020 directory got omitted, also in Maple 2020.0. That was not an obstacle to installing the package and had it working but, apparently, it is in 2020.1 in your case. Anyway I am glad to hear that, after inserting (manually) the 2020 subdirectory, things work as expected.

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

@tomleslie 

Well, at least we are out of the woods! :) Unfortunately, this is not something I can fix within the Updates. It would be interesting to do the following. Check your rights to the directory toolbox/2020 (make sure you have full rights) then: enter restart; Physics:-Version(708); then restart; Physics:-Version(latest). Expected: it works, first installing the previous version, then installing the latest version, and always under toolbox/2020. If so, from here in you can update, as usual, either entering 'latest' or through the MapleCloud icons. If not, there is still a problem - probably a rights issue.

Best

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

@tomleslie 

The "mserver.exe has stopped working" is clearly an issue, probably the whole issue. I know of another person having this problem, and the problem has been reported to the people who take care of it. 

Meantime, this is the structure of directory and files that I expect for Maple 2020.1:

So please create 2020 below toolbox, then move the Physics Updates directory within 2020, as you see in the image. You can get the Physics Updates.maple file downloading manually from the Maplesoft R&D Physics webpage, and you do have the version.txt from the failed installation. For the override_maple.txt, copy the one you have in Maple 2019 or previous.

That will make the Updates work and in the right place (under 2020; could you please confirm that it works) while there is a fix for these 2020.1 problems. By the way, the installation issue you are having (but for missing the 2020 directory) does not happen in Macintosh.

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

@tomleslie 

Please recall: "Then close, then reopen Maple (not just 'restart'), and input 'Physics:-Version()', everything should work. If not, then also input 'libname', and reply here showing a picture with the output of Version and libname. With that info we can figure out what is going on at your end."

I still don't see that image showing the output of Version and libname. Only with that info, obtained after closing and reopening Maple, is that I can give you an opinion of what could be going on.

Independent of that: from what you say, somehow the download is not working for you - maybe a rights issue. One alternative is for you to download the package and move the Physics Updates.mla to the expected directory. This should't be necessary but it is a workaround. I've seen another person with this crash, so maybe there is something wrong with the 2020.1 update of Maple.

In any case, this is the contents of an email I received of someone with the same problem, how he solve the rights issue:
 

"Ok, just a quick follow up... i think the issue is that the permission of the folder:
~/maple/toolbox/Physics Updates

were set to `root` - i'm not sure how or why that happened (?). 
But a moment ago, I ran maple as root, then updated physics while running a root session (it seemed to have installed the package into my normal user directly's maple folder). Then manually changed the permissions (recursively) of ~/maple. That seemed to have worked. When I run Physics:-Version(latest) now, after starting maple as a non-root user, it tells me I have the latest. "

Summarizing what I think is going on: there is a rights issue on the directory, that should fix the problem, or you can download and put the file where it should be.

Best

Edgardo

@mthkvv 

The current v.687 contains further developments, not rollbacks. Define handles `&mu;` and `~&mu;` in definitions, `&mu;`, `~&mu;` are now valid indices, mu and `~&mu;` are not considered repeated indices when in a product, only the pairs [mu, ~mu] and [`&mu;`, `~&mu;`] respectively are. All that is new. And you cannot sum over repeated indices for objects before defining them as tensors, that is old.

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

@mthkvv 

Sorry but that won't happen. As said, that would complicate the code unnecessarily: in the output, we already have excellent typesetting, so all this is about how the input looks. But for the input, as said right-click and converting to 2D-Math input achieves an even better result: a greek letter and presented as a superscript, with no ~.

The only situation where we need to handle `~&mu;` is when you are passing a tensorial equation "to define" a tensor and you want to see ~mu as a Greek letter (by typing ~mu, then pressing escape and chosing mu you will receive `~&mu;` that looks like at ~ followed by the greek leter). In that case, the right-click & convert will not produce ~mu as a superscript because at the input level (before pressing enter in a call to Define) that object is not yet a tensor, and so the index is not typeset as a tensor index (greek and superscript, while keeping its semantics equal to ~mu).

That exception is now handled since v.686 in the only place I can think it happens, which is when passing a tensorial equation to be defined using Define, as in your original example. In the latest example you posted, anyway you cannot perform a sum over repeated indices of an object that is not a tensor (will be after you press enter in that call to Define), so your example is invalid regardless of any typesetting issue.

Just try it. Type ~mu, then right-click and convert the tensorial expression to 2D Math input and you will see it working.

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

@mthkvv 

..hmm you meant `&mu;` and `~&mu;`, not mu and ~mu, which are automatically, always summed, unless you explicitly ask otherwise.

A bad news and a good news. The bad one: mu and `~&mu;` are not seen as "repeated indices" but for the context of Define, which handles the defining expression only once and can workaround the computer syntactic detail.

But there are too many places in the package where the convention is that repeated indices are A and ~A, not A and `~&A;`. So at this point that has no simple solution (and going all the way to implement that may end up introducing a level of complexity in the package that is not a good idea).

The good news is that to have a nice display, you do not need what you are asking. Instead: right-click the input line and select the menu 2-D Math -> Convert To -> 2-D Math Input, and not only you will see ~mu written with a Greek letter but also as a superscript (instead of this Fortranish tilde).

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

@mthkvv 

In v.686 the two problems are addressed: you can now define a tensor, using mixed covariant and contravariant, in a curved spacetime and when the tensorial expression involves objects that are not actually tensors, as is the case of d_[nu](v[~mu]) in the definition that you posted as problematic. Additionally, from v.686 on, things like `&mu;`, that also appear from times to times in the GUI and are indistinguishable from the greek letter mu, as well as `~&mu;`, are both valid tensor indices in equal footing with mu and ~mu.

This pic, an excerpt of your last worksheet (_3.mw) shows how both things work now, 

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

@mthkvv 
You say "Yes, I did definitions with different indices intentionally.". It is good, we caught one more exception. The problem being that, when you convert to d_, the first term of the covariant derivative becomes d_[nu](v[~mu]) and that is not a tensor. The code assumes it is and, when normalizing the defintion, just substitutes ~mu by mu to get the covariant form, which of course is correct if an only if you are substituting in a tensor. The code got fooled by your input because the left-hand side of the definition is a tensor OK (of type Physics:-Library:-PhysicsType:-Tensor) but - as said - the first term after converting to d_, is not. The fix is simple, check that the right-hand side is also a tensor in the current coordinates (command Physics:-Library:-IsTensorInCurrentCoordinates).

That said, I wonder your intention ... what was it? Regarding ~mu, this is a longstanding issue with the GUI: it sometimes transforms `mu` into `&mu;` and `~mu` into `~&mu;`. I will adjust the code to understand `&mu;` and `&mu;~` as valid as  `mu` and `~mu` indices.

Note after the post: but mu and `~&mu;` are not considered repeated indices when in a product. Only the pairs [mu, ~mu] and [`&mu;`, `~&mu;`] are.

About your other post regarding the font: it is also a known issue. Acer gave you a good suggestion to address the problem locally in your machine, until Maplesoft fixes the problem.

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

@mthkvv 

NOTE ADDED May 25: the issue mentioned below as 'to be fixed later today', is also resolved by installing the Maplesoft Physics Updates v.686 or newer.
 

The computations are performed correclyt if in the definitions you use all free indices covariant , as you see below, which is your worksheet but entering the defnitions of the tensors dv1, dv2, dv3 and dv4 using indices all covariant. I will fix the problem that arises when you Define with one index covariant the other contravariant, and post the fix in the nex version of the Physics Updates later today.

 

To the side, note that to get the matrix form there is a shortcut: [] produces the all covariant components and "[~]" the all contravariant ones. Finally, maybe you noticed maybe not: you can always post your worksheet with the contents itself visible, and you can insert text in the document: in any line (or open one above or below the cursor) by pressing Ctrl + T (or Command + T in Macintosh) or by clicking 'Text' in the context bar.

 

with(Physics)``

Setup(mathematicalnotation = true)

Coordinates(X = [t, r, theta, phi])

{X}

(1)

g_[sc]

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

(2)

Define(v[mu] = (Vector[row](4, {(1) = (r-2*m)/r, (2) = 0, (3) = 0, (4) = 0})))

{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], Physics:-d_[mu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(3)

v[]

v[mu] = Array(%id = 18446744078294210310)

(4)

Define(dv1[mu, nu] = `&dtri;`[nu](v[mu]))

{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], Physics:-d_[mu], dv1[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(5)

dv1[]

dv1[mu, nu] = Matrix(%id = 18446744078413868318)

(6)

Define(dv2[mu, nu] = convert(`&dtri;`[nu](v[mu]), d_))

{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], Physics:-d_[mu], dv1[mu, nu], dv2[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(7)

dv2[]

dv2[mu, nu] = Matrix(%id = 18446744078383960062)

(8)

Define(v[mu] = (Vector[row](4, {(1) = 1, (2) = 0, (3) = 0, (4) = 0})))

{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], Physics:-d_[mu], dv1[mu, nu], dv2[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(9)

v[]

v[mu] = Array(%id = 18446744078383946438)

(10)

Define(dv3[mu, nu] = `&dtri;`[nu](v[mu]))

{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], Physics:-d_[mu], dv1[mu, nu], dv2[mu, nu], dv3[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(11)

dv3[]

dv3[mu, nu] = Matrix(%id = 18446744078310429630)

(12)

Define(dv4[mu, nu] = convert(`&dtri;`[nu](v[mu]), d_))

{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], Physics:-d_[mu], dv1[mu, nu], dv2[mu, nu], dv3[mu, nu], dv4[mu, nu], Physics:-g_[mu, nu], Physics:-gamma_[i, j], v[mu], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(13)

dv4[]

dv4[mu, nu] = Matrix(%id = 18446744078431803862)

(14)

``

NULL


 

Download cov_diff_bug_3_(reviewed).mw

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

@vv 

There is only one Maple syntax indeed. Essentially, whatever you write using that syntax when the display is 1D, you can write when the display is 2D with the same meaning. But then there is also (as the 15th order term in a series expansion ...) a very small number of things that change, mostly related to not leaving a space between operators, as for example the one you mention. However, you see: with so many years using Maple, programming in Maple, and having used 1D display of input as well as 2D display of input, I never - ever -  crossed with this example you are mentioning now, simply put: wasn't even aware of it. If something, your example basically makes my point, in my opinion.

With all due respect, honest respect I have for you, vv, to think otherwise, that because of this example, then what you write when using 1D display doesn't work when using 2D display seems to me a blatant misrepresentation of the actual situation. People need to understand how this works 99.999 % of the time. It may even be useful to collect the minuscule exceptions, but not useful to think they are the issue here.

Most of the confusion about this, in fact, I think, derives from the mistake of calling these modes "1D input" and "2D input" when in reality they mean "1D display" and "2D display" of the same sequence of characters being input. Plus the fact that when using "2D display" of the input, you can, additionally, optionally, also use a space to represent multiplication, as we do with paper and pencil.

One last comment for Janhardo: what I meant by Maple syntax is not about programming. Maple syntax is just how we express mathematics on the worksheet. So 1+1 is Maple syntax, f(x), diff(f(x), x), all that is Maple syntax. 

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

 

First 15 16 17 18 19 20 21 Last Page 17 of 60