@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.

@awass Did you see that,

   F(7.0), F(7.1), G(7.0), G(7.1)

return 1D Arrays, whose entries are the numerically solved values y(x) corresponding to the x-values in 1D Array A. (But, for the different parameter values a=7.0 and a=7.1.)

You can always wrap those 1D Arrays in a call to Vector, if you'd much prefer that.

The whole point of the code in my Answer (just as in dharr's) is to compute (for an arbitrary parameter value) a 1D Array of y(x) values that correspond to a forced 1D Array of x-values. We both uses an even spread of x-values.

Otherwise, I don't see what you're requesting.

@sand15 The OP stated that TM1,TM2,TM3 are all positive.

But when Pn=0.2, say, they are all negative for all w=0..1.

Shouldn't the conditions that they are all positive further restrict the regions in your plot?

(...using an extra quadratic, etc, if you are doing it algebraically.).

@AHSAN I cannot say anything about your formula, where you have,

     # Evaluate skin friction at a specific point

etc. How would anyone else know what you mean by your formula, or whether your formula is correct?

You can adjust the 3D plot by zooming in and panning it, in the inlined plotting window. You can do that in the usual way, ie. right-click on the 3D plot, and in the popup menu go down to the "Manipulator" item and toggle it to "Zoom In", or "Pan", end then use the mouse to zoom/pan. Only the actual plot will zoom&pan, so its size&position relative to the color-bar and title can be thusly controlled.

The GUI has its own notion of how large the plot should be, at first, and it depends on the size of the title as well as the presence of the colorbar, and it also depends on the GUI's decision to allow you to rotate the plot without the axes going out-of-view. You can adjust it to your taste, by zooming in/out and panning.

note: zoom effects don't always get retained when the sheet is closed/reopened.
3D_shadow_at_the_base_Help_alt_ac.mw

See the plot3d option axes and axis for choices of the axes-style and location (high, low, etc). Those gray gridlines aren't available with a dedicated option for 3D plots, but you can mimic them easily by adding lines at the edges of your plot's view. You can do that. See also this old posting (or others like it).

You should carefully read the documentation pages relating to the commands and functionality about which you ask.