@Rouben Rostamian  By setting Digits:= 15 and using dsolve options abserr= 1e-10 and relerr= 1e-10, I got the accuracy I wanted. I didn't need to fiddle with the events, nor could I figure how to do so. That help page is quite unhelpful, having about 10 times as many options as there are examples. So, combining the higher accuracy with your way of programmatically extracting the values, I am satisfied.

@Rouben Rostamian  I see two drawbacks to this approach:

1. Its default accuracy is much, much worse than the other "stock" methods, but I guess that I could figure out how to adjust that with the relerr option to dsolve(..., numeric).
2. As you've written it, there's no way to programmatically access the returned valued. Do you know a solution for that?

@Carl Love Since the u's only appear with phi applied to them on the right side of the defining equation, if phi is injective over any relevant domain, then without loss of generality (WLOG) we can assume that phi is the identity function. (And if phi isn't injective, then I think that the problem is ill posed.) So, phi is just obfuscation, and the notation can be simplified to

`&*`:= (u__1,u__2)-> ln(exp(u__1)+exp(u__2)) + Q(u__1 - u__2);

@sunit You should read the help page for algsubs (?algsubs). It provides numerous examples of some of the subtleties involved. It is easy to learn to recognize syntactic subunits, and once you can, there's no question that for them you should use eval (which understands mathematical subtleties) or subs (which intentionally ignores them) to make the substitutions. In particular, any name (as in a variable name) is always a syntactic subunit.

There are many commands for making substitutions. Here they are ordered by my approximation of their complexity (and I've probably forgotten a few). I'd generally recommend choosing the simplest one on the list that you know will get the job done.

subs
subs[eval]
eval
eval[recurse]
subsindets[flat]
subsindets
evalindets[flat]
evalindets
simplify(..., {...}) #aka "simplify with side relations" (see Kitonum's Answer)
algsubs
eliminate

If you have a question about factor, you should ask that as a separate Question.

Are you saying that you want to use Maple's (G)UI as an interactive front end for a Linux shell session with the two communicating both way via pipes? Or would it suffice to just use Maple as an editor to compose (and perhaps to analyze) a batch of shell commands that could be processed by Linux as a batch?

@sunit You're most welcome. I just added an explanation of why algsubs works and subs doesn't, which I hope will help you decide when to use which command. But don't get the idea that algsubs is better than subs or eval; algsubs is very complicated, expensive to use, and often fails.

@radaar My point was to challenge your unsubstantiated and generally negative attitude about DirectSearch applied to a black-box Ackley function. I suggest that you open your mind a little and investigate DirectSearch further. It can be applied just as well to a directly specified function or to a black-boxed one specifed by a surrogate. I don't know that it'll work for your function, but it's a very robust optimizer with a vast number of options that shouldn't be dismissed out of hand by a two-sentence comment. On the other hand, it's entirely possible that your problem is too large to be handled in any reasonable amount of time by this method.

Upon further thought, it's clear that your r^4*sin(6*theta)*sin(3*phi) isn't a proper change-of-variables factor because it's negative over some portions of your region of integration.

From your previous recent Questions, I know that you're working with an obscure coordinate transformation (you called it OPToroid). In order to integrate, you need to multiply the integrand by the absolute value of the determinant of the jacobian of the transformation^[*1]. That may be the purpose of your factor r^4*sin(6*theta)*sin(3*phi), but that's not clearly stated.

[*1] Does anyone here know a briefer, yet mathematically precise, way to say "multiply the integrand by the absolute value of the determinant of the jacobian of the transformation"? 

@radaar 

Would you please post a worksheet showing some minimal evidence (and it needn't be hard or conclusive evidence) of these two statements:

1. "Actually, direct search packages stopped working."
2. "I dont think direct search will work for black box functions."

Both statements are quite contrary to my experience.

@9009134 If you look at your expressions with lprint, you'll see that the function names are actually u__r, `u__φ`, and `u__θ` rather than u__r, u__phi, and u__theta. This is not really your fault. It has something to do with 2D input: I think getting the names from palettes. I'm not certain because I never use it (because it's total garbage that leads to errors like these).

@Nadeem_Malik My use of declare(U[]) rather than declare(u(x,t)) makes absolutely no difference! The important thing is that you use square brackets---not underscores---to input the derivatives. The way that things "appear" in your Maple doesn't matter. What matters is the keystrokes that you used while entering the expressions. Two different inputs may lead to outputs that appear identical (when prettyprinted, which is the default output format) but which in reality are different. That's why I suggested that you look at the output with lprint.

The underscore character is treated by Maple exactly like an alphabetic character (a, b, c, etc.). It has no other syntactic meaning, but you are using it as if it did. This is different from LaTeX, where the underscore is very significant syntactically.

To save a worksheet, use the File menu, just like any other desktop application.

To upload a worksheet to this website, use the green uparrow that appears on the toolbar of the editor of this website.

@Joe Riel 

Yes, elementwise operators (as opposed to elementwise function symbols) can be applied to multi-term expression sequences as if they were lists (of course, with the result being an expression sequence rather than a list). It's often useful (and more efficient) to not need to place and then to remove the list brackets, such as when the output becomes the input of a multi-argument function.

@Joe Riel Perhaps this is too clever, but it fits on one line, starting with the original equation, eqn:

`=`((1,-1)*~selectremove(has, (expand@(lhs-rhs))(eqn), diff));

Compositions of multi-argument functions are tricky.

@vv Yes, LOC and lambda are escaped locals. Like anything else, they'll be gc'd when there's nothing pointing to them. That they're escaped locals doesn't cause any special consideration wrt gc, nor should it. Did you have in mind an example where such behavior might be problematic? I think that upon closer examination, you'll see that it all works out.

None of this changes my Answer, except that I might possibly add a footnote:

• "For what it's worth, lambda in this situation is called an escaped local, which may sound like the name of some erroneous condition, but actually it's innocuous. Escaped locals can even be useful sometimes; they're closely related to module exports."