@C_R @acer 

Interesting discussion. As you note, facility with Maple enters into that - short code that is easily understood by a Maple expert can just be cryptic for a beginner. There is also a tradeoff between "shorter and simpler" and more rigorous (in the sense that all input cases are covered). So the use case is important.

In responding to Mapleprimes questions or for my own use in the middle of a worksheet, I usually use procedure parameter type checks, but just to cover the common cases and not fully rigorous, in order to keep it simple (readable). As an educator, I've found that students are usually looking for a simpler answer than I think, and will ask for more depth if they want more. On Mapleprimes there is always the hope that they learn something useful, which is less likely with complicated code. But for a more experienced questioner, my answer will have less simple/more rigorous code.

For my own worksheets, if a procedure becomes more complicated, I usually relegate it to the startup code region so it doesn't interrupt the worksheet flow. But if I am going to put it there "out of mind" and forget its details, I'll usually do more argument checking. Often, say with a graph theory procedure, the argument checking can be a significant fraction of the procedure code.

In the present case, inbaseunits could be relegated to startup code, then I think the result is "simpler" in some sense. I put the argument checking partly so I didn't have to think too much outside the use case, such as what is wanted for x + 3*Unit(kg)? Also I reluctantly added the numeric type check since in this context Nr = 20 is supposed to pass, but really is that in base units? Once I realised that if a non-SI unit system is in use it doesn't work, I changed the name but didn't add any code, not so much to keep it simple, but because @C_R could recognize if something went wrong because of that and modify accordingly.

I would always put the evalb in, because then the procedure is self-contained, but I agree it is less readable, especially to a Maple novice.

I also gave some thought to if simplify and convert(..,unit_free) might, for some complicated expressions with many units, lead to numerical round-off errors that would make the two sides not equal. One solution is not to check the numerical part but to somehow check the unit part for base units. So here is my non-readable, non-simple version that recklessly uses an undocumented feature, which operates on the units part and checks for SI. (And avoids evalb.)

inbaseSI := p::{numeric, with_unit(numeric)} -> 
p::numeric 
or
  subsindets(attributes(Units:-Split(p)[2])[1],
             specfunc(Units:-UnitStruct),
             q -> if op(3, q) <> "SI" then undefined
                  elif op(2, q) = "gram" and op(1, q) = 1000 then 1
                  else op(1, q)
                  end if)
  = 1;

You ask "Why is a list returned>", but you are operating on a list, so that is not surprisng to me.
You ask "What happened to the units?". Units:-Split produces a sequence, say "2, Units(mm)" so you are doing simplify(2, Units(mm)) and simplify ignores the second argument.

You first solution seems reasonable to me. I'm a bit mystified as to why you want to do this. Since simplify puts everything into base units, just put the numbers into your integral or whatever and simplify before converting to unit_free.

Joe's user profile has disappeared. Not sure what that means, if anything.

@C_R Well I generally have low expectations of 2D, and for the finer aesthetics I usually don't care. The form converted to 2D seems to be functioning correctly even if it looks strange.

Generally if you have a pre-existing expression defined earlier, then you should use MakeFunction rather than the arrow operator to avoid confusion between local and global variables. But the arrow operator should be good for a one-line expression entered as you used. There is something more subtle here with Units that I don't understand.

@C_R If you put

mm := 5;
Unit(mm);

you get Unit(5), so generally speaking you do need the uneval quotes. But you don't need them inside the piecewise within the procedure definition; you can just omit them.  My answer was working under the assumption you wanted them there; if not then just leave them out as you found.

@C_R The weights are chosen so that exact solutions would be obtained for solutions that were polynomial in the space "x" coordinate of degree up to n-1. This gives you freedom to choose the x node locations. (I assume this is what you mean by elastic; that's new terminology for me.) (The method of lines uses finite differences in the x direction instead; neither of them are FEM) Of course intuitively you will do better if they are more closely spaced near where the solution is changing most rapidly. Just as in regular integration, you can do better if you choose the node locations optimally (gaussian quadrature) - then you get agreement to polynomials with twice the degree. 

The following paper doi: 10.1016/0098-1354(89)85051-3 has a nice discussion of some of the tradeoffs. Of course anything can be improved but at some point someone (or at least for me) becomes too involved in the numerical method development rather than the problem solving; and there are often good routines existing out there.

@Aliocha So it seems you are interested in the definite integral? Mariusz's answer can be modified to show the definite integral is n*Pi. I used simplify(...,symbolic), which isn't optimum. There are probably some series of smaller simplifications/conversions with assumptions that might get there instead of simplify/symbolic.

Download definite_integral.mw

@Rouben Rostamian  This runs identically in 2026.1

@sreilly17 Sorry, that's all I know, and going to the page you mentioned just gets a firewall error message (a common random problem on maplesoft's web pages). I can only suggest you contact customer support.

@Mariusz Iwaniuk Nice, vote up. You could do R3 := value(R2) assuming n::posint; to evaluate the summation.

Maplesim is a separate product from Maple, and is not included with the full version of Maple. So I doubt it is included in the student version. If you have some reason to think otherwise, you could contact customer support via the Maplesoft website.

@C_R As you probably know, BC4 is part of the mathematical specification of the problem and is necessary. The general solution to Bessel's DE is a linear combination of BesselJ and BesselY. But BesselY becomes infinite at r=0, so we need BesselJ, which already has its derivative zero at r=0 (except for BesselJ(0,r)). So by choosing BesselJ (as @Rouben Rostamian did), BC4 is automatically satisfied.

@bashar27 Your explanation was in the title and cut off; we just got "mainly i need to collect independent term after...". So please upload your worksheet and put your explanation in the body of the post.

I think the point about a "time" variable is that the the associated conditions are "initial" conditions, so if it isn't actually time it can be treated as time if the conditions only specify one end of its domain, in contrast to a spatial variable where boundary conditions are specified at both ends of the domain. See the description of the "time" option. "These options are typically needed only for first order non-periodic problems where only one of the end points appears in the condition." So it looks to see if there are conditions at one or both ends of the domain.

If you specify your rod problem in more detail it might be easier to answer, but I'm guessing you have conditions at both ends of the rod, and at both ends of the radius (r=0 and r=rod_radius), so no.

If collect(equ,tanh) doesn't do what you want, then you will need to explain exactly what you want to do. Your tanh's are inside JacobiSN etc, so probably you can only simplify the arguments of JacobiSN etc in some way. But what way? You also have sech, sinh, cosh; do you want to convert them all to tanh? Does convert(equ,tanh) help?