Is this the kind of thing that you're after?

Download acf_ex2.mw

It looks as if you might be encountering premature evaluation of the first argument you're passing to NonlinearFit.

You are passing,
   p__eng1(C__10, C__01, kappa, lambda)
which will evaluate with all its arguments as mere names without numeric values. That may cause the call to solve inside procedure r to return a list, which could be where those square-brackets are coming into it.

What might work instead is to prevent that evaluation until the parameters get actual numeric values. So you could instead try passing,
  'p__eng1'(C_10, C__01, kappa, lambda)
to delay the its evaluation.

It would be easier to test outselves if you supplied the actual data (file) which you are importing. (Possibly attached here as a .zip file, depending on its filename extension). It's also difficult to tell whether fsolve might get better speed than solve here, without the actual data.

First, if you want to use capital D as a variable at the top level like this you could issue,
   local D:
at the start of your worksheet. (Or use a different letter. The protected name D is the name of the differential operator and doing otherwise will run into issues.)

Also, fix your syntax and remove errant [...] as C_R suggests.

Thenm try using solve here instead of isolate, supplying assumptions if you have them.

Eg,

   solve(T4, rho) assuming 0 < 4*Co*D^2*theta

etc, instead of,

    isolate(T4,rho)

as one example.

Another example might be, say,

   solve(D2, rho) assuming 0 < delta*D

ps. Your problem is mainly your choice to try isolate which is not the right command here. It's not related to whether you use eval.

Download minimize_ex_2022.2.mw

ps. You may wish to subsequently unassign that environment variable, if you don't want it to affect later solve calls,
    _EnvExplicit := '_EnvExplicit':

pps. I will submit a bug report.

You can add,

   axis[2]=[location=high]

to you plot options, to get the effect of the tickmarks and label on the other/right/upper side of the vertical axis position on the right.

Or you could add,

   axis[2] = [location=low]

if you'd prefer the label/tickmarks to the left/lower of the vertical axis positioned on the left. (This combination happens to render similar to axes=frame.)

For the images above I also altered your size, just to make it all a bit smaller. In the following attachment the same effect is attained using your original size setting (so you can examine that, to see the automatic tickmark values actually generated).

axis_label_on_wrong_side_of_axis_ac.mw

Here is your original axis effect, that you did not want,

@Ronan In light of a few followup comments it seems that you already had a decent mechanism for adding spacing above or below the symbol, including multiple depths.

And it seems you also want to deal with another problem: that the name you wanted to show/render was already assigned a value.

Note. lowercase `typeset` does nothing to avoid an assigned name evaluating to its assigned value. Rather, that lowercase `typeset` serves mainly to allow you to mix math & text nicely, in plotting contexts.

But Typesetting:-Typeset can indeed turn a name (even if assigned) into a form that will not subsequently evaluate to a value assigned to that name.

So it seems to me that all you need is that Typeset along with "\n" newline characters. eg,

     typeset(Typeset(thename),"\n")

though naturally you can also have the newlines before/above, or multples.

Obscure stuff like that `mover` seem like quite unnecessary over-complication. And it needs more effort to shoehorn in a general expression. And it gets quite awkward (nested) for adding multiple vertical spacing above and below.

ps. single right click uneval quotes alone (to prevent evaluation of an assigned name, eg. 'gamma2') is not generally adequate here, since accidental full evaluation of the plot structure ruins it.

There are many errors in your "chelishkov_comparison" worksheet. Here are some adjutments,

chelishkov_comparison_ac.mw

I don't understand what you intend with your Matrix arithmetic in the other worksheet. It doesn't make sense to me.

@Earl I missed this before:

You have the assignment,

   libname := "C:\\Users\\earls\\OneDrive\\Documents\\Earl's documents":

which is not OK (unless you've made a full copy of the stock .mla Library archive in that location, eg maple.mla).

What you likely intended was something like,

  libname := "C:\\Users\\earls\\OneDrive\\Documents\\Earl's documents",libname:

which prepends your location to the stock location. That's what I mean by "augment libname" earlier.

As you had it originally, Maple is not able to find its own stock .mla Library files (unless you made the very usual move of actually copying them to that personal folder).

Try `ODEtools/odeadv`, for showstat or stopat.

The ConditionNumber command in the LinearAlgebra package computes or estimates the conditioning w.r.t. solving a linear system Ax=b where A is a Matrix.

You wrote,
    alias(eparm=CirclePramUHG);
but the submodule's export is named CircleParmUHG.

2024-06-29_use_alias_in_a_Sub_Package_ac.mw

nb. You don't have to load the package for your aliases to work.
2024-06-29_use_alias_in_a_Sub_Package_acc.mw

 (alias: love it, or leave it...)

Whether some expression merely contains 1 is not equivalent to whether it equals 1. You shouldn't be using something like that as your check.

You could utilize,
    ormap(`=`, [op(S[1])], 1)
or,
    ormap(is, [op(S[1])], 1)
depending on whether you want to recognize (as 1!) things which are mathemetically equal (a.e.) to 1 but not literally in the form of 1.  Eg, (x^2-1)/((x-1)*(x+1)).

Here I use ormap rather than `or`, so that it efficiently bails out as soon as any first instance is detected.

Download 2024-06-27_Q_check_inside_typeset_ac.mw

ps. You had a comment about an alternative you'd tried yet which didn't work ok. In principal that was actually much more sound, ie. a test for actual equivalence to 1. Your instinct to try it was good. The problem there was just that your op syntax was faulty. Instead of the faulty,
   op(S[1][i])
you could have had,
   op(i,S[1])
Then it would have worked as you intended.
   2024-06-27_Q_check_inside_typeset_acc.mw
Note however that it is wrapped in a check that is less efficient as well as slightly over-verbose.

[edit] That code would treat a FAIL (from ormap) as if it were a false. If you're ok with that (and I'd guess that is so) then you don't need a special guard against FAIL in that block. The if would handle a FAIL from ormap like a false. I would guess that you'd prefer not to accept a FAIL like a true here. Also, these don't throw an error.

if ormap(is,[false,false,FAIL,true]) then boo; else blech end if;
             boo

if ormap(is,[false,false,FAIL,false]) then boo; else blech end if;
            blech

Here are a few ways to get a list (of lists) instead of your
set (of lists).
 

Download convert_set_list.mw

Do you mean like this?

tagsCornersPlot :=textplot3d([seq([seq(cornerPoints[1..dim,i]),cornerPoints[1..dim,i]],i=1..4)],
                                               align = {above, right}, font = [Courier, bold, 20]);

You wrote, "Also I was not able to suppress the display of the odesteps on the terminal even though they do not display in worksheet, they still print in the terminal. But this is a side issue.

Why does Latex gives error in command line?"

It's not a side-issue; those two aspects are related. Your ODESteps call is returning NULL in the commandline interface case, and displaying the plaintext as a printing side-effect.

Try this instead, in the commandline.

   the_output:=Student:-ODEs:-ODESteps(ode,y(x),output=typeset):

That should force the same output as you get in the GUI, ie. a blob of typesetting stuff, which latex can deal with. You might also try output=print.

Not all these optional parameters to ODESteps are currently documented, but several of them can be figured out:

showstat(Student:-ODEs:-ODESteps,1);

Student:-ODEs:-ODESteps := proc(ODE0, yx0, {animated::truefalse := false, displaystyle::identical(columns,compact,linear,default) := default, output::identical(print,printf,typeset,canvas,script,list,record,`module`,
  nomodule,default,solution,maple,link) := default})

In the commandline interface the default for output seems to behave just like output=printf, while in the GUI the default seems more like output=print or output=typeset. (I'd guess that canvas might be for MapleLearn...)