@Christopher2222 No, that does not always work (partially for the reasons I gave above).

I just tried it in Maple 2020, and it failed the very first time, in a fresh Worksheet. Sometimes it works, and sometimes it does not.

You did not test your suggestion carefully enough. The order in which the PROJECTION and ORIENTATION substructures appear in the result can vary, even with your suggested use of plots:-display.

I got it to pass/fail by using execution-line-by-line-Enter versus !!! from the menubar. I got it to pass/fail according to what went on earlier in the session. (The order generated by the stock commands seem to be session dependent.)

@Melvin Brown Ahh, perhsps you would like to have the saved image files be used as the `background` of the very plot on which you click. Yes, you can do that with a single Plot Component. You could also do it with Explore markers, I think.

I'll try to cook up an illustrative example.

@Melvin Brown 

As Valerie has described, you can utilize Embedded Components for this.

Its still not 100% clear to me whether your PDE solutions are previously computed as plots (in the same Maple session) or as saved external image files.

You can have one Plot Component with some "action" code that discerns where you clicked (or the nearest point on a curve to the click point, etc). So then you have, programmatically, [xi,S(xi)].

You can have another Embedded Component for displaying the assciated PDE solutions. If the PDE solutions are actual Maple plots in the session (previously computed, or computed on the fly) then you could utilize a second Plot Component to show them. If the PDE solutions are external image files then you could utilize a Label Component to render them.

The "action" code of the first Plot Component could also programmatically put the associated PDE solution into the second component (whichever was suitable).

It's difficult to provide fuller details without having the actual full example at hand.

What do you mean by, "opens up a graphical file which is parameterised by (xi, S(xi))"?

Do you mean that clicking on/near the point (xi,S(xi)) in one plot would cause another plot to be constructed (and possibly displayed either beside or in lieu of the original)? That is quite straightforward to do, using Plot Components.

Of by "file" did you really mean that you already have some premade graphical format files (.jpg, etc, on your machine), and that that you want the click action to somehow open on of those somehow?

Or perhaps you want some combination of those? Please explain.

@schapplm Yes! Very good. This is the main point that I put in my Answer (composed while you were submitting your Comment). Avoid naming conflicts up front, rather than trying to manage them by kludges.

@schapplm I believe that you'll find that your workaround simplify3 does not work. Try it with an expression within Matrix v, such as was assigned to your earlier T. Ie. the l1,l2 within v(1) will get evaluated.  You could call simplify2(v[1,1]) instead.

Could I check whether the following makes sense to you?

''Pi'';                                                                           
                  'Pi'

%;                                                                                
                   Pi

And have you read the Help page for Topic ditto ?

(One of points is: are you aware that using % causes an evaluation?)

@Scot Gould Both int(...,numeric) and int(...,x=floatrange) are themselves going to call evalf(Int(...)) but with extra overhead to do the dispatch.

BTW, if your timing comparison of 10000 repeats didn't utilize forget between calls (or construct distinct examples) then memoization is likely skewing your results. There are remember tables under 'evalf/int` etc. So, in your comparison the extra overhead of those two int approaches might be (unintentionally, artificially) relatively high.

@Carl Love Actually, the errant line in the image is,

  G:=GT:DrawGraph(Graph(M1));

where G gets assigned GT and not the generated plot.

But, sure, DrawGraph and a resulting plot are out of place there, regardless. He likely wants G from Graph(M1).

@emendes Amusingly, the simplistic approach of doing a table lookup on all entries seems to perform relatively very well. That was the second approach in my Answer. But it doesn't account for the cost of programmatically constructing the lookup tables. 

If the programmatic construction of the lookup tables -- from details/provisions which you have not yet shared with us -- could be done quickly then that might a real contender.

It's also possible that the lookup details might not need to be explicitly put into new tables -- they might be present in some other form elsewhere in your parent code, which we have not yet seen. That could affect the performance of any solution to this subtask.

There is a theme on Mapleprimes, that goes like, "Thanks for the answer, but my actual problem is as follows..."

@Carl Love If the subsindets typecheck is specindex(A) then is there really a need to utilize op(0,a) in the replacement procedure? Wouldn't just literal A work, and be a little leaner?

Also, if everything within input list varA is of type specindex(A) then the outer procedure T could be removed, since it always applies. (The end result of such changes would then be almost identical to the version I'd given in my Answer, fwiw.) I realize that you, Carl, are fully aware of all this -- I state it for the benefit of the OP, because I'd mentioned that some efficiencies depend on aspects such as whether the input list is known to have all entries be indexed references to the same basename, etc. I don't know how much overhead he'll need to pare off.

@emendes I see. I was not thinking that "thousands" is a very large amount. And there is the cost of building T1 and T2 programmatically for every case, the provisions of which are not yet shown here.

Who knows, your choices might include a middle ground of more easily understood code that scales modestly well.

You might find it worthwhile to benchmark and compare your choices (although ideally the cost of construction of T1,T2 should be included in that, eventually).

It is even possible that -- especially given foreknowledge that the structure of the lists is of a special kind, ie. all entries are a known name(s), indexed by integers -- a simpler approach performs relatively well.

Fyi (though comparison using a single small example is fraught with difficulties, hence the repeats) some simpler approaches may perform comparitively well. For example the two versions I've shown above seem to compare well against the first two that Carl's Answer shows. But note that they are all pretty fast, and all exclude construction code for the lookup tables. It's getting tricky since the cost of determining whether a table lookup should be done is competing with cost of the simplistic approach of merely doing all as table lookups. It's possible that there are other subtle tweaks possible, eg. something faster than using `assigned`, etc.  comp2.mw

@Kitonum This does not solve the problem in Maple 2017. It does take considerably longer time to compute, though.

@tomleslie Sorry, but I'm afraid that you are mistaken. The nicer edge in your plot is due to the adaptmesh functionality new in Maple 2020 (in which your worksheet was saved).

The OP's Maple 2017 would not get that same nice edge (tight to height zero at the midpoint) using your grid=[100,100] suggestion. So it does not solve the problem.

Even with grid=[200,200] the surface edge is right up along the domain boundary but is still quite far from height zero at the midpoint. And it takes considerably longer to compute. Increasing the grid option alone is not a practical solution to this problem.

As a minor point (because the scope of the assuming was discussed), one has a choice of several one-liners, including:

(combine@simplify@[solve])(1/2*m*v^2=1/2*F*x,v) assuming positive;

combine(simplify([solve(1/2*m*v^2=1/2*F*x,v)])) assuming positive;