@AHSAN Earlier, you wrote that fixing the wrong plots (that didn't agree with thd originals) would be the last correction.

You could read the error message in your new code (about wrong number of BCs), and fix that situation.

@AHSAN

Don't reference any individual component of a dsolve/numeric solution (at a point) by ordinal position. For example, don't do these (which I've taken from your followup code):

   u_vals[i] := rhs(sol[3]):
   theta_vals[i] := rhs(sol[6]):
   phi_vals[i] := rhs(sol[7]):

Doing it that way is a mistake, and unfortunately you've found that out the hard way. It's dubious because it's error prone (too easy to muddle up the positions), and it's also dangerous because if you merely change the names of some dependent variables (even if you do it consistently, throughout!), or add additional dependent variables then the ordering in the solution can change, and make your code and results invalid.

Do it like this, instead,

   u_vals[i] := eval(diff(psi(y),y),sol);
   theta_vals[i] := eval(theta(y),sol);
   phi_vals[i] := eval(phi(y),sol);

Please check the plots, my use of the particular names, etc, in this revision,
   Numeric_help_ac_next_ac.mw

Basically, using the poor `rhs`-indexed approach, your code was accessing the wrong entries in the numeric solution. That's why your final plots didn't agree; their data matched the wrong entries.

ps. You can find code by several well known and long-standing Maple power-users which use the poor approach in their dsolve/numeric work. Don't access your solve solution's values that way either. Don't let others' doing it beguile you into doing it...

@Andiguys 

For Case 2 your code does,

   sols_1  := [solve([diff(lag_1, Pc), H], {Pc, lambda__1, lambda__2})]:

But perhaps you meant instead to use H_1 there, instead of H. That'd agree with your convention for names of the other key items. You may have overlooked changing this one. Ie,

    sols_1  := [solve([diff(lag_1, Pc), H_1], {Pc, lambda__1, lambda__2})]:

If you don't, then the Pc components of the solve results could indeed come out the same as for Case 1 which uses H.

Making that change makes the Pc formula & values come out different for Case 2 than Case 1. And the revised Case 2 plot appears to match your expected plot attachment.
 Q_N1_mmcdara_ac.mw

@AHSAN Your original attempt had,

bcs := [  psi(-1 - x^2/2) = 1,
               psi(1 + x^2/2) = -k,
               D(psi)(1 + x^2/2) = 2*H,
               D(psi)(-1 - x^2/2) = 0 ]:

But the added details in your followup Reply now reveal that you had those conditions mixed up.

If you change the BCs to adhere to your followup comments then the plot of u(y)=D(psi)(y) then agrees to your requirement of u(-1)=1.

Using the switched values,

bcs := [ psi(-1 - x^2/2) = 0,
              psi(1 + x^2/2) = 2*H,
              D(psi)(-1 - x^2/2) = 1,
              D(psi)(1 + x^2/2) = -k ]:

Numeric_help_ac.mw
 

Is there a specific reason for (repeatedly) using implicitplot3d, which is quite inefficient in time and memory?

@Rouben Rostamian  With that assumption, it can get there directly.

Download mw_acc.mw

@Christopher2222 Yes, the name font is an option of the plot command, but recall that instead you're trying to leverage options of exports of the Typesetting package (specifically, mtext).

Those allow a mix of subsets of some MathML stuff. They're not documented for general use, so some experimentation is needed.

For example, mathvariant=bold can also be used here.

Download ts_stuff_03.mw

ps. Option 'mathbackground' mostly works in the GUI, but obscures the text when exported to an image file.

Thanks for a great read and links, John.

My favorite bit, "...everyone's favorite noncommutative ring is the ring of n × n matrices".

@Christopher2222  Why not post your attempts, in a .mw file?

I don't really understand how you're operating. You used font before, but it was not the valid option name. Now you're trying other option names such as style or fontstyle, that don't seem right. I know that this is not all documented. But how are you cooking up these wrong option names!?

Download ts_stuff_01.mw

Those would be automatically converted by the Eigenvalues or Eigenvectors commands.

@Christopher2222 

I changed font to fontfamily, to get an actual change in the font used. (I don't see your original `font`=... argument having an effect.)

@GFY Sorry if I didn't explain before. And I wasn't sure which case you were interested in, ie. whether the first argument to your kk calls would always be an integer. I suppose I guessed wrongly.

Note the following difference. The middle example behaves the same as the last example. You can choose the first, if that's what you'd prefer in general.

Download prec_q.mw

Please don't post wholly separate new Question threads on this topic of replacing all instances like,

     diff(G(xi), xi)/G(xi)

inside an expression or differential equation.

You can use algsubs (which member nm has done here), or you can use the simplify command with so-called side-relations, eg,

    simplify(eq2, { diff(G(xi), xi)/G(xi) = w(xi) } );

If you have other equations and you want to do the same kind of thing then please show them here (or use the Branch button at the bottom of this original Question, to start a linked thread).

Wholly duplicate Question threads on this same topic will be flagged as such and may be deleted.

@dharr I agree that would make sense, at least in principle.

I don't recall why/when the distinction first arose for the GUI's printing of an assignment statement (with a plot) versus printing of a mere expression output. Note that it can also occur for "large" 2D plots, such as come out of implicitplot and (perhaps) filled contout plots or density plots.

I have a hazy recollection that I might first have noticed the elided output message when the GUI got the ability to render "thumbnails" of plots when printing an expression sequence that happened to contain at least one plot. But I could be misremembering -- that was quite some time ago.

@dharr Calling display on this single plot structure doesn't do anything of importance to it; it's not the key thing here. In other words, there's not a significant difference between this plot and the plots:-display of this plot; both are just Library/kernel-side constructions. It's not as if storing either of them is storing something printed, etc...

The key thing here is that the result is that in your second line the plot structure is being printed as output, without being part of an assignment statement, which makes the GUI actually render it. (The GUI is simply confused about what kind of large thing it should be allowed to render, on the RHS of output of an assignment statement. It has some special case code for small-enough plots.)

The fact that the second line is a call to plots:-display is not what make the structure actually get rendered. (Ie. the OP's supposition about that was off the mark.)

Whether this is coming from a display call or not, the separate statement that caused it to be printed as simple output is what makes it render.