@salim-barzani 

Shure:

>  restart; >  local gamma: >  Added random values for the parameters theta and gamma >  params := {alpha = 2.5, k = 3, w = 2, beta[3] = 3, beta[4] = 1.7,theta=0,gamma=1}; (1) >  (2) We perhaps want to plot the magnitude and color it with the phase - so make [mag, phase] >  sol1 := [U(xi), -k*x -(9*alpha*k^2*beta[4] + 2*beta[3]^2)/(9*beta[4])*t + theta]; (3) Assume some functional form for U(xi) >  sol2 := eval(sol1, U(xi) = -beta[3]/(3*beta[4]) + beta[3]*sinh(xi)/(6*beta[4]*cosh(xi)) + beta[3]*cosh(xi)/(6*beta[4]*sinh(xi))); (4) insert numerical values >  solnum :=eval(sol2, params); (5) >  #plots:-complexplot3d(solnum, x = -50.. 50, t = -50..50); >  >  >

Download complexplot3d_reply.mw

I have never seen this before but I remember that you run Maple with modified kernelopts settings form default values.
When exactly do you get this message? After having executed input involving kernelopts?

@salim-barzani 

The sheer amount of libraries you load makes me uneasy. So I have done it by hand just excluded that packages do not work well together. This does not seem to be the case.
Could it be that you B__0 has an error of sign in the second or third summand?

Download simplify_by_hand.mw

@Nicole Sharp 

Does it display as you want in print layout mode? This is supposed to be a WYSIWYG (what you see is what you get)

@acer 

You are correct. I had the sum 5 * Unit(m) +x in mind, which does not lead to an error message in the OPs example with the error messages using Simple (but it does using Standard).

In your example, Simple temporarily assumes that x is of unit m which does not fit to the second term where x must be of unit s. No global checks accross several inputs are performed.

I never understood why Simple is called simple. It seems to be more sophisticalted than Standard (or at least allows for assignements to names/variables with and without units).

Anyway, I don't use unit packages. I am fine with subs/eval of 'name=value*unit', simplify, combine and convert after having done algebra on symbolic physical equations/expressions. Unit inconsistencies will finally reveal at the end, when numerical results are computed form the symbolic results. 
Assignments to names as 'name:= value * unit' have complicated my work since they "ruin" symbolic results (which require reexecution of a worksheet when this happens). So I stopped using assignements for physical quantity and parameter definition.

@dharr ,

Since @zenterix came up with a case of practical importance, I was unhappy with Maples output which does not accept units. Here is how a general solution can be derived that does accept parameters with units.

From dharrs worksheet

In the same way

Both expression do not evaluate with units.

However, the intersting part is the following:
Both scale with k which is in J *n/mol. The more molecules are present, the higher is the work to be performed.

So far so easy. The arguments of ln() scale with the values and units of V and P, respectively. But the difference of ln's scale as follows

Meaning: the units used for V an P do not matter only the ratio of values counts.

Substituting Maples output with the right hand side results in a propper general solution.

Download Units_int_general.mw

@acer , @Thomas Richard 

Not as short as I hoped for but better than op().

Unfortuneatley the parenthesis convention of ISO80000 to symbolise the extraction operation of values and units is not common and does not fit Maples use of parentheses. Otherwise it could be used in pretty printed output.

To make code and/or output better understandable defining a function with a selfexplaining name like

UnitOf:=x-> Units:-Split(x, output = unit);

is maybe the best compromise.

Thank you for the details

@zenterix 

dim_V is nothing special. I used it to express the unit of V (I should have called it unit_V. I will correct it).

Deviding by unit_V removes the units from your original ranges which is required to make ln() work.

https://en.wikipedia.org/wiki/Physical_quantity defines a physical quantity Z as composed of two operands

Z= {Z} * [Z]

where {Z} means the value of the quantity (i.e. a number) and [Z] is the dimension. {} and [] in this definition stand for  operations that extract the value and the unit of a physical quantity, respectively. Since in Maple [V] would be a lengthly command of the units package, I have introcuced dim_V=[V] to express the unit of the quantity V.
So v in my answer stands for v={v}.

Anyway, I have edited my answer and introduced a variant without auxilary variables.

This does not work for me:

int(n/v, v = n*Unit('m'^3)/t .. m*Unit(Unit('m'^3))/t);
Warning, units problem, not enough information to unambiguously deduce the units of the variables {n, v}; proceeding as if dimensionless

@acer 

The example is probably too simplistic in the sense that a user would not use has on such a simple expression. It’s obvious from the screen. In the original expression the search pattern was larger and very similar expressions were presented on a screen filling output. The user could not substitute expressions he saw on screen. To understand the problem, has was used, which surprisingly did not work as expected.

New users to Maple learn denom before they discover (if ever) that Maple does not use quotients internally. This can lead to the contradicting situation where a product has a denominator

I/sqrt(a):
whattype(%);
denom(%%)
                               I   
                             ------
                              (1/2)
                             a     

                               *

                              (1/2)
                             a     

Kitonum explains in more detail why Maples output “false” is technically correct – a view on has from Maples internal representation. nm’s answer focusses on the pretty printed output and provides the expected answer “true” – a has varaint for GUI /pretty print.

Your reply adds the aspect of collecting/factoring an expression (that is not a subexpression) in an expression. This is beyond pattern matching of subexpressions and common-sense interpretation of has (which could lead as we discuss here to incomprehension when the internal functioning of Maple is not known).  

Your answer has(%,{a^(1/2),a^(-1/2)}) tells me that there is no “GUI has”.  I think it’s a good example to raise awareness that has does not always produce the expected answer when used in for GUI output. Since decomposing of a complex expression with op  is not straight forward (to understand the structure of an expression), I wonder whether indets would have given a better indication that I/sqrt(a) does not contain sqrt(a). If so a link on the help page of has could be beneficial in addition to a note and/or example that has is designed for the internal representation of an expression. This could help making an important learning step in case has is used.

@Ronan 

Looks like that \n does not work inside Typeset and that there is no new line MathML tag that can be used instead with Typeset.

By the way, typeset or Typeset in my former examples with mover is not needed when Typesetting is loaded

display(point(Pgamma2, symbol = solidcircle, symbolsize = 14), textplot([Pgamma2[], mover(mo("⁢"), mo("γ2")), align = {above}]))

For me the lower case typeset is an unlucky choice. Too close to Typeset but not the same. 

@acer 

Somehow \n is not working. What is wrong with my trials?

display(point(Pgamma2,symbol=solidcircle,symbolsize=14),textplot([Pgamma2[],Typeset((`gamma2`,"\n" )),align={above}])); # this is what I tried before mover
display(point(Pgamma2,symbol=solidcircle,symbolsize=14),textplot([Pgamma2[],typeset(Typeset((`gamma2`,"\n" ))),align={above}]))

@dharr 
I would have expected the floats to trigger this in the same way the limits do. In both cases the solution is not exact.
The error must be somewhere else because int integrates numerically.

infolevel[int]:=5

Update:

The inner and integral yields a piecewise expression with conditions on y with is 3 times Float(undefined) and a big expression otherwise. This big expression does not evaluate to 0.2080471649. There is clearly something not working as it should.

@Ronan 

It's not really documented. Apart from 

Most other Typesetting exports correspond to either internal-use routines or typesetting tags, which roughly correspond to MathML tags. (from the Typesetting helppage)

I got most help from Acer and Carl Love. And, since I am not typesetting on a regular base my frist command was unnecessary long. Here is a shorter version

display(point(Pgamma2,symbol=solidcircle,symbolsize=14),textplot([Pgamma2[],Typeset(mover(mo("⁢"),mo("γ2"))),align={above}]))

that skips the longform (no mention of the typeset package). Took me a while to figure out that when calling plot (Edit: sometimes but not allways) typeset perfroms the same as Typesetting:-Typeset.
 

display(point(Pgamma2,symbol=solidcircle,symbolsize=14),textplot([Pgamma2[],typeset(mover(mo("⁢"),mo("γ2"))),align={above}]))

An important other tag is mi for italic.

If 2D-Math is accepable there is a much easier way using the palettes which you can also use to learn type setting in 1D.
 

Download MathML.mw

should this be Pgamma2

@nm 

There can be many reasons why a graphic card is part of an issue. For example, the system is configured not to use the graphic card and used the internal graphic adpter.

You can check this in the task manager under GPU. With the NVDIA control center you can force which adapter is used by javaw.exe.

A driver update could make sense.

I am on Windows 10.