@acer 

I am genuinely impressed by your ability to immediately identify the source of the problem. I spent nearly an entire afternoon trying to locate the difference, but I could not determine what was causing the mismatch. Your analysis was extremely insightful.

The two methods you provided are both very helpful. The example I posted was only an extracted portion of my full calculation procedure, and your first method is especially valuable because it allows me to modify the existing program directly without rewriting large sections of code. That will save me a considerable amount of time. Thank you very much.

Regarding your final question about why I used Eval instead of eval: if I directly use eval, the differentiation variable inside diff is also replaced by L, which is not what I want at this stage. Since the explicit form of phi has not yet been substituted, my intention was to first preserve the differentiation operation and only substitute the numerical value afterward. For this reason, I used Eval to ensure that differentiation is performed before evaluation.

At present, this is the most suitable approach I have found. If there is a cleaner or more robust method for handling this situation, I would greatly appreciate any additional suggestions. Thank you again for your detailed explanation and help.

@sand15 

Thank you very much for clarifying this issue. I had been trying to understand why the substitution failed, but I could not identify any difference from the displayed expression.

Your use of lprint to reveal the internal linear representation was particularly insightful. I had not considered this approach, and I had assumed that the substitution failed simply because the expression was too complicated. It was also surprising to see that, after applying expand, an additional {} structure appeared in the expression.

Your step-by-step demonstration was very detailed and helped me understand the issue much more clearly. Adding {} inside Eval in the boundary condition bc1 is indeed a useful solution. However, since the original eqn1 definitions were not written in this form, applying this convention only to the boundary conditions makes the overall program look inconsistent. I am also checking whether there is another way to handle this replacement more uniformly.

@acer 

@acer 

I noticed that the corresponding example (“question525”) was already included in the original post, although it may not have displayed correctly. I have therefore attached the reference again below for clarity.       question525.mw

At present, using Expand does indeed make it possible to transform the inert integral of a summation into a summation of inert integrals. Direct combinations of expand and simplify did not achieve the desired result in my case, whereas Expand was able to successfully distribute and expand the expression as required.

@C_R 

Thank you very much for your help. Your interpretation was exactly the point I was trying to describe.

I noticed that you used op to extract the individual components and then reassembled the integrals term by term. Interestingly, I had previously attempted a similar approach myself. When the expression was written as explicit sums of terms rather than using Sum, Maple automatically recombined the expressions afterward. However, when using the symbolic Sum representation, this automatic recombination did not occur, which actually made the manipulation much easier to control. The difficulty in my case was that the expressions of different terms were not always written in a fully consistent form, so the approach could not always be applied directly.

I also have another question regarding your example. I noticed that your proc definition was displayed in a neatly formatted boxed style. I have wanted to produce this kind of structured display for a long time, but I have not been able to find the correct method. Could you please explain how this formatting is achieved?

Thank you again for your detailed explanation and helpful suggestions.

@acer 

Thank you very much for your method, especially the approach for expanding the summation terms. I had not considered this strategy before, and the implementation is remarkably elegant.

Regarding the extraction of terms independent of the integration variable from the inert integral, I had previously attempted combinations of simplify and expand, but the expressions in my case were likely too complicated for the approach to work successfully. Following your suggestion, I applied expand twice and then used the Expand command, which successfully transferred the non-integral-variable terms outside the inert integral.

Thank you again for your detailed help and insightful suggestions.

@C_R Thank you very much for your help. I was not aware that there is a built-in function that allows the extrema to be extracted directly. This approach is very effective and greatly appreciated.

@dharr 
Thank you very much for your help. This solution has been extremely helpful, and the use of the scan option is particularly elegant and insightful. I sincerely appreciate your clear explanation and guidance.

@dharr 

I also attempted to rewrite the system into a first-order form and carried out stability analysis using the Lyapunov method. However, I was only able to identify the singular point at the origin, and the computation process turned out to be quite complicated. Moreover, it seemed to offer limited insight, as no other equilibrium points were found beyond the origin.

Later, I came across the Bifurcation command in Maple, and I initially thought it might be capable of automatically performing numerical continuation to trace different solution branches and detect bifurcation points. However, I’m now unsure whether this command is actually designed to handle such tasks, especially for coupled systems. Is it possible that the Bifurcation command is not powerful enough for this type of analysis?

If anyone has experience using this command for nonlinear, multi-degree-of-freedom systems—or can recommend a better way to perform numerical bifurcation tracking in Maple—I would be very grateful for your suggestions.

@acer Thank you for your insightful response! I’ve gained a deeper understanding of why referencing issues occur with convertsys and learned about the advanced variable handling capabilities of the indets command, which is truly exciting. Your explanation of convertsys applications has significantly enhanced my grasp of this command—thank you again for your enthusiastic help! To further master this technique, I’d like to know how to distinguish whether an issue stems from local versus global variables. Are variables displayed in command outputs always considered local variables?

@Preben Alsholm 
I’m truly delighted to see your Maple program on synergistic analysis — it's absolutely brilliant. I’ve learned a lot from it, especially how to approach the solution process. Your code is concise, elegant, and beautifully written. Thank you so much for sharing it.

However, I’m still unsure how to properly choose the linear auxiliary function and convergence-control parameter when solving periodic functions. May I also ask if you happen to have any other programs related to synergistic analysis for solving nonlinear vibration problems?

@acer 

Thank you very much for your reply — it resolved something that had been confusing me for quite some time. I was caught up with work recently and forgot to respond, my sincere apologies!

From your code example, I learned that if I want both conditions to be numeric, I need to group them together using parentheses in order to apply negation to both at the same time. I also realized that the not operator only negates the first part unless parentheses are used.

Thank you again for your helpful response — much appreciated!

@acer 

I have a question about the second conditional approach. As mentioned earlier, the command I wrote was intended to delay evaluation when i is not numeric but ii is numeric.
if not i:: numeric and  ii::numeric then  return 'procname'(args); end if：
However, after testing the code, I found that it seems to behave the same as before — it does not actually delay evaluation as expected.
Additionally, I also tried modifying the command based on the previous logic, but that still didn't achieve the effect of delaying the evaluation. This has left me a bit confused, and I’m not sure why it didn’t work as intended.

if not i::numeric and not ii::numeric  then  return 'procname'(args); end if：

@mmcdara 

Thank you so much for providing this method — it's truly impressive how it allows all four curves to be plotted simultaneously. It's a clever and elegant approach, and I really appreciate it. Through the code you shared, I also learned a lot about Maple’s plotting commands — it's genuinely excellent and educational.

At the same time, I’d like to highlight the explanation given by the other expert above regarding the cause of this issue. I sincerely recommend taking a look at it as well — it really helped clarify the confusion.

I'm genuinely happy and grateful to receive such helpful replies. It feels incredibly warm and encouraging to be part of such a supportive community. Once again, thank you very much for your detailed and thoughtful response!

@acer 
Thank you very much for your guidance — it truly helped me understand the reason why my plot command wasn't working as expected! Before reading your reply, I was quite confused and had spent a long time checking my code, thinking there was no issue. Only after seeing your explanation did I realize that the procedure was first performing symbolic operations (including sorting) before the numeric values were substituted for plotting.

I'm also very grateful for the three methods you provided along with the clear explanations. They were incredibly helpful! I personally found the first two approaches to be particularly effective and more intuitive for achieving accurate plotting results.

Once again, thank you sincerely for taking the time to provide such a detailed and thoughtful response. It truly resolved my confusion!