If you only need to plot it then the tolerance for the numeric integration doesn't need to be super fine.

For some ostensbily complex expressions, simplify@evalc might produce en enormous new expression, or take a very long time. Since your integrand1 and integrand3 are quite short, maybe the numeric roundoff is acceptable.

Download heat_equation_on_finte_interval_ac2.mw

Here's something (no AI used),

Download dchange_ex_ac.mw

Hopefully the attached revision will shed some light on what effects "loading" a package can have on parsing subsequent code, due to rebinding of names.

Without the call to with(...) the names of the exports don't affect higher-level references to the name. (That kind of a central point of having exports of modules -- they can be accessed, but unless the package module is "loaded" the subsequent parsing of the name isn't affected.)

Notice also that this involves not so much what a name evaluates to at execution time, as to what binding is in effect for a name (ie. what it resolves to) at parse time.

See also the Help page for with, which discusses the binding effect.

InitCommon_acc.mw

ps. The OP's Question mentions checking for "existence", but I'm not sure what that is means. It's not clear to me whether your usage cases will involve checking whether a global name has been assigned, or been rebound, etc.

[edit] I ought to mention that I would never want to write "production quality" code that depended on what rebindings might have occurred earlier (via with, etc). That seems like coding fragility which would be risky to introduce unnecessarily.

I know the OP writes large, sophisticated packages, some of which might interact.

The above attachment is intended only as an illustration of how some mechanisms behave; it's not any recommendation. I was guessing as to what difficulties the OP might be encountering, eg. possibly redefinition during out of order reexecution or rereading of source.

None of my attachment belongs anywhere near quality code. I will try to find time to add a further note on how I think separate packages could interect and be well-coded, so that their definition could be robust wrt what might have occurred earlier in a session. (One guess by me as to what might be the motivating cases behind the Question...)

Since you've already assigned,

   u := A[0] + A[1]*R(xi) + B[1]/R(xi);

then what do you think it means to use the indexed names u[0], u[1] ?

Those names u[0] and u[1] will reference (index) into the expression assigned to name u. They are not distinct from u.

Did you intend, instead, to use wholly separate names like u__0 and u__1?

Download bashar_27_2.mw

This kind of programming mistake with mixing a symbol with its indexed-name form has been mentioned to you in a previous, recent Question.

The OP's attachment was last saved in Maple 2025. Using that version, an alternate can be obtained, with a common factor of sqrt(2) pulled out and cancelled.

Download Simplify_radical_02_ac.mw

That result attains without need of the assumptions on beta.

You can expand that, if you don't want the contents of the radical to be simplified.

When you have difficulties, don't suppress printing output of intermediate results using full colon statement terminators. Use semicolons and look at the intermediate results.

Also, look at the Help page of the command causing you difficulties. Then you could see that BarChart produce horizontal bars, and ColumnGraph produces vertical bars.

Download Bargraph_ac.mw

You cannot solve for only {omega, a[0], a[1], b[1]} because there are still constraints on the remaining names.

But (without getting into parametric solving, or eliminate, etc) is there a reason why you cannot pass the whole system to solve?

For example,  here is a list of different solutions. Each solution is one of the sets in the list sols. For each solution set, if a name does not appear then it is free to vary in that solution.

Download bashar27_1.mw

ps. I substituted a[1]=a__1, a[0]=a__0, and b[1]=b__1 because your system already contained the names a and b. You should not mix those with the indexed names.

It's new behaviour as of Maple 2024.

I will submit a bug report.

[edit] It seems to be related to the seq call at showstat(`plot/iplot2d`,178)
and floating-point error.

Another example, showing only one contour in M2026,

plots:-contourplot(y+sin(x),x=-2*Pi..2*Pi,y=-1..7,':-contours' = 2);

Your Equation Label (2) refers to the HTML entity `★` which you can check by lprint'ing it.

Notice the surrounding single left-ticks. Those a so-called name-quotes, in Maple. And `★` is a name (in Maple's technical sense). It's not an indexed name. It's a symbol (in Maple's technical sense). That's why type(..,symbol) returns true for it.

In Maple, symbols beginning with the ampersand symbol are treated as so-called neutral operators, and allow for calling with infix functional notation.

In Text mode the Maple GUI allows the glyph to be entered, without surrounding left-ticks, and in upright roman. If you paste that into a 2D Input area then you can accomplish the (mistaken) action of entering something like `★` but without the left-ticks. Notice that is rendered in upright roman in your Q1. The 2D parser tries to interpret it as a neutral operator, but finds an unexpected form (inlcuding unexpected special characters, without the surrounding left-ticks). It's not a valid symbol, in that case, since it has non-numeric characters but no left-ticks. Yet it looked as if it was going to be a neutral operator. Hence the error message, unknown operator. I don't know why the GUI allows one to enter that, without the left-quotes.

I don't know what the GUI is doing when it accepts name `⁑` in 2D Input mode but then seems to change it into something else. I've seen some actions where it hasn't done that, in which case I don't see that placeholder glyph, and also it then lprints as expected. But mostly it seems to change it into some other form (unicode?), and the output rendering and lprint then fail. I don't know why it does that, or what was the difference in the cases I didn't see that, for the same input character.

There were various problems, including (but not limited to) premature evaluation of your proc CC which gets called in expression T with symbolic names as arguments. And the plot syntax was wrong, mixing an expression (in S) with a range instead of the form S=range. There were more items to adjust. Please see the comments in the attachment.

Note there are significant regions in the S-mu-Z-Pr space for which there might not be roots found. It can take longer when it's trying to find roots that don't happen to exist.

Download Explore_Plot_Problem_ac.mw

ps. If you move one of these Sliders, then keep an eye on the GUI's status bar at its bottom. I advise waiting for it to go from Evaluating to Ready, before doing anything else (expecially moving any other Slider). Also, it gets slow for mu>0.5 or so...

When you expand your eqn1 the lhs's of the Eval calls get put into {} braces. That is,
   Eval(..., x__1=L__1)
becomes,
   Eval(..., {x__1=L__1})
and so on.

That makes them not match the Eval call in the lhs of bc1., which lacks those braces.

You could programmatically change all the Eval calls into this form, or you could write it that way if they're all entered directly by you. I show both ways, below. I used Maple 2022, as you do.

Download question527_ac.mw

ps. I don't understand the construction D[1]*Eval(...) in your bc1, but that's not part of your original ly reported difficulty.

For your part 1), you could look at this old thread, which covers that aspect pretty thoroughly. Carl Love gave a general bi-directional procedure, and I gave the following for a definite integral like Int(Sum(...)).

Download GFY_1.mw

That's a question that's been asked several times before, and there have been a variety of ways to go about it (depending on how general one might want it, etc). If you have sum or int instead of inert Sum or Int then it's trivial to replace replace those up front, or utilize op(0,..) in the code and modify the types, etc.

For your part 2), it depends on what you're willing to accept for incidental transformation of g(t) and f(x). The literal example,

    Int(g(t)*f(x),x=a..b)

can be handled directly by either expand, simplify, or even IntegrationTools:-Expand.

But what if you had something like, say,

    Int((1-cos(t)^2)*(1-sin(2*x)^2), x=a..b)

Those commands could alter the subexpressions g(t) and f(x). Using Maple 2022 (as your attachment used),

Download int_ex03.mw

So for part 2), what would you need, more generally? That requirement might affect what answer could serve.

You could put,

   $include "NODEXML.mm"

into some parent text file, and read that instead (or $include it from something else that is read, etc).

But you have to trigger the $include directives with some other mechanism instance. It could be read. Or you could use a shell call to the TTY/CLI `maple` script with that parent text file fed in as input.

The point is that you need some parent action that is not an $include directive.

For your Maple 2015 you could adjust the actual procedure used by the command plots:-sparsematrixplot.

Download spmp_2015_ac.mw

For Maple 2024 and later the alternate command plots:-matrixplot offers its dimension and gap options, and as of Maple 2025 it offers a sparse option.

Download spmp_2026_ac.mw

In that example I forced only a single color, so as to focus on comparison of the gap with the sparsematrix command. But the default is actually a range/variety of colors,

In recent Maple versions the plots:-matrixplot command can also do custom coloring, including accepting the colorscheme option. Eg,

Download spmp2_2026_ac.mw

When you call,

    plot([h(7.7,x),x=0..30]);

the evaluation of h(7.7,x) happens before the plot procedure receive any arguments, and before the symbol x takes on any numeric values. Hence, you are seeing the same error message that you would if you executed,

    h(7.7,x)

alone.

You could try,

    plot([ 'h(7.7,x)[1]', 'h(7.7,x)[2]', x=0..30 ]);

or,

    plot([ x->h(7.7,x)[1], x->h(7.7,x)[2], 0..30 ]);

If that works, but seems slower than you expect, then let us know as there may be some memoization adjustment possible, to avoid duplication of computation.  (Eg, procedure h might be given option remember; or option remember, system; etc).