@salim-barzani It's not clear what you might be trying to say about conjugates.

I really do suggest that you try to understand how the code parts work. How else would you be able to tell that parts of some AI-generated code is trash? (I don't mean mmcdara's and dharr's code...)

@mmcdara Yes, I saw that too. And simplify doesn't reduce the contradiction, as well (in M2024.2 at least). I'll check M2025 and submit a report (against both solve and simplify).

@mmcdara In the member's Maple 2019 the conditions in that piecewise result from that solve call are awkward (and weird).

Download Q_solve_oof_M2019.mw

That first Error message in your worksheet (in magenta) is a URL that can take you to this webpage.

Not all (few) Error messages link to useful information, but this one does.

I had to tell it how to find my web-browser, the first time I clicked on such a link.

@emendes I don't think that you've explicitly clarified whether an entry in any given inner list/set has to have all its own member lists/sets have the same depth of nesting as each other. Ie, you haven't (as yet, explicitly, AFAICS) disallowed, say,
   [  [1, 2], [ [4,5], [[6,7],[a,b]] ] ]
or,
   [ [1, 2], [ [4,5], [[[[[6,7]]]]] ] ]
where it's unclear whether the "depth" rating of [ [4,5], [[6,7],[a,b]] ] ought to return as 2 or 3 (or error).

But perhaps you don't expect such a case. So far, that was my guess.

Or perhaps you mean to convey instead that you wanted the maximal nesting depth for the members of parent L.  So here's another guess for the depth (though I don't know always what you might mean by "flatten" in some examples),

Download some_list_set_stuff_2.mw

@emendes To start with, your claim, "After the first outer list, entries are either lists or sets." is not true of the examples you've shown. Some entries are integers.

Moreover, even if you complete your characterization to allow lists or sets or scalars(or integers), it could still not be specified whether the entries of any sublist list have to all be all-integers, or all-sets or all-lists, or all sets-or-lists, or possibly a mix. If a mix of integers and lists/sets, then it's not explicitly clear what you might mean by "flatten", and you haven't clarified that case through example -- or prevented it (so far) with words.

It may be that an natural interpretation is obvious to you (or others). But, based purely on what you have written, the problem is (literally, indeed) under-specified.

@emendes [edited code]

Download some_list_set_stuff.mw

I think that your problem is still under-specified.

@emendes That is to guard against the situation in which the name `coef` might have been assigned some value.

CG_ex2.mw

Defensive programming.

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