@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 ]

We'll probably need more details if there's to be any hope at all of helping you. Note that your version of Maple is about 20 years old. What you describe seems like a problem with the GUI (Graphical User Interface). That GUI software is not used anymore. And even if (and it's a big "if") it were theoretically possible to fix some bug in it, I don't know if it would be legally possible for Maplesoft to do it. Nor would it make any business sense (in my opinion) for them to devote more than, say, 1 worker-hour to fixing some bug in that ancient system. 

So hopefully your problem can be solved without modifying the "Classic" GUI. To help, please clarify the following:

1. Are you saying that whenever you try to save a worksheet, your entire Maple session crashes (completely disappearing from your screen)?

2. Is the worksheet actually saved when this happens? Or do you lose your worksheet and your session?

3. Are you trying to save some code while it is running?

4. Was there ever a time using your current computer, current operating system, and current Maple version when you did not have this saving problem?

5. Was there ever a time using a different computer, different operating system, or different Maple version when you did not have this saving problem?

@Christian Wolinski "Good", but not worth a Thumbs Up?

In case you're not familiar with pointto and assemble, I thought that I should also show an example of explicitly creating a pointer to an object that can be pointed to at the user level (rather than one where the command causes an error):

kernelopts(dagtag = INTPOS); #positive integer INTERNAL type
                               2

A:= assemble(2, 23); #This returns a memory address (session dependent!).
                   A := 36893488147419103275

n:= pointto(A);
                            n := 23

The inverse of assemble is disassemble; the inverse of pointto is addressof. The 62 fundamental data types are known in Maplese as dagtags. The first argument to assemble is thus an integer[1..62]. The procedure d-> kernelopts('dagtag'= d) is its own inverse.

I just deleted a Post by you which was a follow-up question to the above. Please put your follow-up here instead of in a new thread.

Okay, I felt like looking at the 8th-order method. Where is it?

@ You wrote:

• For some reason when I run it, the same error Error, (in plots/odeplot) input is not a valid dsolve/numeric solution) still pops up. All I have changed is the mass values. I ahve attached the code below.

I can't duplicate that problem. I loaded the worksheet that you posted, with the changed mass values, and clicked on the !!! icon on the toolbar to Execute Entire Worksheet. Within 2 seconds, the entire worksheet executed, and the new plots were produced:

• Also for some reason, why is the code for the plot in text mdoe rather than math mode?

What makes you say that it is in text mode? When I use the worksheet, the code for the plot doesn't seem to be in any format different from any of the other code. And the mode indicator on the toolbar says "Math".

Edit: Actually, whether it says "Text" or "Math" on the toolbar seems inconsistent. Sometimes it does say "Text". I guess this is a bug. But, regardless of what it says, the code executes exactly the same for me.

I'm using Maple 2022.1 on Windows 10.