@student_md: For a general n x n matrix A, with unknown/generic entries, I guess there is no simple solution, at least not for large n.

@MrYouMath: As far as I can tell, you have treated Carl and me completely equal, giving us both a thumbs up. Without being able to speak on Carl's behalf, I believe that he is, as I am, completely satisfied with that.

@lemelinm: Now I see what you mean. You can do as follows:

expr := SumOverRepeatedIndices(
   g_[mu,nu]*d_[~mu](psi(X))*d_[~nu](psi(X))
):
# Doing some 'massaging' of the expression
simplify(expand(r*(r - 2*m)*eval(expr,{
   diff(psi(X),theta) = 0,   # No theta dependence
   diff(psi(X),phi)   = 0    # No phi dependence
})));

the output of which matches exactly the expression you give.

PS: I have actually never used the command SumOverRepeatedIndices before (which says a lot about how little, unfortunately, I have penetrated the Physics package), so it took me a little while to locate it in the help pages.

@Sannis: It is quite ok. Happy to hear that you have gotten the help you need. I am not quite satisfied with my answer/solution above, though, but that is my problem, of course.

@lemelinm: Thanks for the hbar-notation; I searched the help pages in vain. And, of course, you are absolutely right: The equation having to be zero makes the exponential unimportant, of course; that did not occur to me.

Perhaps the following will count as an answer:

expr := Simplify(
   dAlembertian(`ℏ`^2*exp(I/`ℏ`*psi(X)))
):
expr1 := `*`(op([2,2..3],expr));
expr2 := g_[mu,nu]*d_[~mu](psi(X))*d_[~nu](psi(X));
Simplify(expr1 - expr2);   # Check equality

Note that expr1 pulls out of expr the appropiate part.

PS: There is actually no need to perform this check, for the contravariant four-gradient is, by definition, the contraction of the metric with the covariant four-gradient.

@tomleslie: I agree. Using

e1New := (beta - 1)*subs(beta - 1 = 1,e1);

may certainly fail in producing what one would perhaps expect. It should be used only in conjunction with some subsequent boolean check,

evalb(simplify(e1New - e1) = 0);

say.

@taro: Now I see what you want. The solution by Joe Riel:

(beta - 1)*subs(beta - 1 = 1,e1);

is obviously the correct, and far superior, one.

@lemelinm: The D'Alembertian of the expression you have is given by

Simplify(dAlembertian(h^2*exp(I/h*psi(X))));

[Note that by h, I actually mean hbar. I cannot figure out how to input hbar. If you know how to do it in 1D input mode, then please let me know.]

For hbar going towards zero, the exponentials will oscillate wildly. That is a bit unsettling concerning the limit of the overall expression. But if it should in fact be unproblematic, then clearly the first term vanishes in the limit. Up to the exponential factor, the second term is almost the required result. I do not see how the exponential factor can possibly avoided.

@Bendesarts: I guess you mean the emacs editor. I have never used it, neither back in the university years, nor later. I guess that its learning curve was too steep for my sentiment.

Concerning jEdit: There is no addon needed. A new document with Maple highlighting (although perhaps not complete, but certainly sufficient, I think) may be simply created using 'New in Mode' under the File menu, followed by choosing 'maple' from a menu of possibilities.

@Bendesarts: That is good; there is no reason to really change anything there. I do, however, believe that it would be a good idea to migrate the whole thing to a text-file, using an external editor. In that way you can use tabulating indentation, etc., to render you large file visually much easier to read. All you need then, is to read the file into your main worksheet. If that is not enough, then afterwards you could try to break the code apart in chunks, and then reassembling it using read or with. But I guess that should wait.

A couple of years ago I migrated my own files in the same way. It was a bit hard work, but I have never regretted it. It is much easier to maintain these external text files, and as acer mentions, they are also less error prone than are Maple worksheets which are, behind the scene, littered with XML codes. I use jEdit, see http://www.jedit.org/, which someone here at Mapleprimes recommended.

@Bendesarts: That is good. Does your worksheet then have an outline analogous to the following example?

# Main package
A := module()
   option package;
   export B;
   # Subpackage
   B := module()
      option package;
      export C;
      C := (x) -> x^2;
   end module:
end module:
A:-B:-C(10);   # Test

the last line returning, of course, 100.

@Bendesarts: In line with acer below I believe that the best way forward is to break up your large worksheet into smaller text-files, using some external editor, which may then be read into your existing worksheet with the read statement.

For clarification: When you talk about a (sub)package, do you mean something created using the module ... end module construction, or what?

@tomleslie: I noted the same thing concerning H, and made the same guess concerning Ha.

What precisely do you mean by "group/ungroup all the lines inside a subpackage"? How have you written your code? In Maple itself, or in an external editor?

@Christopher2222: Thanks to you as well for your feedback. Interesting that you can narrow down the time of change. I agree, of course, with you that this is something Maplesoft should take care of as quickly as possible. Are they aware of the problem?, I ask myself.