AFAIK there has never been any technical reason why one cannot install multiple instances of the same major version number of Maple on the same machine.

I haven't yet tested it on Maple 2025, but I've done this previously on Linux with all versions (all update point-releases) from Maple 6 through to Maple 2024.  And for MS-Windows I did it for all versions (all update point-releases) from Maple 6 through to Maple 2020.

The main thing to do is to install them in their own separate folders/directories/locations.

For the Windows desktop you could give the various launcher icons different labels.

Naturally, it's necessary that your activation key will still work for each install. You could contact Tech Support, if the number of activations is "all done" for your key. They might be able to accomodate you, if it is.

@JP Howe There are a few alternatives to the palette, for entering expressions containing units.

One way to do that is to enter units within the Unit command, eg. Units(kg).

Or, if you'd still like to have your units nicely typeset in your 2D Input you could use command-completion. For example, if your type the first few part of that, say,
    Unit
you could then enter command-completion mode, and choose the unit constructor as one of the top items in the combo-box menu that pops up.

Several of the key things to know are absent in just your images of a session.

For one thing, we cannot deduce which version your using -- since you haven't set the "Product" field in your Question with the version number.

Also, we cannot know what code might have occurred before your pasted images.

And we don't know what packages your session might have loaded. And we don't know what values might have been assigned to the names you're using.

Also, we cannot tell whether you're using units properly. That is, "kg" appears in italics, so have you used merely the name kg rather than Unit(kg)? We cannot tell for sure.

You can upload and attach a .mw worksheet document, and inline either its content or just a download link, using the green up-arrow in the Mapleprimes Question editor's toolbar.

@sand15 I voted up.

What do you think about putting option remember on the ANS procedure; see the attachment.

Generic_2d_plot_sand15_ac.mw

You can see the timing effect. Repeated inputs values of the plotting variable occur if the plotting range and the numpoints choices are repeated.

@WD0HHU This site doesn't has that problem, for files with names containing special characters like & (ampersand).

@nm Sorry, I'm having trouble reproducing my success now. I may have gotten confused with the filenames I was using with attempts in different interfaces.

It's an unfortunate bug.

Here are a few ideas:

Just as a check, does it also fail to produce those expected gridlines in the commandline-interface's exported image file if you use another format like bmp or gif?

What if you use the command,
    Export( .... )
instead of,
    plottools:-exportplot

I wonder whether this problem is specific to Windows. It seems to work OK for me in the commandline-interface on Linux. Is there a possibility that you could use the new Windows Subsytem for Linux (WSL), a runtime supported as a layer on MS-Windows? Even if you don't want to run your whole complicated scripting processes (I know they are large and involved) in this way you might be able to just save the plots and a filename string to .m format and then run a short Maple script in the Linux that read in the .m file and ran the plot export.

@JP Howe You didn't answer all my queries, no. Are you using MS-Windows? And Maple 2025.2?

I don't have that point-release version on that OS, but perhaps someone else here might be able to check whether it works for them. 

It works for me.

What Maple version are you using?

Do you see the rest of those code lines having their expected effects? If yes, then how are you checking whether the LinearAlgebra package got loaded? If no, then what is the explicit location of the initialization file that you're using?

@nznz1987 Carl provided his code as plaintext, ie. 1D Maple Notation code It seems as if you might have copy&pasted it in as 2D Input.

@Rouben Rostamian  I mentioned it in my Reply's last paragraph above. The curves coming out of usual contourplot calls are each made from a collection of small curves (ie. many CURVES substructures within the PLOT structure).

Even though these many CURVES each have linestyle=dash applied to them, they are (usually, by default) each too short for the GUI to render them clearly enough for us to be able to see the dashed effect.

This granularity of how the CURVES are produced is related to the grid size with which the internals compute and construct it all. If you also pass, say, grid=[6,6] to contourplot then you can usually also see the linestyle's effect, because then these individual segments are longer. But then the resulting level-curve contour lines are too coarse and chunky.

plots:-contourplot(x^2-y^2, x=-1..1, y=-1..1,
                   grid=[6,6], linestyle=dash);

Sometimes one can programmatically meld together the CURVES substructures that pertain to a longer, single, rendered curve. But it's effort.

So (often) a possible alternative is to make separate implicitplot calls, for each contour value, and give those the linestyle.

@Rouben Rostamian  

The color can be changed after the fact by using plots:-display with overrideoption. The linestyle can also be changed after the fact using plots:-display.

It also makes sense to not include the background densityplot that Kitonum's labelling-contour-plot proc can do (since it'd be different for each of the OP's three cases, and after merging only one of them would be seen anyway...).

case_2_ac.mw

If the OP doesn't want those contour "labels" (because, say, when all three cases are merged it could look too crowded...) then an alternative might be to use a seq of implicitplot calls (since the apparent curves from contourplot are actually a large number of individual line segments and the linestyle=dash effect gets obscured by virtue of that). But perhaps the contour "labels" would look acceptable if done with the distinct colors.

@Math-dashti Put your followup queries on this here in this Question thread, not in a duplicate thread (which gets flagged as such and may be deleted).

Or , use the Branch button to link your highly related queries.

You've been asked that before.

@awass You made a comment, "Also, I am happy with eval(...,a=20) etc rather than parameters I though that was disparaged now."

I'll address that in the following attachment. But first some notes:

1) dharr's approach corresponds directly to Second way in my Answer. In fact they're nearly identical. The differences are minor:
   1a) he called dsolve twice, whereas I wrote a tiny proc so that I'd only have to type out the dsolve call details once -- and then I called that procedure twice.
    1b) He created an Array of 20 evenly spread x-values, using,
              seq(0..3.0, numelems=20)
           while I created one with 31 evenly spread x-values,
              seq(0..3, 0.1)

2) Using output=Array(...) may be more efficient than mapping the dsol returned by dsolve,numeric across a Vector/Array of x-values. It may be more efficient because dsolve can use already-computed values when integrating on to the next specified x-value. But when one maps the returned dsol "solution" across an Array, each specified x-value is used separately and internal computation may be repeated (depending on circumstances, possible garbage collection of previously computed intermediate results).

With 2) in mind, I gave my First way because I thought it was more convenient and legible. It has no extra indexing stuff to pick off the appropriate item&column from the list&Array returned. (See the [2,1][..,2] indexing syntax in both dharr's Answer and my Second way. I suspect that might be mysterious for some users.)

Now, here is a variant of the approach without output=Array(...). I suspect that this may be what you were recollecting, when you wrote "disparaged".

>  restart; >  with(plots): setoptions(size=[500,200],style=pointline,labels=[x,""]); >  interface(rtablesize=4):   >  de := diff(f(x),x,x) = -sin(a*x): >  Let's create an evenly spread collection of x-values. A := Array([seq(0..3,0.1)],datatype=float[8]); Calling dsolve,numeric on a DE that contains an unassigned/symbolic global name (as "parameter"). It doesn't work if the  output=Array(...) option is used. >  dsolve({de,f(0)=1,D(f)(0)=1}, numeric, output=A) Warning, The use of global variables in numerical ODE problems is deprecated, and will be removed in a future release. Use the 'parameters' argument instead (see ?dsolve,numeric,parameters) Error, (in dsolve/numeric) array output cannot be obtained for problems containing global variables The output=Array(...) option cannot be used with the parameters option. >  dsolve({de,f(0)=1,D(f)(0)=1}, numeric, parameters=['a'], output=A) Error, (in dsolve/numeric) array output cannot be obtained for problems with parameters We can invoke dsolve,numeric just once, for the DE with an unassigned global name "parameter" in it, if we don't use the parameters option and we don't use the output=Array(...) option. This use of global names in DE sent to dsolve,numeric is disparaged; it is deprecated. >  dsol := dsolve({de,f(0)=1,D(f)(0)=1},numeric,output=listprocedure): Y := eval(f(x),dsol): Warning, The use of global variables in numerical ODE problems is deprecated, and will be removed in a future release. Use the 'parameters' argument instead (see ?dsolve,numeric,parameters)   >  A := Array([seq(0..3,0.1)],datatype=float[8]): >  The following compute the 1D Arrays of y(x) values that correspond to the 1D Array of x-values. Note that this loop actually assigns values to the global name a.  We could also do it by actually explicitly assigning a numeric value to name a, and then doing , and then repeating that. for a in [7.0, 7.1] do   F[a] := Y~(A) end do; >  display(Array([   plot(A, F[7.1]-F[7.0], title=y[7.1](x)-y[7.0](x)),   plot(A, F[7.1]/~F[7.0], title=y[7.1](x)/y[7.0](x), color="Navy") ]));

Download de_V2.mw

@awass 

Using dsolve/numeric with parameters is not discouraged. Indeed, there is a dedicated and documented mechanism for doing it.

What is now deprecated is calling dsolve/numeric for IVPs that have unassigned global names in them (ie, parameters), and then invoking dsolve's returned solution procedures only after assigning numeric values to those names.

See my Reply below.