Let us assume that the system starts (ie t=0) with the spring at its 'unstretched' length. The coordinate x(t) is measured downwards from this point. With this start point, the start position is x(0)=0, and the start velocity is D(x)(0)=0.

Now consider the forces on the mass: you have three

1. the constant gravitation force (m*g)  which acts downwards
2. the spring restoration force, which always acts upwards. This is given by the product of the spring constant and the displacement, so will be -k*x(t)
3. the friction: this is always proportional to the velocity. If the velocity is positive (ie weight is moving 'downwards'), then the friction force is 'upwards' and so is given by -mu*diff(x(t),t). If the velocity is negative (ie weight is moving upwards), note that the term -mu*diff(x(t),t) will be positive - ie a downward acting force. So the friction force is always given by -mu*diff(x(t),t)

Hence the total force on the weight is given by

mg-k*x(t)-mu*diff(x(t),t)

From Newton's law, this is equal to mass* acceleration, ie m*diff(x(t),t,t). Hence the ODE you have to solve is simply

m*diff(x(t),t,t)=mg-k*x(t)-mu*diff(x(t),t)

Which can be achieved with the worksheet

Download odeprod.mw

Notice that (as expected) after some time, the system comes to rest (ie velocity=0), with the spring in an extended position: ie x(t)= a constant>0 for all time, which is physically correct

Only time I tangle with 2-D input is when responding to posts here. Otherwise I'm more-or-less a completely one-dimensional sort of guy. Useful to know that 2-D input on 2017 has developed a few more 'quirks'

Believe it or not I did consider some kind of operator overload, but decided that this was not possible(?), since it would not result in a valid latex expression

If you just want to plot a 'velocity' term for any of the answers you have been given so far, then the correct syntax would be

plots [odeplot] (res,[[t,x(t)],[t,diff(x(t),t)]],t=0..10,numpoints=500);

I don't propose to answer your second question, because

1. It doesn't make much sense - the left hand side of the expression m*diff(x(t),t,t) + k*x(t) + mu*m*g*signum(v(t)) = F  depends on the independent variable 't'. But the right-hand side seems not to. You imply that it is a value which only applies when t=0
2. Since your original problem was ill-posed - everyone here spent lots of time and effort trying to work out whether the sign change in your original equations depended on x-doubledot, or x-dot (and you still have not clarified this!). I (for one) will not be offering further contributions on this problem until you clarify this question.

To be painfully clear, in your original question, state clearly whether your original ode system is

m*diff(x(t),t,t)=-k*x(t)-mu*m*g*signum(diff(x(t),t));

or

m*diff(x(t),t,t)=-k*x(t)-mu*m*g*signum(diff(x(t),t,t));

Once you have made the above very clear, consider again your recent post

m*diff(x(t),t,t) + k*x(t) + mu*m*g*signum(v(t)) = F

Since you do not specify 'F', I assume that this is a numerical constant, so the force is applied for all time. That's what your equation states, but I'm going to take a wild guess that's not what you mean. If you want to define a force which is instantaneously applied at t=0 and then removed, you might want to consider the definition

m*diff(x(t),t,t) + k*x(t) + mu*m*g*signum(v(t)) = 0
m*diff(x(t),t,t)(0)=F

But only you know what you want! I'm just not planning on guessing any more

In my previouys post I suggested thst the the initial conditions (mainly x(0) ) could determine one of two viable solutions. However what I realised about 20secs after hitting 'Submit" was that in either of these cases, the second derivative x''(t) would never change sign, so any kind of oscillatory behaviour would be impossible - so again, no way to produce the oscillatory behaviout which OP seems to require.

Either there is something deeply wrong with this problem statement, or my last few remaining neurons have given up

and I wish it had occurred to me. One suggestion might be initial-condition-related: ie if x(0) < -mu*m*g/k  then x(t)< -mu*m*g/k for all t. Similarly if x(0) > mu*m*g/k  then x(t)>mu*m*g/k for all t. Haven't got time at the moment to investiget if this makes any sense - may get back to it later.

The OP's original question specifies that the sign change depends on diff(x(t),t$2), whereas you have used diff(x(t),t). If I modify the eventcondition in your code to

resE:=dsolve({eval(ode,params),x(0)=1,D(x)(0)=0,b(0)=0},numeric,discrete_variables=[b(t)::boolean],events=[[diff(x(t),t$2)=0,b(t)=1-b(t)]]);

Then the dsolve(..numeric) process errors.

I was also interested in why you initialised the boolean as b(0)=0: if I use your original command, with b(0)=1, then

resE:=dsolve({eval(ode,params),x(0)=1,D(x)(0)=0,b(0)=1},numeric,discrete_variables=[b(t)::boolean],events=[[diff(x(t),t)=0,b(t)=1-b(t)]]);

produces a "growing" oscillation - rather than a damped one.

#####################################################

I find this interesting, because I attempted a symbolic solution to this problem utilising a signum() function to handle the sign change, as in

restart;
params:=[m=1.0, k=0.1, g=10.0, mu=0.003]:
eqn:=m*diff(x(t),t$2)=-k*x(t)-signum(diff(x(t),t$2))*mu*m*g;
sol:=dsolve([eval(eqn,params),x(0)=1, D(x)(0)=0]);
plot([rhs(sol[1]),rhs(sol[2])], t=0..100);

However I assumed I was misunderstanding something, because (irrespective of the ICs I picked), the dsolve() command always returned two solutions, both oscillatory, and neither with any sign of damping.

Interestingly if I change the signum() function to signum(diff(x(t),t)) to align with eventcondition which you used in the numeric approach, then I cannot persuade dsolve() to provide an analytic answer, irrespective of the ICs and paramValues which I used

When you say

"Thank you for your programmed solution"

I did not provide a "programmed solution".

Maple supports two forms of input - known as 1-D input and 2-D input.

Neither of these has anything very much to do with programming. They are simply two methods of the writing the same Maple instructions

Maple 1-D input is interpreted/executed directly.

Maple 2-D input is first of all "parsed" into 1-D input, and the resulting code 1-D code is then interpreted/executed. Note the extra 'parsing' stage.

The fundamental problem is that the extra  "parsing" stage associated with 2-D input is not 100% bulletProof - after all it is a softtware process, and which software process actually is bulletProof?

So when you have a problem when using 2-D input you cannot tell (and neither can I immediately) whether this problem arose because

1. the parsing process from 2-D input to 1-D input failed
2. the interpretation/execution of the resulting 1-D input code failed

However when you provide some code using 2-D input, I can immediately tell where the problem is by the simple expedient of selecting your 2-D input code and utilising the "convert to 1-D input" command on the Maple "format" menu - and reading the result

You state

Please find attached my doc where in there is no error on procedure call.I have made dt as local and included the proc inside module.

However in the file you attached

1. There is no 'procedure call'
2. There is variable dt so stating 'I have made dt as local' is completely meaningless
3. Since there is no 'procedure call' (see 1 above), and there is no module definition, the statetment 'included the proc inside module.' is doubly meaningless

On reflection, I'm tempted to go with vv's suggestion that this is timing issue - although I can't think of any way to prove it (definitivel)

1. In your penultimate line you define AreaTriangle - but the final line uses  Area(triangle). Are these meant to be the same?
2. If I make the assumption that Pi+cur*Area(triangle) = Pi should actually be Pi+cur*AreaTriangle= Pi, then this produces a single PDE with three dependent functions in two independent variables, ie f(u,v), g(u,v), h(u,v). To have any hope of solving a problem with three unknown functions, you will need three equations

Most of Maple's random number generators use a fixed 'seed'. Handy for debug purposes because you can guarantee to get the same 'random' numbers each time you execute. To get a different set of random numbers each time, you have to add a randomize() command, before the command which is used to produce the random numbers. This changes the 'seed' on each execution.

The two possibilities I considered were

1. timing (as you describe above)
2. return status (this may/maynot) be influenced by timing

Most I/O-related commands, as well as performing the required  read/write operation, also generate a "return status".  *Usually* this is zero if the specified read/write command complete successfully. But if the return status is being incorrectly generated (or generated late - back to a timing issue) - then this might cause the OP's problem.

I quickly realised that I couldn't prove it either way (maybe someone smarter than me can?). Even if I could determine the precise nature of the problem, I probably couldn't fix it

Whatever the true nature of the problem (timing, return status or something else), I would consider this issue to be a bona fide bug, and hence would encourage the OP to submit an SCR

Previou post probably (certainly?) won't work if your zero elements are floats rather than integers, or indeed a mixture of floats and integers. The following (even uglier) version ought to work for any mixture of integer and float descriptions of "zero"

   restart;
   with(LinearAlgebra):
#
# All of this just to provide a matrix
# with a few zero rows and columns
#
   M:=RandomMatrix(10,10):
   M[2,..]:=Vector([seq( 0, j=1..op([1,1],M))]):
   M[5,..]:=Vector([seq( 0, j=1..op([1,1],M))]):
   M[7,..]:=Vector([seq( 0, j=1..op([1,1],M))]):
   M[..,3]:=Vector([seq( 0, j=1..op([1,2],M))]):
   M[..,4]:=Vector([seq( 0, j=1..op([1,2],M))]):
   M[..,6]:=Vector([seq( 0, j=1..op([1,2],M))]):
   M;
   M:=convert(M, float); # comment this out (or not!)
#
# Now eliminate zero rows
#
   M:=Matrix( < seq( `if`( `or`( convert(j,set)={0.},
                                                convert(j,set)={0},
                                                convert(j,set)={0,0.0}
                                             ),
                                         NULL,
                                         j
                                      ),
                                 j in Row(M,1..op([1,1],M))
                             )
                     >
                    );
#
# Now eliminate zero columns
#
   M:=Matrix(  [ seq( `if`(`or`( convert(j,set)={0.},
                                                convert(j,set)={0},
                                                convert(j,set)={0,0.0}
                                              ),
                                        NULL,
                                        j
                                    ),
                                 j in Column(M,1..op([1,2],M))
                              )
                      ]
                  );

well we have no access Op1 or Op2, because you do not supply them!

You refer to Fig1 and Fig2 which again you do not supply

So when you say that you

"use surfdata like surfdata({0p1,Op2}) it produces a plot with both the range of Op1 and Op2 between 0 and 1 (see Fig1)".

So without knowing Op1 or Op2, and without being able to see Fig1 - you expect some kind of response??

Respondents here are generally pretty smart, but regrettably they are not psychic. Consider uploading a worksheet (using the big green up-arrow in the Mapleprimes toolbar) whihc illustrates your problem

Please supply more details - as in how precisely are you performing the 'copy' operation. You state

whenever i want to copy a matrix from a result, it gives me an _rtable, and a number.

If I do this with a CTRL+C/CTRL+V operation, I still get a matrix, not an rtable with a number - So *exactly* are you performing this 'copy' operation

it is even possible. that's one I'd like to see!