It works if one specifies the function, eg. as y(x).

(That error message is attempting to describe an ambiguity, otherwise)

dsolve_exx.mw

The following takes about 1sec on my machine,

map(u->fsolve(unapply('evalf[15]'(u),T)),
    subsindets((rhs-lhs)~(eval(eqList,t=T)),
               specfunc(Int),
               uu->Int(op(uu),method=_d01ajc,digits=15)));

  [-4.000000000, -3.139954398, -2.113700371, -1.528831968, 
   -1.048408886, -0.7066382663, -0.4795776807, -0.3151696062, 
   -0.1824325597, -0.06254879140, 0.08914597087, 0.3686891818, 
   1.504692983, 2.115525214, 2.461195982, 2.720883279, 
   2.962135688, 3.213074710, 3.598125622, 5.163493045, 
   6.560014160, 6.814134444, 6.668244819, 6.405779566, 
   6.193526060, 6.022014505, 5.954332725, 6.067614012,
   6.326776518]

The term "student portal" is quite often used to refer to the following documentation, which is available both online as well as (offline) in the Maple GUI's own Help system:  Maple Portal
(nb. In the actual Maple GUI you can issue ?portal or search for the term portal in the Help browser.)

A slightly higher link is this Student Help Center link.

There is also the Teacher Resource link, and the online Training link.

And all of those can be accessed from Maplesoft's main webpage, under the Support and Resources tab at the top.

You can do,

    rtable_eval(M)

That command was invented for dealing with this kind of situation.

The behavior you showed relates to a full eval not making a copy of an rtable, which relates to the (good) design of not having the mutable rtable structures (Matrix,Vector,Array) get passed as copies when they're arguments in procedure calls. (This allows for in-place sematics for rtables, in procedure calls.)

Can you not just assign copy(T) to some other name, and then act in-place on that (in the usual way) by assigning to indexed entries?

You should be able to run this in Maple 2024.1 (or Maple 2023.2, etc). But not Maple 2024.0 which had a bug, now fixed.

I created a procedure which generates a static plot for any values of those parameters (and tfinal the end-point for t). Then I show how it can be used with Explore, or plots:-animate letting the tfinal value change. [This is a natural way to proceed; I see now that Carl has done much the same thing.] I also allow extra arguments to the procedure be passed along into the odeplot call (for which I too collapsed your seq into a single call).

You could also add the plotting command view option to the calls to G, if you'd prefer. Eg,
   view=[0..7, -10..2]
etc.

explore_odeplot_2.mw

Adjust other options as wanted.

[edit] It is interesting; when I first posted this Answer it was the only one, but now Carl's appears above it -- even with no votes yet for either. Perhaps the system got confused by very close posting times. (But I've also seem some other curious new behavior by this site.)

Consider the situation where the name e has been assigned a value, at the level at which you are making those calls.

For example, after e:=37 has been executed.

Now m:-e will still access that export of your given module. But m[e] will not, since that evaluates to a reference to m[37]. You could use m['e'] however.

And it could get even more complicated inside some procedure which had e as a parameter. Then m['e'] might not access that export of m, while m[':-e'] could work ok.

So, if two decent choices are m:-e and m[':-e'], which is easier to type and use? For me, it's the first of those two.

The different results you see are because in the case of x (instead of 2) there is ambiguity, as C_R explains.

You've asked whether the difference arose from using the two input forms, ie. 2D Input with the explicit command, versus 2D Input with units-shortcut entry. In that case the only difference (ie. if the commands were the same) would be that with the shortcut the unit in the input is typeset like in the output.

Below I've used Alt-Shift-u to get the Unit(m) typeset in the input for the line involving expr2.  In modern Maple that input renders with an upright Roman "m", without double-braces. (Mapleprimes uses an older backend that still shows the double-braces.)

As the lprint (line-print) command reveals, the expressions themselves are the same.

Download 2dmath_unit_entry.mw

See also this Help page which describes this hotkey mode of unit entry.

There are two main ways to get a subscripted name.

One involves a double-underscore (so-called Literal Subscript), and another involves an indexed name (so-called Indexed Subscript). The actual constructs for those would be g__n and g[n], respectively.

The ScientificConstants package uses the latter, ie. indexed names, to refer to its constants.

In 2D Input mode you can get the typeset subscripted form for input with the keystrokes,
    g Ctl-Shift-underscore n      (Windows, Linux)
    g Cmd-Shift-underscore n    (Mac OSX)

For example, using those keystrokes,

Download 2dmath_indexed_entry.mw

You can also enter g[n], literally, in either 1D or 2D input modes.

See this Help-page for 2D Input ketyboard shortcuts.

You wrote,

Consider the expression 5m+x. This expression works in
Units:-Simple but not in Units:-Standard.

Units:-Simple adds a quantity 5m to a quantity without units.
But why can one add a quantity with units to a quantity
without units?

Units:-Standard tries to add a quantity 5m to a quantity
that is assumed to have units. What units are assumed?

The point is that the name x might be evaluated later on at some value involving some unit of dimension length.

One can evaluate x (in expressions containing x) with pretty much whatever value you want, in general. And for the expression 5*Unit(m)+x some later value like 3*Unit(mm) or 8*Unit(km) is quite fine. So the expression 5*Unit(m)+x can be allowed. So that's one thing that the newer Units:-Simple does, which the older Units:-Standard does not: it allows such an addition.

You asked, "What units are assumed?" But it's not some specific unit that's taken. It's the dimension of length that is taken.

And with the notion that the x in expression 5*Unit(m)+x can be considered as having dimension length, further dimensionall anaylsis is possible. That dimensional analysis may help with further symbolic manipulation.  That dimensional analysis can also help in the front- and back-ends of commands that are taught to understand units more, eg. plot, fsolve, etc.

Since you have Units:-Simple loaded, you don't need to do combine(...,units) or simplify to get the simpler units you originally showed.

You can instead accomplish your simplification/combining of units, directly upon substitution, by merely using eval instead of subs.

I also show how the J/mol form can be attained, in two ways.

Download Units_-_Subs_zent2.mw

I just use with(Units) to get Units:-Simple as default. (That's not showing in the sheet as inlined in this forum.)

ps. If you inadvertantly create an expression with over-complicated units then you can use combine(...,units) on it.

If you specifically want to avoid additional non-units-related simplifications/changes then IMO combine(..,units) is better than calling simplify. nb. also, simplify doesn't handle your original subs result in 2022.

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.