I'd like to clarify some apects.

This is not a question of using 2D Math versus 1D Maple notation. Rather, it's a matter of using Clickable Math (like the right-click context menus) versus programming. In a previous Question the submitter has declared some preference for the clickable approach.

The original Question's document has a call to the smartplot command, (veiled) as the result of doing a context-menu action. Tom Leslie's Answer consists of handling the units with a programmatic approach.

Whether invoking smartplot, the new (2017) interactive plot-builder, or the older (Maplet's based) plots:-interactive command, there is a general weakness in the automatic handling of units in plotting.

What happens if (after re-executing the whole sheet, so as to get the various quantities assigned) you do the following:

1) Edit the lines with the problematic plot calls, and terminate them each a full colon. Then press Enter.
2) Edit those same lines again, removing the trailing colons (so that the plots are once more shown).

The idea is to remove the output from those lines, and then re-execute.

It's possible that some rendering qualities on the float tickmarks are suffering from "plot persistence". Temporary removal of plot output from a paragraph/rexecution-group can get rid of some persisting qualities.

@maple2015 It looks like there is a local minimum (of both real and imaginary parts) at omega=0. But the real part is not zero there, for your given expression, being something close to 0.09 or so AFAIKS.

It doesn't help that your expression looks like it has had evalf applied to it to early. That may be making further numerical and mixed symbolic/numeric computations more awkward. It might well be easier if you gave us the whole original computation, in which it might make things easier if 2*Pi and other constants and so forth were not turned into floats.

@Ramakrishnan What do you mean by "difficulties"?

Do you mean that it just doesn't work?

Or do you mean that the original display with the "->" arrow gets replaced by something like, say, proc(...) option operator, arrow; ... end proc when pasted in? That alone should not prevent it from functioning, and is just a 1D Notation/lprinting/formatting thing.

No, my example Does Not require you to load DocumentTools or Statistics or anything like that.

You've written two statements above: an assignment to eq21 of a collect call on eq20, and equation with q(x,s) on its LHS.

You didn't provide the value of eq20, so naturally we cannot re-execute that assignment statement properly.

Are you saying that equation was the output of executing the first statement, and that this is the "expression" you want further simplified? If so then something seems amiss because applying that very same kind of collect call to the given equation does further simplification of the coefficient in question.

simp_example.mw

Also, when you say that you want further simplification of just one "coefficient", does that mean that you want all other terms left untouched?

Altogether I find it difficult to see what you are asking for, and what your expressions are, and what you hope to achieve.

@mikemeson Why did you not try my suggestion? For your data it would simply be something like the following,

plots:-display(
  surfdata( Op1, 25..35, 25..35 ),
  surfdata( Op2,-25..-10, -25..-10 )
);

That shows the two surfaces, respectively above the two different x-y domains specified.

A minor point is that the collect command allows for an optional argument, to specify post-processing action on the coefficients. So it can be done in one step like so:

collect( q(x,s), [exp((lh-x)*sqrt(s+thetac)/sqrt(Dc)),
                  exp(sqrt(s)*(-lh+x)/sqrt(Dp)),
                  exp((-2*lh+x)*sqrt(s)/sqrt(Dp)),
                  exp(-sqrt(s)*x/sqrt(Dp))],
         simplify );

Also, mapping simplify to the result of the shorter call to collect could in general affect not just the coefficients but also all of the collected subterms (which might possibly not be wanted). That doesn't happen here, however.

For this example it also turns out that the subterms to collect are the only instances of function calls to exp in the expression. So for this particular example it can also be done with a little less copy&pasting, as:

collect( q(x,s),
         indets(q(x,s),specfunc(exp)),
         simplify );

@Ronan There are lots of text editors, and some will offer nice things like colorized syntax (...think keywords like if, then, else, do, etc).

I use a command line shell in Linux, with the `vi` editor.

If you're using MS-Windows the I wouldn't know what to suggest as best. You could start using `notepad` though, as a simple mouse-driven editor that comes with MS-Windows and has the usual menu bar items for File/Save/Edit/Help.

At the risk of repeating myself, I'll say that I've seen many corrupted .mw files over the years. But I can't recall ever seeing a stock text file editor corrupting a file. I consider my project source code to be worth the protection.

I really don't think that you should be trying to use Maple's `save` command to "export" a procedure as source to a plaintext file. 

Since Ronan seems to really want to define the module export Rtest by obtaining it from its own .mla archive (rather than straight from source), then here's how to do all the steps.

There a few things I'd like to stress.

The first is that this seems clumsy -- why get the body of  the procedure from .mla when one already has the source? I've enumerated above some good reasons why defining all of the module from source can be better.

The next thing is that you don't use the read command to obtain the stored procedure from its .mla archive -- that happens automatically after augmenting libname with the .mla location.

The next thing is that if you want the module export to function even when the procedure-only .mla archive is not in libname then you have to assign the value assigned to the global name to the export name when defining the module. That is, you want the module export to be a full copy of the actual procedure, and not just a reference to the global name. See the comment about using eval for this, in the module definition below.

And lastly, in general this methodology will not work for reading in a module rather than a procedure, in the hope of assigning it in full as an export/local submodule and then saving the parent module to its own separate .mla archive. It won't work for several kinds of module, including: some that have some kinds of ModuleLoad procedure, some that have locals which have not been accessed prior to re-saving, and so on. This is just another reason for which it's a lot better to stick to reading in the entire module, and its submodules, etc, in the same session -- preferably all from text files.

Download ronan_method3.mw

Which options of the command contourplot do you want to use/mimic? Is it related to coloring and shading?

@adel-00 Yes, I understood what you meant. My answer is that there is at least one other way to approximate or interpolate or fit the curve reasonably accuractely and easily.

What is the expression assigned to the name result?

@Gillee "stop watch experiments" relate to "wall clock" timing and the results from calling time[real](...) rather than calling time(...).

Your statement -- about the results from calling time(...) being incorrect because they don't match your stop watch experiments -- is wrong. You have clearly misunderstood my main point. Results from time(...) are the sum of all subthreads, including overhead, and Need Not correspond to wall clock time. If you want to compare something to your stop watch then make it the results from calling time[real](...).

I am supposing that you want a solution which is fully programatic, so that the actual plot portion has a precise size (matching that of others, say). Otherwise you could use the right-click context menu to set the plot "manipulator" and zoom and pan by hand (thus creating the extra space for the well-placed annotation).

It might be possible to set up an easy-to-use procedure to do that fully programatically using the
DocumentTools:-Layout:-InlinePlot command.

I'll try and do that when I get computer access, perhaps this evening.

The idea is to increase the (viewport/bounding box) while zooming-out (scaling) by a corresponding factor so as the keep the actual plot size fixed. Then the plot could be positioned within the box by offsets (pan). If I recall the DocumentTools stuff allows these bits to be programmed.

I'll let you know if it works well for me, unless someone else codes it up first.

update: It turns out that I was mistakenly thinking of the way that zoom and pan works for 3D plots. I don't see how the above could be used for 2D plots, in which even manual zoom and pan affects the axis view. The suggestion to annotate by using plots:-textplot (which can be used to insert typeset math as well as text) seems like it may be the only simple approach.

@Christopher2222 I was going to have a look tonight (for a FromInert/ToInert try).