To compute KillingVectors using the distributed Maple, see the help page ?Physics:-KillingVectors. The Examples section contains examples showing how to use the command.

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

Hi
You understood right; non-projected means a vector that is not projected on any particular basis. Such an object, represented as you say, ending the vector's name with an underscore, used in textbooks to formulate vectorial equations, has several properties under vector or vectorial differential operations (Nabla) that are understood by the system even when the vector is not projected. So this is not just about "representing" the object but about computing with it without projecting it; for examples, see the section on "Vectors and Analytical Geometry" on the page ?Physics,examples.

In textbooks, the distinction between projected and non-projected is more formal; the letter - say - A_, represents both. So nobody uses any particular wording for non-projected vectors. On a computer algebra worksheet, however, where, historically, only projected vectors were represented - as matrices - the distinction is relevant: if you say vectors people think/expect those matrices only, while a key feature of Physics:-Vectors is that you have symbolic representation for vectors, projected, or not. So it appeared to me appropriate to introduce the words non-projected, explicitly in several places in the help system.

About your questions:

• if in the first item you meant "how it looks," using alias(A = _i) you can get _i displayed the way you prefer.
• On the second item: It is not difficult to extend Physics:-Vectors so that one can define a vector basis that is not Cartesian, cylindrical or spherical, but it's not been done yet. So at this point, you can only project onto that three orthonormal bases.
• About the third item: yes you can use both packages together, but they have commands with the same name. So I recommend you pay special attention to the ordering: if first VectorCalculus, then Physics:-Vectors, you will be using the commands of  Physics:-Vectors, and can invoque those of VectorCaclulus using the long form (e.g. VectorCalculus:-Curl) Note as well that there is a convert routine to convert between the Physics:-Vectors (algebraic, symbolic) and VectorCaclulus (matricial) representations for vectors.  See ?convert,PhysicsVectors

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

Download dot_notation.mw

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

Although the failure in trapping the interruption is a kernel issue, the error interruption should not happen in the first place; thanks to my colleague Austin Roche for his super-fast fix of that. By the way, the problem was not related to odetest but in a simplify subroutine.

The fix is available as usual to everybody using Maple 2022 by installing the Maplesoft Physics Updates, achieved using the MapleCloude toolbar (packages/updates).

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

It says

.. the number of new and old independent variables must be the same. Found {zz, tau[2]} as new, while {FN, var[1], var[2]} as old.

That said, I see one of your transformation equations is FN = Y(zz), but there is no FN in pde1. Remove that equation and the change of variables proceeds.

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

@tomleslie @nm

Yes, the useint optional argument is the way to go if you want to always have the integrals computed even if they may eventually result in a wall-paper instead of a 1 line expression with an uncomputed integral.

As to when it appears to be convenient not to evaluate an integral, basically, it is about two things:

• the integration may take a significant amount of time and memory, even when it is an intermediate one;
• the result may appear as a wallpaper, not really of better use than the same solution expressed with an uncomputed integral;
• these wallpapers, when happening during intermediate algebraic manipulations (a gazillion of them) are frequently a significant obstacle to computing a solution to-the-end;
• from a design point of view, it is important to have the main three activities of DE solving, 1) formulating the solution in terms of integrals and algebraic 'solve'ing,  2) integration (options useInt and useint), 3) algebraic 'solve'ing (option implicit), as disentangled as possible.

The example you posted, @nm, is of that sort, second item above, the implicit form of solution you show with the integral computed has, generally speaking, no better value than the 1/2 line solution with an uncomputed integral that you also show.

Regarding "how is it done?" That is a different question, it involves heuristics, some basic integration knowledge, and some verification after-the-facts. For those curious about the internal routines for accomplishing the task, well, Maple is very open about that. Check `PDEtools/int` and the subroutines it calls.

Regarding "is this a good design?" The answer, as usual, depends on the observer. As the author of the DE Maple code, I can tell you that this design (avoid spending too much time producing wallpapers not-more-useful than uncomputed integrals) is a key element in the performance you see of the Maple differential equation solvers.

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

What you say is simpler to accomplish using the Physics package - take a look at the help page ?Physics,Tensors.

That said, in order to receive good help, it is useful if you post a worksheet (for that, use the Green arrow you see when you post your question) with your attempt to formulate the problem you have in mind. From there, it is frequently easier to understand you and give you more specific feedback.

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

The answer depends on the person. My take: I see, frankly, a lot of advantages in using 2D-Math notation when typing input. I type as if I were using 1D-Math notation, and for free, I get a space after a coma, equal or unequal signs, exponents appear as superscripts, subscripts appear as subscripts, fractions as fractions, etc.

Then if a problem happens, if I have some patience, I report it, and it gets fixed. If you have an old one unfixed, please post it here. If I am in a rush, right-click, 2D Math > Convert To > 1D-Math and revise with my eyes what the problem is, with everything visible (as in a FORTRAN program, say).

Now, you see, am I a programmer or someone that only wants math notation? Yes, I am a programmer; as many people here know, I wrote a significant portion of the Maple library, and yes, I want math notation - my brain parses what I read 10 to 100 times faster. I recently even went to the extreme of changing the way integration constants and functions are returned by dsolve and pdsolve.

Besides, for example, in physics, the notation is also beautiful, so for sure I also want that.

I can see, however, that for other people, these things I see attractive about using closer-to-textbook mathematical notation on input (what we call 2D-Math notation) are not relevant. All ok.

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

This command, odetest, was initially coded to test solutions returned by dsolve, always of the form y(x) = something (explicit solution) or the form f(x, y(x)) = 0 (implicit solution), or solutions entered by you of those forms, explicit or implicit. Your booksol is not of those forms, one could say it is an implicit solution but with a right-hand-side different from 0; that confused one internal routine.

This is now fixed and the fix distributed for everybody within the Maplesoft Physics Updates v.1348 and newer. If you don't install this Update, you can still test this non-standard-dsolve format of the solution using odetest((lhs - rhs)(booksol) = 0, [ode, ic]) to get [0, 0].

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

Hi,
When you indicate arbitraryconstants = subscripted, all the integration constants introduced by dsolve appear as c__n (and are equal to _Cn). So no, your solution do not come with "mixed looking constants" as you say. By design, there is no chance for that to happen. If you think otherwise, to make your point you'd need to show an example of the form dsolve(ODE) -> mixed looking integration constants - not what you are showing.

Regarding another part of your question, dsolve matches c__n to _Cn only for the integration constants that it introduces/uses, not for al possiblel n (infinitely many).

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

Download exercise.mw

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

Until a general fix is provided, maybe within a dot release, this problem is fixed, and the fix is available to everybody using Maple 2022 within the Maplesoft Physics updates. I see you are somehow new to Maple 2022. To install the latest version of these updates, please open Maple and just input Physics:-Version(latest). Then restart the system.

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

@nm
The assuming command knows about the options of each Maple command. Thus, it knows that right is an option of the limit command and will not place any assumption on it. That is the explanation also for what you @Carl Love ask.

Regarding the error interruption when you used quotes in 'right', indeed it is a sort of unexpected issue. A fix for this problem, available to everybody using Maple 2022, is distributed as usual within the Maplesoft Physics Updates, v.1340 or newer.

Finally, regarding this other comment by @Carl Love, I wrote assuming and can tell you there is no problem, at all, in passing something like: something assuming some_property, without specifying variables. That is one of the most valuable and practical ways of using assuming. I use it that way all the time. If you find something unexpected, post it, and if it is something to be corrected, it will be.

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

Input dsolve(q, singsol=false) and you will get only the general solution, all the singular ones are automatically not computed.

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

Download frontend_convertAlg.mw

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