@ecterrab 

Short version:

There is no seamless derivation top-down from the principle of least action

to the principle of d’Alembert in its classical form

(Seamless means without deliberately multiplying at some point by -1)

Long version:

It took several iterations to get it to the point. I hope it is understandable and sufficiently consistent.

My intention is to use the new function Physics:-LagrangeEquations for d’Alembert’s principle (and maybe for other principles) for systems with non-constraint forces (external forces excluding constraint forces). This is relevant in some non-conservative (e.g. with friction) or in non-holonomic systems (e.g. with control forces) where no energy potential can be defined for non-constraint forces (in order to account for them in a Lagrangian).

In your first reply you pointed out that Physics:-LagrangeEquations can change the sign of the output. This lead to the wrong conclusion (from my side) that this is the reason for the wrong sign in my example worksheet Lagrange_Equation.mw. This false conclusion got further support from the comparison of a second case (the first example of ?dsolve,numeric,DAE) where

   VariationalCalculus:-EulerLagrange returned - A - B = 0 and

   Physics:-LagrangeEquations returned A + B = 0

For this case VariationalCalculus:-EulerLagrange produces the correct sign when used to calculate the left-hand side of the d’Alembert’s principle. However, neither Physics:-LagrangeEquations nor  VariationalCalculus:-EulerLagrange produce the correct sign in my example worksheet. So, in one instance Physics:-LagrangeEquations with the new option keeprelativesign can be used, in another not. The reason for that is simple, once noticed: The left-hand side of d’Alembert’s principle has an opposite sign than the Lagrange Equations.  Only when Physics:-LagrangeEquations for the d’Alembert’s principle is used this way the sign is correct:

Physics:-LagrangeEquations(-L,…,keeprelativesign)=Q; #note the sign

I do not see another way for a generic use of the command Physics:-LagrangeEquations for d’Alembert’s principle (which is my intention). For this reason (and for compatibility to VariationalCalculus:-EulerLagrange) I consider an option to keep the sign relevant.

Naming a command option keeprealitivesign explains what the command does. Naming it non-holonomic on the other hand describes the context, for those who know what non-holonomic is. I therefore think that keeprealitivesign is a good choice and the description could refer to cases where this option should be used. Thank you for adding this option.

In the below, I have tried to identify cases where a mismatch of sign can occur when deriving one principle from another. It basically can (but does not have to) happen on the way up from Newtons equations to the principle of least action or on the way down.

Comparing some references

D’Alembert’s principle from https://en.wikipedia.org/wiki/Lagrangian_mechanics but not named as such

The right-hand side matches the left-hand side from Goldstein’s book that you cite (assuming T is replaced by L):

Also: One of my old textbooks derives the Lagrange’s equations for holonomic systems from d’Alembert’s principle and is in line with the left-hand side of Goldstein’s book above.

However, https://en.wikipedia.org/wiki/Lagrangian_mechanics chooses a different path to derive Lagrange’s equations from d’Alembert’s principle:

This is done by substituting Q__j into d’Alembert’s principle an doing (lhs-rhs)(…) on it instead of (rhs-lhs)(…). Both operations are correct but only the second allows for what I did in my worksheet: replacing T by L in d’Alembert’s principle.   

This deliberate choice of sign is also possible when going backwards from the principle of least action to the Lagrangian’ s equations. You state

Strictly speaking, this is Hamilton’s principle but https://en.wikipedia.org/wiki/History_of_variational_principles_in_physics#action_principle_names states that Feynman called Hamilton’s principle the principle of least action. According to https://en.wikipedia.org/wiki/Principle_of_stationary_action, distinct principles, "the principle of least action" is a common name for many principles.

Anyway, in https://en.wikipedia.org/wiki/Hamilton%27s_principle the same result is derived in more detail by defining the change in the action functional this way

Since the change is stationary (not necessarily minimal) in the principle it is equally possible to change the sign of the integrand (i.e. doing L(q, q_dot)- L(q+eps, q_dot+eps_dot)). By doing so the result will match the left-hand side of the Goldstein book above. Both ways are mathematically correct. Again, the selection of one of two possible ways to define the change of action functional in a stationary context is a deliberate choice of sign. I would have probably applied the same definition as in the functional above because it is in line with the often-used convention: error = measured value minus true value. Another reason to stay with the above functional is that the variation of the action (and the variation of the Lagrangian) can be written in the form of a total differential which leads literally via integration by parts to

 --->

As long as we are dealing with conservative systems the sign of the left-hand side of the Lagrangian’ s equations is not a problem. But for non-conservative systems (where no disspative energy term for the Lagrangian can be defined for the non-conservative forces) and for non-holonomic systems sign matters. For those cases https://en.wikipedia.org/wiki/Lagrangian_mechanics  has to change the sign of the left-hand side to correctly account for the sign of forces derived from a dissipative term:

This uncommented change of sign of the left-hand side within this otherwise well-made reference is unfortunate and makes the reference somehow inconsistent.

P.S.:

My “flat” statement was more a whish towards principles that Maple has not covered extensively yet (like d’Alembert’s principle) and not towards the principle of least action.

D’Alembert’s principle leads directly to Newtons equations of motion and is closely related to the principle of virtual work. Only for this, d’Alembert’s principle has a place in physics. In combination with non-constraint forces it has a unique position with its closest cousin being Lagrange’s equations of the first kind. However, it looks to me that the principle of virtual work and d’Alembert’s principle are more used in engineering applications whereas in modern physics the principle of least action dominates.

In classical mechanics: D’Alembert’s principle, Lagrange’s equation of the first kind, and modified Lagrangian’s (by constraints) all deal with forces. Why can’t they be combined into one principle that fits all? On the one hand I have not found good references connecting these dots. On the other hand, I have not found a reason why d’Alembert’s principle cannot be changed to a modified principle using the Lagrangian or even a modified Lagrangian (see P.P.P.S).

I am not sure if a consistent description including Lagrange’s first equation, d’Alembert principle and the principle of least action without a deliberate change in sign can be found. At the moment I only see a flip of sign for the variation of the action (which I think is out of discussion) or a reformulation of the common form of d’Alembert’s principle (It would be a great relief if someone could demonstrate the opposite).

So, if there is no elegant unification, Maple can, at best, help physics and engineering users applying principles as they are making aware of signs when they matter. 

P.P.S.: Talking about engineering applications. My old textbook is consistent in itself but does not mention the principle of least action. However it is mentioned that the Hamiltonian principle states that the action int(L(t),t=t0..t1) becomes stationary which is according to the book “An insight of philosophical but not of technical value”. It also considers the Lagrangian Equations of the second kind as unnecessarily complicated to perform calculations and therefore uses for the practical part of the book only d’Alembert’s principle and Jourdain’s principle to solve problems. It also mentions the Gaussian principle that had little technical relevance. The author clearly had to do all calculations by hand, which must have been laborious at the time. These times have changed with computer algebra. I wonder if he would have refrained from making such statements today.

P.P.P.S.:

Reformulating d’Alembert’s classical principle from my worksheet (omega stands for alpha_dot)

to

would allow the use of Physics:-LagrangeEquations without minus sign.

If the Lagrangian accounts for external forces by defining potential and dissipative energy terms, the above equation becomes

where Q__NP stands for all forces that are not included in potential or dissipative energy terms. This equation should be usable with a modified Lagrangian accounting for constraint forces.

@Scot Gould 

Was a couple of years ago before 2020?

@Gabriel Barcellos 

Your case is interesting in many respects. A bench mark for Maple from physics.
Attached is a file with my edits in organge.
Campo_Médio_spin_7_2_-_Forum_benchmark.mw

My perliminary conclusion is that you do not need more memory and a processor much faster is not available. Acer mentionned already some options to improve fsolve root finding. I would like to add symbolic simplification of the equations. (fsolve is "robust" proven code. I do not think that is does allot of symbolic preconditioning.)

If you have already reached an endpoint of symplification, I still assume that compromises in numerical precision can substantially speed up fsolve (compare the time it takes to compute one root by fsolve to the many roots that implict plot computes).

Some observations:

Computing Z0, implict plots and fsolve occupy mainly one core.
System load before running the worksheet

Computing "best case": Two cores are buisy. The cpu time is about half the real time

Computing with "core hopping": The task mserver.exe distributed over more cores.

Whereas in the best case the overall system load is displayed around 5%, it is now hopping between 5 and 20%. The real time can take longer than the cpu time dispalyed by codetools. I cannot give an explanation what system state triggers the OS distributing the task to more cores.

@Scot Gould 

This does not sound like bugfixing. More like a rebuild of the interface or maybe even a complete new interface.
I am still trying to understand to what extent the current Java IDE contributes to GUI problems and whether such problems also occur on Apple OS and Linux. It seems to be non-trivial to fix randomly occuring "glitches".

The last substantial and visible overhaul was from Maple 2020 to Maple 2021. Did you get this feedback before 2020?

I have it with Maple 2023 as well.
I understand that this can be annoying because it interrupts the work flow.
Should be reportet.

@MaPal93

Have a look at the structure in the attached. I would go numeric

attempt_dot_products_for_C_R_reply.mw

@Christopher2222 

and probably less to ask. It is quite easy to use.

@MaPal93 

In your new attachment you applied innert operations everywhere. That is a bit too much. All subexpressions containing lambda[i] should evaluate to scalar expressions. The resulting polynomial expression should not contain any unevaluated matrix expressions (see dharrs answer).

And: assume is only needed for solve

There is probably also one transposition too much. Please check

Attempt_dot_products-_reply.mw

@dharr 

I agree with your no and see the potential complications. However, the first attachments of the OP evaluated to something where degree worked on. For this reasons I assumed that the commands I applied evaluated to a polynomial.

@Scot Gould @dharr

It happend again in a bigger worhsheet. This time I went back with the undo button and could reproduce it

Selecting r__1 -> typing d ->

This was not reproducible in a new worksheet (It later was in a second input line. Than it was not. Strange).

Reloading the bigger worksheet without executing it: The glitch can be reproduced with a subscript expression but not with a normal name (without subscript).

Reloading the same worksheet with Maple 2023 the glitch cannot be reproduced.

Reloading the same worksheet with Maple 2024  on a computer with more memory that suffered less from "GUI not responsive" does not reproduce the glitch.

Looks like a regression that potentially depends also on the system.

How to add this observation to the bug report?

@dharr 

It happens when I am so focussed on code editing that I cannot observe myself. If I type slowly everything is fine. It might have something to do with change equation labels, change of an index or deletion of some invisible characters.

The animation with the initial point is very instructive.

To be sure what I was looking at I did

implicitplot3d([f3], x1 = -a .. a, x2 = -a .. a, x3 = -a .. a, axes = normal, transparency = 0.7, numpoints = 5000, style = surface, color = [blue]);
plots[display](E3, %);

So the black dots are the solutions. At their locations the intersection curves of f1 with f2, f2 with f3 and f1 with f3 intersect. This would mean that at each solution 3 curves intersect or 6 curve segments meet. Is it possible to predict the number of segments without plotting them? Or the other way arround predict from the number and kind of intersecting curves the number of possible solutions?

Annother question I have: Sometimes, as here, there are infinite solutions. Infinite solutions mean a continutiy of points. Could it be that in the case that there are also infinite solutions, the  the pink curve locks into them. I.e. becomes itself a "continuous" solution.

@ecterrab 

I have just seen your reply by coincidence (I did not get a notification). Before I can reply in detail I have to solidify my landscape of physical principles. This will take time. I will see if I can dig out my old text books to verify whether they match other references. Its essential to have a common ground for discussion.

For the moment, I would like to thank you for your detailed reply

@ecterrab 

Excellent! Then I do not have to ask how to edit. Good that there is the Physics Updates project.

@Christian Wolinski 

I see

map(''`^`'', eqs, 2);
%;
            [^(a = b, 2), ^(c = d, 2), ^(e = f, 2)]

                  [ 2    2   2    2   2    2]
                  [a  = b , c  = d , e  = f ]