Download The_metric_[27_37_1].mw

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

First, recall that the tetrad, represented in Maple by Tetrads:-e_, is defined up to a Lorentz rotation of the tetrad system of references, so you can write it in infinitely many different ways. There are also orthonormal and null tetrads, related to the form of the tetrad metric, represented in Maple by Tetrads:-eta_.

So answering your questions, yes, when you load Physics:-Tetrads a tetrad is automatically computed on background, and by default it is an orthonormal tetrad, to which corresponds a Minkowski form of the tetrad metric. By entering Setup(tetradmetric = null), a null tetrad is automatically computed (this is easy, you can construct it directly from the orthonormal one).

Then suppose E is a 4x4 matrix and you want this matrix to be the tetrad: input Setup(tetrad = E). and the tetrad metric will be automatically computed following your definition E of the tetrad. But suppose that, in addition, you want to also specify the tetrad metric in any particular form, say a 4x4 matrix Eta (it needs to be symmetric, you know): input Setup(tetradmetric = Eta).

So you can work with any tetrad and tetrad metric you want. When you set both the tetrad and the tetrad metric manually, however, you need to be careful with one thing: input e_[definition] and you see the relationship between the tetrad e_ and tetrad metric eta_. So after setting both the tetrad and the tetrad metric manually, input TensorArray(e_[definition]) and see if you do have a matrix of equalities (i.e. whether you defined these two consistent with each other).

Also important, the Tetrads commands OrthonormalTetrad and NullTetrad will compute tetrads of the respective kinds for you, with options (see their help page), the command IsTetrad will tell you whether your matrix E is or not a tetrad and of which kind, and the command TransformTetrad allows you to rotate the tetrad in independent ways; you can make it be whatever you want, including transforming automatically into a canonical form (that implies on a canonical form of the Weyl scalars - see the help page ?TransformTetrad).

On multiple tetrad systems: you can have only one tetrad system, the so-called local system of references, where the Christoffel symbols are all equal to 0, in an infinitesimal neighbourhood of that point the spacetime is flat. Given a point in spacetime, you have one tetrad system, not many. The fact that you can Lorentz-rotate this system arbitrarily doesn't make it be many systems. I don't understand what do you mean by multiple tetrad systems.

Finally, on the conditions for beta(t, r) < 1, input Assume(beta(t, r) < 1). On the type of letter to input different kinds of indices, you can set that as you prefer, for instance, you can swap the Physics default entering Setup(spacetimeindices = lowercase, tetradindices=greek).

I suggest you take these comments into account and hopefully they help you to move forward in your worksheet - then post again. Other people will probably find your development useful for their work.

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

The different behavior is related to the history of these two commands ... PDEtools:-Solve works using differential elimination (whatever that means is not relevant here) that requires every single variable to be classified according to its role, while solve uses a different approach (details skipped).

For PDEtools:-Solve, the question you wanted to ask is 

In this call, you indicate that the main variables are the aj, while the etaj are parameters, meaning you expect the solution with the aj isolated as functions of the parameters, with possibly some further conditions for the parameters (last two equations). 

You do not have that distinction between main variables and parameters witinin solve, where the question would be

The output by PDEtools:-Solve can be improved, but this example is not a good one, since passing your input to solve you also don't get what you expect (I am assuming that) - somehow the question is not properly possed, precissely for the reasons mentioned in the error message by PDEtools:-Solve.

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

Download plot_complex_expression.mw

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

You know, tetrads are defined up to an arbitrary Lorentz rotation of the tetrad system, so naturally, there are infinitely many ways of writing a tetrad correctly. Equation (27.22) in Stephani's book shows this:

So in order to help you with this, or fix something in the code if necessary, would you mind please to write, in the worksheet you attached, the null tetrad matrix you expect, as a matrix, and post the worksheet again.

Please note: after you write the matrix - say M - that is the tetrad you expect, before reposting your worksheet input this:

So I expect true, indicating that the matrix M is indeed a tetrad, and xxx indicating what type of tetrad is it, orthonormal or null. If you don't get true but still think your M is a tetrad, please post anyway and I will give it a second look.

Independent of all the above, note that: a) the database of solutions is accessible regarding the solutions, not the tetrads, presented or not in the book, and b) you do have, in the Tetrads package, several commands to depart from one tetrad and obtain another one, notably TransformTetrad.

Not only TransformTetrad can perform all the different transformations for tetrads mentioned in Stephani's book, but more: it can, automatically, compute a canonicalform for the tetrad, so that the Weyl scalars appear with a certain form, all this explained in ?TransformTetrad. This help page, by the way, is not a standard one but something close to a textbook section on the matter. The topic is advanced. I intended to present a self-complete and clear page as opposed to a very technical and undecipherable one.

If you were already aware of all that, please disregard these comments. Otherwise, there is a source of computational manipulations there that you may be missing and that allows you to work with any tetrad of your preference.

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

Hi

Good catch. The variable keeping track of intermediate simplifications was reinitialized by mistake at line 19, as shown by showstat. This problem is fixed and the fix available to everybody using Maple 2020 within the Maplesoft Physics Updates v.828 or newer.

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

Hi nm,

I realize the natural interest in having that piece of information. In the past, there was a Maple worksheet, updated with each new version, with that contents.

But then the Updates grew in coverage and scope. The task of producing fixes that are compatible with "the previous version" (that for you is the "current version") plus having new developments also consistent, plus testing a large number of things before uploading a new version of the Updates, all together takes an amount of time that leaves 0 for that description you ask now.

It is also the case that I am producing these Physics Updates during spare time, only because I like the idea; the fixes and developments are happening - so why not present them around the clock? Most fixes in new versions, or new features, are directly related to feedback by people, so someone at least knows what is new in the version being uploaded. Unfortunately, this project also makes me divert valuable time on the infrastructure that makes it possible (MapleCloud, etc.).

So yes, it would be nice, but it won't happen.

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

It is probably related to the large number of changes happening at this point. I am adding a test for this example.

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

Nice to see someone playing with the symgen routines; there are, for me, several beautiful ideas behind this code. This is my first work in differential equations, done in 1995 with Luiz Duarte and Luis da Mota in Brasil. On to the problem, the core idea in the symgen routines, that surprised several for their efficacy, is that we map differential equations into an algebraic problem for which, frequently, solutions exist that are computable without solving any differential equation. You realize the gain this represents. On the other hand, it is not the case that such solutions always exist.

Take your ODE

You see, the solution is easy to compute BUT requires solving differential equations and so are out of the scope of symgen. That is why DEtools:-symgen(ode, HINT = [f(x), g(x)*y]) doesn't succeed in this example. An important consideration is that, at the time the symgen routines were written, the capabilities of Maple's dsolve were rudimentary. Mapping an ODE into a problem that required solving differential equations was just of no use. It was actually the presentation of symgen that changed the game, triggering a full rewriting of Maple's dsolve in 1997, now using the symgen routines at its core.

Years later I wrote the symmetry routines of PDEtools, a package also originally written in 1995 in Brasil, with Katherina von Bulow . Basically all the symmetry commands in (O)DEtools have an equivalent in PDEtools. For symgen, the equivalent is Infinitesimals. At the time of writing it, however, Maple's dsolve was already a powerful command, so I coded Infinitesimals such that it tackles the problem for the infinitesimals as a differential equations problem. That is why PDEtools:-Infinitesimals(ode, HINT = [f(x), g(x)*y]) succeeds in this case.

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

In particular, dsolve(equation, useint) will request dsolve to try to compute the integrals, regardless of their complexity or the result potentially be a wallpaper. Analogously, the useInt option requests not to attempt computing any integral. The output is a solution in terms of integrals. The call dsolve(equation) - neither useint nor useInt around - uses an internal algorithm that will attempt computing the integral most of the times but not always, and also discard wallpaper integrations preferring the compact uncomputed integral. That algorithm is pretty efficient, but it may end up avoiding the computation of an integral in a case where the integration can be performed smoothly.

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

@Carl Love,  nm

I wrote this help page and program. I wrote "work as well", that is what I meant. Not at all "works well". The page actually says, as you quoted, that for 1st order ODEs by using this algorithm you map the original problem into an equivalent one, so no gain, i.e. in that case it does not work well. I am a non-native-English speaker but I don't see what would be wrong with this use of "work as well" in this sentence of this help page.

Regarding the hang, as the help page tells, in the first step the algorithm constructed another ODE "equivalently difficult to solve", whose solution involves integrals with wallpaper integrands involving unresolvable RootOfs. The system hangs when trying to perform those integrations in order to move to the second step. You see the flow entering debug(`symgen/formal`). I don't see a problem here. The use of formal for 1st order ODEs is just inappropriate, even if allowed mainly for pedagogical purposes.

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

The problem with mathit is that it removes blank spaces, while in Maple, it is valid to have "symbols" with blank spaces. The textit approach resolved that. There are, of course, other options: add an extra \; after textit, or use the alternatives to work around the removal of blank spaces.

I will think about it.

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

One of the bugs in the old latex command is, precisely, what you are showing: the imaginary unit is I but appears translated as i. The fix consists of: respect your choice.

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

Thanks for the report; this one is fixed in the Maplesoft Physics Updates v.786 or newer. That version also added one more Usexxx variable: Latex:-UseColor := true (default value). With that, for example, Latex(Int(f(x),x)) gets translate using gray, but if you don't want colours set Latex:-UseColor := false.

Regarding one other question you posted: a) now, Typesetting settings do not get changed unless you with(Physics). Besides, you can also assign Latex:-UseTypesettingCurrentSettings := true for that same purpose. And b) assuming does not use Physics:-Assume unless you with(Physics), or you explicitly enter Physics:-Setup(assumingusesAssume = true). For an example of the convenience of using Physics:-Assume instead of assume, see the explanation and examples in ?assuming,details.

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

Update to Maplesoft Physics Updates v.779 or newer, then put Physics:-Latex:-UseTypesettingCurrentSettings := true at the top of your scripts, or in a worksheet before using Physics exports (e.g. Latex), or in your .mapleinit file read when you open Maple. Then your "current" Typesetting settings (whatever they are) will not be "extended", when you load Physics, or when you use Physics exports like Latex and execute a product that requires initializing the package.

Details.

In Maple, for a long time, the default was interface(typesetting = standard). Since some years it is interface(typesetting = extended). I like that. For a release or two interface(typesetting = extended) implied on Typesetting:-EnableTypesetRule(Typesetting:-SpecialFunctionRules); Typesetting:-Settings(':-typesetdot' = true); and Typesetting:-Settings(':-typesetprime' = true). And physicists enjoyed that, up to the feedback I receive,

But then those three Typesetting settings were removed from "interface(typesetting = extended)", which remained the default. After asking for opinions, we end up maintaining these three settings active when you initialize Physics (using 'with' or using its exports) and interface(typesetting = extended) (or the equivalent Physics command Setup(mathematicalnotation = true). Since then It's been several years, and it is the first time someone using Physics complains about using the prime or the dot settings - naturally because they are of no use in your case.

In brief, a possible solution to this is as implemented now: set your Typesetting settings as you prefer then enter Physics:-Latex:-UseTypesettingCurrentSettings := true, before using any Physics command or before loading the package, and your Typesetting settings will not be extended or changed.

As for any other issue you noticed (e.g. itsme seems to have crossed with other things but didn't provide examples), please recall the package is not finished, your feedback is very welcome, either describe them in an email with attached worksheet to physics@maplesoft.com, or post that worksheet here (Green arrow please). Thanks.

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