Good catch DarkMath; it is fixed and the fix distributed to everybody using Maple 2020 as usual, within the latest Maplesoft Physics Updates.

Two additional comments:

1. The syntax simplify(expr, assume = [some_assumptions_here]) gets internally transformed into simplify(expr) assuming some_assumptions_here. So what counts is assuming, not assume. 
2. All of Physics, DifferentialGeometry, VectorCalculus, and some others, all packages more modern than the old assume command, require Physics:-Assume to work properly.

Why? Because the old assume redefines the assumed variables. Say A is that variable, then before calling assume it is one object, and after calling assume it is another one (you can check the addressof of the variable before and after calling assume to see this problem). Hence, for example, it suffices for you to assume on a Cartesian coordinate for it stop being that Cartesian coordinate.

So, while Carl is correct in "workaround: make assuming use the old assume", if you are working with these more modern packages like Physics or DifferentialGeometry, Carl's workaround is not recommended in general. (Reporting the problem, on the other hand, like you have done now, is excellent: we notice and it gets fixed.)

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

Check the help page. ?Physics:-Setup, option realobjects. Alternatively you can use Physics:-Assume. Both indicate to the system that something is real. Still, while simplify and other commands use that information more and more, some parts of the library or their subroutines were originally written for the complex domain and may not take the 'real' value of the objects into account.

In this case and in general It would help if you post the specific example you have in mind.

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

In your PDE: replace occurrences of u  by u(x, t). Then do not assign x and t to algebraic expressions as you do, because that makes things like diff(u(x,t),x) becomes wrong Maple syntax. Next input

ii := PDEtools:-Infinitesimals(PDE)

to get a sequence of infinitesimals. Then

PDEtools:-InvariantTransformation([ii], u(x,t))

That will give you the transformations that leave your PDE invariant; you will find that the one two times previous to the last one is closer to the form of the transformation you are looking for.

Finally, try

map(PDEtools:-SimilarityTransformation, [ii], u(x, t))

and you will see the more traditional similarity transformations for the given infintesimals.

In general, take a look at the help pages listed a Symmetry Commands under ?PDEtools. You realize there are more direct ways to achieve the results you mentioned, but if you prefer to go a more manual approach, produce your HINT for the infinitesimals, and send it to the PDEtools:-Infinitesimals command (see its hint option), or likewise send your hint to SymmetryTest and of course the symmetry will not cancel the symmetry PDE equations, but the command will show you what remains, and you can solve that for the variables you want (k alpha and beta in your worksheet)/

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

In the upcoming version of Maple, all maple.sty LaTeX macros that resemble an existing non-Maple LaTeX macro are, conventionally, written using the LaTeX macro name preceded by 'm'. So \moverset, \muderset, etc.

Maintaining a single copy of the code that works in both Maple 2020 as Latex, with e.g. \Mapleoverset, and the upcoming Maple 2021 as latex with \moverset, is prone to these situations you noticed; the code mapping things between releases missed \munderset -> Mapleunderset. Some people prefer to not advance this code in the Physics Updates. I think otherwise, put it there, everybody benefits from it, and we all move forward together getting feedback right away. And when you find these issues just report them so that they get fixed.

To summarize, this issue is fixed for everybody using Maple 2020 by installing the Maplesoft Physics Updates v.913 or higher.

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

A fix for this, available to everybody using Maple 2020, is within the Maplesoft Physics Updates v. 913.

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

These are all fixed and the fix available to everybody having Maple 2020 by installing the Maplesoft Physics Updates v.911 or newer.

Download latex_examples_(reviewed).mw

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

Hi

I'm giving (zoom ...) a Physics course that finishes this week, and able to adjust things in the Physics Updates mostly in connection with that course only. I gave a quick look at the LaTeX code now and understand this problem above is fixed in the Updates already there v.907. I will give a look at the other ones you are mentioning first thing after this course, probably on Monday 18, perhaps already before Friday.

ADDED NOTE JAN/17: All the above Mapleprimes links reporting Latex issues are fixed and the fixes distributed to everybody using Maple 2020 within the Maplesoft Physics Updates v.913 and newer.

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

The error message tells the problem; in one spot, after normalization, a denominator became 0. That should not interrupt the flow, though. The issue is fixed, and the fix is distributed to everybody as usual within the latest Maplesoft Physics Updates.

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

Hi

This is indeed not correct; the code fell into a mini-trap. In your example, y(x) is a factor, so there is a solution y(x) = 0 to this problem, to which would correspond F = 0 and G = 0 and there you are: a "dAlembert ODE". However, naturally not: for F = G = 0, this is not an ODE since y' disappears. Anyway, it is fixed and the fix distributed to everybody as usual within the latest Maplesoft Physics Updates.

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

Yes, there are interface changes among several other improvements in the (now also interactive) line-breaking (option breaklines), and in connection with the upcoming release of Maple 2021, where this command is called latex (replaces entirely the old one), not Latex anymore. The problem you noticed is fixed and the fix is distributed to everybody within the Maplesoft Physics Updates v.900 and newer.

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

@nm 

The infinite loop is in `series/tanh` (input tracelast after that error message and you see it). @Preben Alsholm, generally speaking, RootOf's don't mean 'wrong' or the like (If that were the case, I would not use them). RooOf is an essential piece of computer algebra. You know, only a tiny and minuscule number of expressions have an algebraic inverse that can be expressed with so few mathematical functions. That is on the way of changing with more general functions, like the Heun, Appell and etc. but we are still far away from that. So either you use RootOf, or you can do very little.

Passing the useInt option, you dodge this issue in series/tanh and get the solution to this problem.

PS: I won't be participating in Mapleprimes till Jan/15. I wish you all happy holidays.

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

There was a place where the estimated degree appeared as a fraction, which is not a problem for add, seq or mul, but the type checking of the input was too stringent. That is now fixed and the fix distributed to everybody using Maple 2020 within the Maplesoft Physics Updates v.896 and newer.

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

The indices introduced in a product of two covariant derivatives, at the time of performing the 'convert to g_' operation, collided - they should have not. That is now fixed and the fix distributed to everybody using Maple 2020 within the Maplesoft Physics Updates v.896 and newer.

PS: one more adjustment; this is resolved in v.897.

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

There was an issue, not related to ':-executeprintroutines' (the design is indeed to execute print routines, and you defined several) but related to the unexpected way you defined these routines, where, e.g. `print/_C` exists, but it is not a procedure. Keep in mind that, for the print routine's extension mechanism to work, `print/_C` needs to be a procedure, not anything else (see ?print). Anyway, a fix for that unexpected situation is distributed in the Maplesoft Physics Updates v.894.

By the way: what you tried to achieve is achievable directly using alias - I mentioned this in a previous Mapleprimes post, here is your example:

In this example, the difference with the old-latex is that the new one respects (takes into account) any alias you define.

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

I didn't peak at what is going on deeper, but this is what hangs in Maple 2020, not in previous releases:

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