@MaPal93 If I understand you correctly (based on the code in your first Reply), then you consider each column of each matrix as a separate function, so there should be three "curves" for each matrix. Is that correct? If so, does this plot make sense for your purpose?:

X:= <seq(1..op([1,1], M_jk))>:  #op([1,1], ...) is the row count.
plot([seq](<X | M_jk[..,j]>, j= 1..op([1,2], M_jk))); #op([1,2], ...) is the column count.

If that makes sense for your purpose, then do the same for the other matrix, and put the two plots together with dualaxisplot.

If that doesn't make sense for your purpose, try to explain to me why not, and I'll probably have another idea.

@PhearunSeng 

Assuming that 

1. the non-atomic entries (i.e., the inner vectors or matrices) of the outer matrix DOe each contain only 1 row,
   AND
2. the number of atomic entries (the integers in your example) in each row of DOe is the same,

then it can be flattened like this:

#Construct your example:
DOe:= eval(<a,b; b,c; c,a>, [a,b,c]=~ `[]`~([<1|2>, <3|4>, <5|6>]));

#Flatten it:
Matrix(
    [seq](
        (ListTools:-Flatten@[subsindets])(DOe[k], rtable, v-> seq(v)), 
        k= 1..op([1,1], DOe)
    )
);

Maybe now you see that it's far easier to just avoid creating matrices that need to be flattened.
 

@PhearunSeng I don't think that you understood the read-between-the-lines rhetoric of the "flattening" part of my Answer, due to my gentle tone, so I need to reiterate it more vehemently (also reiterating something Tom Leslie said to you):

You have some earlier code, which you haven't shown, which produces the matrix DOFe. That code is a corrupt, filthy piece of crap. That code is what you should ask me to teach you to correct, so that I'd be teaching you to avoid producing crap rather than teaching you how to wipe it up after it's produced.

However, I will show you how to flatten that matrix if you'd attach a worksheet that produces it. Please attach it. The plaintext code that you gave just gives me a error (which is likely not your fault).

Unrelated issue: I see this command in your code:

with(linalg)

This is also filth, crap; "deprecated" is the official word, which sounds vile enough already. You should never use that command.
 

Anecdote: In the mid 1990s, a company that I was doing some computing consulting for purchased a full-package (integrated hardware and software) accounting / inventory / point-of-sale (i.e., cash register) system. The software was written in a ridiculous language named KADOL, which was proprietary to that company. My job was to "maintain" that software, that is, make on-demand and reasonable modifications to it that were peculiar to my client's business (a chain of 11 hardware stores, 7 retail and 4 for building professionals).

All of that KADOL code was crap. It worked, but was very difficult to read and modify. Fortunately, the files of code were each only a few hundred lines long. At the top of one file, where a programmer might ordinarily put their name in a comment, I saw this comment instead:

# Are you kidding? I wouldn't put my name on this crap.

@vs140580 In my formulation, G1 is the smaller graph and G2 the larger. In your followup immediately above, it seems that you may have switched those roles. I'm not sure; your writing is difficult to understand. Can you please check whether in the above G1 always refers to the smaller graph and G2 the larger?

@vs140580 It's okay. Even I didn't know about the importance of the "Text" and "Math" boxes until today. I do believe your sincerity.

@Dkunb Let's suppose that your expression for H[s] is correct:

H[s]:= sum(Norm(p_[n])^2/2/m + U(q_[n]), n= 1..s) 
    + sum(sum(V(q_[i] - q_[j]), j= i..s), i= 1..s)/2;

(I have no reason to doubt that it's correct; I simply say "let's suppose" because my next conclusion depends on it being correct, which I have no means of verifying.) I consider H[s] as a function of positive integer s (function being used here in the mathematical sense, not either of the Maple senses). You want H[N-s]. Via done-in-my-head substitution (s:= N-s) and re-indexing (shifting indices up by s), I get

H[N-s]:= sum(Norm(p_[n-s])^2/2/m + U(q_[n-s]), n= s+1..N)
    + sum(sum(V(q_[i-s] - q_[j-s]), j= s+i..N), i= s+1..N)/2;

Does that seem correct to you? And do you see how it's different (and more than just superficially different!) from what you had?

@nm It can be corrected by changing `if`(e::`=`, lhs-rhs, x->x) to 

(numer@`if`(e::`=`, lhs-rhs, x->x))

And, although it's not necessary for any among your current list of examples, I think it'd be wise to also change evala@Norm to numer@evala@':-Norm'

The final expression (the integral) contains two partial derivatives of "rho", but there's no rho mentioned earlier.

I recommend that you copy-and-paste my code directly as plain text into a 1-D Input (Maple Input) execution group with the leftmost box on the lower toolbar, labelled "Text", highlighted. I'm not sure what exactly happened in this case, but I think that

1. having "Maple Input" selected in the pull-down box is essentially just changing the font (and only the font) to the font usually used for Maple Input---a red monospaced Courier New (this is the point that I'm not sure about);
2. the code is still being interpreted as 2-D Input because the "Math" box is highlighted rather than the "Text" box (this part I'm sure about).

But you can use any font that you want (needn't be monospaced or red, for example) and still have it processed as 1-D Input. The important thing is that the "Text" box is highlighted.

Here is the code as a worksheet in 1-D input where I've changed the font and styling to that usually used for 2-D Input---black italic Times New Roman. (This particular restyling is just an example, and I'm not recommending it. Times New Roman with the majority being in italics is extremely ugly.)
 

Download prog.mw

I write Maple code and I write articles on MaplePrimes solely for my own enjoyment; for me, there is great beauty and glory possible in it. But there is no enjoyment at all for me interacting with 2D Input in any way. I don't want to read it, correct the errors caused by it, advise people about it, and certainly not write it. It is utterly repulsive to me to even see it (because of the horrible spacing of the default italic font combined with non-italic brackets and other symbols). In short, while I love answering your graph theory (and related) questions---they're often quite interesting--if you continure trying to put my code in 2D Input, I'll need to stop.

As an example of what would go wrong, suppose your module had somewhere the command print(is_valid). Should it print the boolean variable or the procedure?

@nm According to the help page ?odeadvisor,linear:

• The general form of a first order [sic] linear ODE is given by...
  linear_ode := diff(y(x),x)+f(x)*y(x)-g(x);

Your ODE (x+y(x))*diff(y(x), x) is not in that form. So, odeadvisor shouldn't say that it's linear. In other words, I think that it should be considered a bug. 

@nm Okay, I see your point now. But I was confused by your title and first paragraph, which I took to mean that you considered it to be linear, and that thus the problem is with convertAlg. So, perhaps we agree here that the main problem is with odeadvisor, not with convertAlg.

I'm not sure exactly what your definition of linear is, or the definition being used by odeadvisor here, but I'd say that that ODE is not linear (at least not in the "raw" form that you present) because it contains a product of y(x) and diff(y(x), x). Perhaps it's the "reduced form" diff(y(x), x) = 0 that both you and odeadvisor are considering. Yes, sure, that's linear. But I don't think that convertAlg is seeing it in that form.

It's not even clear to me that your ode should even be properly called an ODE in a strict sense, although it's fine by me if dsolve chooses to solve it anyway. I'm more inclined to call it an ordinary differential-algebraic equation.

I agree with Tom. The definition does not exclude the possibilities f=0 or g=0. And more importantly, the transformation that this form allows is still valid for f=0 or g=0.

@mmcdara If A and B are column vectors (as they are in all the examples shown so far in this thread), then the desired operation can be done simply by

A.B^+

(regardless of the number of elements of A or B; they needn't be the same).

If they're matrices instead of vectors, then KroneckerProduct (or an easy ad hoc procedure) are needed.
 

Your usage of the term built-in procedure is not the standard usage of that term in Maple. The term officially refers to commands that are integral to the "kernel" rather than being written in the Maple language. KroneckerProduct, Matrix, and even `.` are all procedures written in Maple; on the other hand, rtable, `*`, and `+` are built-in.

type~([LinearAlgebra:-KroneckerProduct, Matrix, `.`, rtable, `*`, `+`], builtin);
                   [ false, false, false, true, true, true ]