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

@Jean-Michel Yes, the subscripts are displayed slightly differently (upright Ronan, versus italic) to provide a visual cue.

It's meant to help perceive what was utilized. Sometimes people use both together, accidentally, while thinking that they're all the same one.

@Jean-Michel After you assign the same expression to both names then your check return true because it's comparing the same assigned values rather than the names to which they're assigned.

@AHSAN Did you try my followup, with a code adjustment for the color-bar's dimensions? I used Maple 2024.2 there, but I'm hoping the effect is the same in your Maple 2025.

Or is your PNG immediately above from my original Answer's code?

@sand15 In my example above I showed colored vertical axes alongside black axis-labels, using a typesetting construction (of which you're already familiar). A similar effect could also be done for the tickmarks, as a different color from the axis-bar.

I don't know of a way to get a linestyle or transparence for the axis-bars, except by faking it with a dedicated line (and supressing the axis proper).

@AHSAN Of course, you could simply get rid of the color-bar altogether, by specifiying colorbar=false instead, in the call to contourplot3d.

But I believe that you could also adjust the original by shortening the color-bar in the substructure, after construction. Eg,

Download 3D_shadow_at_the_base_Help_acc.mw

@sand15 That too is nice and visually easy to understand.

[edit: it's more complicated to do, though, and requires adjustment for other data.]