I have two issues with your worksheet, one major and one minor.

You have already hinted at the major issue by what you said about your variable cool. All output which will be re-used should be assigned to a variable, and all future references should be through that variable, not by re-entering the output as input. I'll state it as a maxim of programming in a command-line environment: Never re-enter output as input.

The minor issue is that there's no point to showing the value of kk, and certainly not its decimal value.

The VIEW component of the graph can be extracted by 

indets(a, specfunc(VIEW))[];

Thus, one doesn't need to remember the magic position number. It's not even clear that it's always in the same position.

I can anticipate your next two questions, so i might as well answer the first now: Even from my phone I can see that you have 3 dependent variables and only 2 ODEs. You need one more ODE. And you'll need a number of new BCs equivalent to the highest differential order of phi in the 3 ODEs.

It can be done by 

{evalindets(expression, set, op)};

This may re-arrange the order of the terms. The user cannot control the order of items in a set.

And, although it doesn't happen in this case, if some of the embedded sets have a number of elements other than 1, it's likely that the resulting expression will no longer be syntactically valid. So, I'd recommend against creating arithmetic expressions with embedded sets. A much better form of encapsulation can be achieved with functions, which, of course, interact with arithmetic operators in all the normal ways.

And, if you want the encapsulated expressions to prettyprint as if they were sets, using the { }, even though they're internally represented as functions, that's also easy.

I'd like to point out for any readers who are not paying close attention that in your original Question, you asked about differentiating wrt x[i], while in your Reply to Markiyan, you changed that to x[j]. That changes the Question significantly. 

• The issue that I raised about bound variables no longer applies.
• The new problem can be solved by Maple if you're willing to make a few accommodations that seem relatively minor to me.

The accommodations are

• Change sum to int.
• Change x[i] to x(i) and x[j] to x(j).
• Change diff to Physics:-Fundiff.

So, the command is Physics:-Fundiff(int(sin(x(i)), i= 1..N), x(j)). The returned result is expressed in terms of Heaviside functions, and is essentially "cos(x(j)) if j is between 1 and N, otherwise 0".

It looks like you need a logarithmic plot. There are numerous options for those, with the most-significant distinction being which axis or axes contain the extreme values. See the help pages ?plot,axis, ?plots,logplot, ?plots,semilogplot, and ?plots,loglogplot.

You can put two plots (or any number of plots) side-by-side like this:

plots:-display( < graph | colorbar > );

Don't confuse this command with the ordinary plots:-display command, which merges multiple plots onto the same set of axes. This command literally places them side-by-side, each with its own set of axes.

I don't know how this will interact with EPS, but you can probably test that faster than I can.

There is a simple and universal way to deal with this situation: You refer to the placeholder Trace (the one used with evala) as :-Trace.

If you find this ugly or cumbersome, you only need to do it once. Choose a name that you don't find ugly or cumbersome, such as AlgTr, assign

AlgTr:= :-Trace;

and proceed to use AlgTr whenever you need it in the evala context.

The index i is a bound variable (see this Wikipedia article). As such, it doesn't make sense to use it to mean the same thing both inside and outside the context to which it is bound, which is the sum. Maple's syntax checker let's you get away with doing it without giving an error message, but the results are often nonsense.

The commands add, mul, and seq (which are all builtin and thus not written in the Maple language) have special rules that prevent their bound variables from being abused in this way. (Of course, they all never return unevaluated, which makes this easier.) This is not entireIy possible in Maple-language procedures. I advocate that the Maple language itself include a facility whereby a procedure can do the same thing, i.e., to declare that a name argument is a bound variable. The trickier part of this is how unevaluated returns (such as your sum) are handled. I think that the bound variables should be accessible to some low-level commands such as subs, but inaccessible to mathematically sophisticated commands such as eval and diff. This would be akin to the way that the internal contents of procedures can be manipulated by subs from outside the procedure.

One of the great things about Maple is that it's easy to convert from nearly any data format to nearly any other, and both the conversion and the use of the data can often be done together in a single line. So, you want a dataplot but it doesn't currently accept DataFrames or DataSeries? Then convert to lists via

dataplot(convert~([x,y], list)[]);

If the x-values are unsorted, then the connecting lines in the above plot will be nonsense. So, you can either make it a scatter plot or sort by the x-value. To make a scatter plot, do

dataplot(convert~([x,y], list)[], style= point);

To sort, do

dataplot(convert~([x[(P:= sort(x, output= permutation))], y[P]], list)[]);

Since the type specifications required for your work are getting lengthy and it'd be useful to use some recursive types, here is how it's done systematically. 

(This code requires Maple 2018.  If you're using earlier Maple, I can make a small change to make it work. Let me know.)

RohithExtract:= module()
uses TT= TypeTools, IN= InertForm;
local
   TryAddType:= proc(TH::(name::anything))
   local T:= lhs(TH), H:= rhs(TH);   
      if TT:-Exists(T) then TT:-RemoveType(T) fi;
      TT:-AddType(T,H)
   end proc,

   AddedTypes,

   ModuleLoad:= ()->
      TryAddType~(
         (AddedTypes:= [
            #With recursive types, put base cases at beginning to avoid infinite loops!
            'Atomic'::'Or'('name', 'numeric', 'InertReciprocal', 'Negated'),
            'InertReciprocal' :: (1 %/ 'Atomic'),
            'Negated' :: ((-1) &* 'Atomic'),
            'Operators'::'specfunc'('Atomic', {`%+`, `%*`, `%/`, `%^`}),
            'Rohith'::'And'('Operators', 'Not'('InertReciprocal'), 2 &under nops)
         ])
      ),

   ModuleUnload:= ()-> (TT:-RemoveType@lhs)~(AddedTypes),

   ModuleApply:= (E::string)-> value(indets(IN:-Parse(E), 'Rohith'))
;
   ModuleLoad()
end module:

And you use it like this:

RohithExtract("1/v[0]*V1+1");

Answering your first question, the mathsize option lets you specify the width and height of the response box in pixels.

Answering your second question, passing to (and even from!) the variables can be done in a quite general way with Grading:-Quiz:-Set and Grading:-Quiz:-Get like this

restart:
proc() 
uses GQ= Grading:-Quiz;
local r:= rand(2..20);
   GQ(
      "What is $a + $b?", 
      ()-> evalindets(`$RESPONSE` = `$a` + `$b`, name, GQ:-Get), #Checks answer
      ()-> evalindets([`$a`, `$b`]=~ ['r'()$2], `=`, GQ:-Set), #Generates random numbers for problem
      inertform, mathsize= [64,32]
   )
end proc
();

The $ and `` in the variable names are required, and `$RESPONSE` is a special receptacle name for the response. None of these can be local variables. I think that this is the form that you need to use if you want the randomized quantities to appear in the text of the question (which is what I mean by "quite general way"). The inertform is needed to prevent the quizzee from being able to get "Correct" by simply echoing the problem.

If the problem can be stated in the form expression = blank box, then Kitonum's formulation, which is simpler, can be used.

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.