It is done by Typesetting:-mn(gcd)(x,y). This command is undocumented; however, if you enter exports(Typesetting), then in addition to the documented commands, you'll see many whose names begin with m. These are all commands for doing this sort of thing.

As Acer says, the extra prompts make no difference to the meaning of the code. On the other hand, with respect to editing the code, I find them quite a nuisance (you can't backspace over them) as well as ugly. When they appear in my code, I try to delete them as soon as possible. So, yes, I'd say that there's an advantage to not having extra prompts.

What purpose do they serve? Is there some reason that Maplesoft doesn't remove the prompt from the bottom group when execution groups are merged (aka joined)? Or is it just an oversight?

And this seems as good a place as any to remind people once again that restart commands should always be placed in their own execution group. Not doing do only occasionally causes problems, but those problems can be quite weird.

The error message indicates that your variable O[L] (or O__L) does not have units. The absence of units is considered the same thing as having 1 as the unit, as indicated by the message. If you replace O[L] by O[L]*Unit(kN), it should work. I can't test it unless you supply your actual code.

Your command print(whattype(df)) is leading you to believe that df has been converted from a Matrix into a procedure. In fact, it's still a Matrix. It's an idiosyncracy of print combined with the fact that the symbol Matrix is both a type and a procedure. If you use lprint instead of print, it'll say "Matrix".

I have many more suggestions for how you can improve your code, which we can go into. 

Any of the following commands will return ln(a+b*c), which is, I think, what you're asking for.

indets(expr, function(Not(function)))[];
indets(expr, anyfunc(Not(function)))[];
indets(expr, function({`+`, `*`}))[];
indets(expr, anyfunc({`+`, `*`}))[];

You need to give deeper (i.e., more complex, more profound, more nested) examples for me to refine the above commands. You say that you want the first, but there is no second in your example, so I cannot show you how to distinguish those.

Recalling your previous Question, I need to add: If you are processing the input through InertForm:-Parse, then the above commands need to be changed because then operators will be turned into functions, so the above commands will not distinguish between sin and `%+` for example.

Among the mathematical functions, special attention needs to be given to sqrt with respect to how it behaves with respect to your type of work: sqrt(x) is either simplified (assuming that x is some expression for which that is possible) or converted to x^(1/2) (or some combination of simplification and conversion to exponent form, as with sqrt(12)). So, if you search for sqrt in some expression that you just entered, you won't find it, it becomes an operator rather than a function. This can be prevented by using the inert form %sqrt rather than sqrt. As you may have guessed by now, every function f has an inert form %f. The command value is used to convert the inert forms to active forms (as I did in my Answer to your previous Question).
 

You can ask Maple:

is(cosh(x) <= exp(x^2/2)) assuming x::real;
      true

This can mostly be handled by InertForm:-Parse followed by some filtering with indets and a special structured type (that I composed just for this situation). Here's your example done:

value(
   indets(
      InertForm:-Parse("y = s + (a/b)*log((a+c/b))"), #string!
      #selects operators with exactly two operands, both of which are names,
      #integers, or floats:
      And(specfunc({name,numeric}, {`%+`, `%*`, `%/`}), 2 &under nops) 
   )
);
                             /a  c\ 
                            { -, - }
                             \b  b/ 

Note that the argument to Parse is a string. This prevents any automatic simplifications, thereby avoiding the problem mentioned by Preben.

I said mostly because the minus sign is treated differently in Maple, even by InertForm. It is always (effectively) an unary operator when applied to a symbolic expression. So, for example:

-1 is atomic (any negative explicit integer or float is atomic).
-a is stored as (-1)*a, even by InertForm.
a-b is stored as `%+`(a, (-1)*b), where `%+` is the inert operator in prefix form.
-a-b is stored as `%+`((-1)*a, (-1)*b).
-a-2*b is stored as `%+`((-1)*a, (-1)*`%*`(2, b)).
-2*a-2*b is stored as `%+`(`%*`(-2, a), (-1)*`%*`(2, b)).

As far as I can tell so far, there is no weirdness with the handling of fractions or complex numbers: They are deconstructed into `%operator`(operands) form in the way that you probably expect. You didn't mention exponentiation, so I didn't investigate that.

If you consider the last 2 of my 6 examples above, I think that you can imagine some of the problems and ambiguities that can arise. So, if we are to proceed, then you need to show many examples with minus signs and say for each how you would like it deconstructed.

I see that you've loaded the command codegen[makeproc], but you haven't used it in the code that you're asking about. Using it is the way to solve your problem. Here's my example: I generate two long, random polynomials in variables x, y, z (to serve as examples in place of your two expressions, which I can't directly see). Then I translate them to optimized Fortran two ways: the first being the way you used, and the second by first applying codegen[makeproc]. Execute this example and observe the differences:

(p1,p2):= 'randpoly([x,y,z], degree= 32)' $ 2;

CodeGeneration:-Fortran(p1, optimize, resultname= dp1);
CodeGeneration:-Fortran(p2, optimize, resultname= dp2);

CodeGeneration:-Fortran(codegen[makeproc](p1, [x,y,z]), optimize, resultname= dp1);
CodeGeneration:-Fortran(codegen[makeproc](p2, [x,y,z]), optimize, resultname= dp2);

The second pair of Fortran commands might re-use some of the variable names, but, if it does, it won't cause any problems because those names will be local to the Fortran functions in which they occur.

It is not fixed.

A crude way that I work around such bugs is to replace arbitrary symbols, such as your a, with arbitrary (or randomly chosen) complex transcendental constants. For example, I replaced a with sin(23+I) (as well as several other such values). In all cases, the answer 2*Pi is obtained. Of course, this result cannot be accepted with mathematical certainty, but it's much safer and more certain than replacing a with a rational.

Regarding the OP's followup problem of finding integer solutions to x = a + sqrt(b*x+c), I here present two algorithms that are much faster than that posted by Kitonum. The first of these is about 35 times faster. It works with the symbolic solution of the equation and avoids repeated calls to solve. The procedure for this method can almost be automatically generated from the symbolic solution. This method could also be applied to the OP's first problem. My second algorithm is about 700 times faster than Kitonum's. To generate it, I analyzed the symbolic solution (by hand) and reduced the sufficient conditions to a few simple inequalities.
 

Download IntegerSols.mw

We can generalize the idea to any container (Matrix, Vector, Array (of any number of dimensions), table, list, set) that contains a single element. The following procedure will either

• unpack its argument if its argument is a container with a single element, or
• simply return its argument otherwise.

And it applies itself recursively so that nested singleton containers are unpacked.

UnpackSingletonContainers:= proc(x, $)
   if x::'indexable' and not x::'string' and numelems(x) = 1 then
      thisproc(`if`(x::{table, rtable}, entries, op)(x))
   else
      x
   fi
end proc:

The warning says that the system is inconsistent, not that it's consistent.

In your dsolve line, you wrote u1(x,t) twice. You meant for one of those to be u2(x,t).

If by i you mean sqrt(-1), then you should begin your code with interface(imaginaryunit= i);

Your code works for me (using Maple 2018 2D Input, same as you). But I think that Acer figured out what your problem is.

Nonetheless, the following is much more robust, seems more scientific to me, and will be better in the long run:

E__n:= unapply(
   combine(
      evalindets(
         'h'*'c'*'R'[infinity],
         'name',
         x-> eval(
            value*'Unit'(units), 
            [ScientificConstants:-GetConstant(x)][2..]
         )
      )/(-n^2),
      units
   ), n
 );

eV:= unapply(x*convert(Unit('J'), units, Unit('eV')), x);

Now the code contains no "magic numbers"; they've all been replaced by internationally recognized symbols which are automatically replaced by the appropriate numbers as needed. Also, all the unit simplification is handled.

[Edit: See much-simplified procedure below.]

I have four suggestions which unfortunately I can't test because you haven't uploaded your code. (I see that you've posted it now.) Any one of these suggestions may be enough to get the integration working.

1. It is never necessary to use and (or three-part inequalities) in the conditions of piecewise in the way that you have done because the conditions are processed left-to-right and so every condition can tacitly use the assumption that all conditions to the left of it are false. (I am sure of what I've written so far.) I have a suspicion (although I'm far from sure about it) that these ands complicate the processing of piecewise expressions by int.

2. Maple's numeric integration by default will not return a result unless it can guarantee that that result is accurate to Digits significant digits. Sometimes it struggles to figure out how many extra digits it needs to use in internal computations (sometimes called guard digits) to guarantee that. You can guide it (and override the default) by using the options epsilon and digits. See ?evalf,Int.

3. Your expressions are essentially polynomial (from what I can see from your "code picture"). I wouldn't be surprised if symbolic integration would work.

4. piecewise expressions can usually be converted to Heaviside expressions. Sometimes (maybe always) these are handled better by int.

diff has no problem with the name sol__i__j; however the __i and __j are not indices, and they have no connection to the loop variables i and j. They do display as subscripts, but subscripts are not necessarily indices.

One way to double-index sol and sys would be sol[i,j] and sys[i,j]. There are several other ways.

Before you use assign on dsolve's output, you should check that there's actually some output. It might return NULL if it can't solve the equations. In order for me to provide more details, you'll need to post your modified code (either as plaintext or an uploaded worksheet).