@mmcdara 

Perhaps the OP refers to the magnitudes of the oscillating variables that reach a steady state.
What would the spectrum look like in a chaotic system? Could it ever reach a steady state.

I assume that you want to sweep Omega and leave the rest of the parameters in data and data1 constant.

Can you give a sweeping range?

Since it is a nonlinear system: Do you want to sweep F__1 as well or can we assume it to be constant?

2. is unclear: Do you want the steady state of the magnitude of the variables x and Theta be the new initial conditions for the same variables at a new frequency?

@acer

Factoring goes beyond my original post, but I did not want to ask a new question about it.

A lot of content to study. Thank you!

@acer 

I have feared that a solution would be sophisticated. Your code sheds light on the algorithmic finesse required for simple sounding tasks. The output looks much nicer without "(-", is shorter and vertically better alligned.

Intuitively I had hoped that simplify/size would do the same but maybe the internal way to determine size is not affected by "(-".  Also 2 could have been factored out since Maple does not automatically  expand 2*c*(a+b) as compared to 2*(a+b) but the command factor does not do that. You codes does it partially. Simplify size is also not effective but works on 2*c*a+2*c*b.

As a curiosity, I have attached another way which only works with equation labels

Format_odes_with_predefined_expressions.mw

But entering predefined expressions is half way to enter everything by hand.

The map(print,list) comes, when I use it, with an extra empty list. Not sure what I am doing wrong here.

ps.: the odes are an extract of output from Physics:-LangrangeEquation which comes as a sequence. I have adopted here what I saw in many dsolve examples: defining odes, ICs and BCs as sequences for later use in a dsolve call > dsolve([odes,ICs]). A habit...

To what I see it is not realy hanging. Maple tires someting in \`ODEtools/fc/modResultant\` involving expression with F and C and applying mod of huge integers to it.
Maybe that is the correct approach to find a solution but takes ages and should/should not(?) be interrupted.

The quick answer from the other program raises the question whether look-up tables are involved (does Maple use such tables at all?).

@dharr 

Occasionally I experience moderate delays as if some files cannot be opend or saved immediately. A system service with high priority can cause this (like a virus scanner). Hard to find out.

@acer 

All the above is a substantial collection of unexpected/inconsistent output.

I must have been extremely lucky in the past using sequences without brackets not running into this kind of problems. I will "bracket-up" in the future to stay away from surprises.

I have send a notice to support that they have a look. After all, add is an important command that should be used in a safe way.

I will leave the remaining question about the usefulness of adding operands (any other than operands of a sum) open for the future.

You mean Maple drawing a block diagram?

Cool idea.

@Carl Love 

Yes. All worksheets/tabs were corrupted (also newly opend ones). I had to exit Maple.

@acer 

Yes, allways. Adding to the above

Whatever add gets from the GUI is processed differently than what is stored internally. Somehow the GUI must decode the equation label not equal/equivalent to the value of S. I hope this observation is only relevant for sequences...

@Carl Love 

I use practically all formatting options.

My computer and Maple sessions run over days, interrupted by energy saving and hibernation, and I only do reboot for maintance or when performance degrades.

Zoom 100% is my default and I rarely zoom. I will pay attention whether zomm has an effect.

I do not remember having this with earlier versions.

I had 3+ Maple seesions runing when I observed this and only one was affected.

Display seettings change between office and home.

@acer

I finally understand now some error messages of commands when I forget to put brackets. I new how to fix the errors but the messages did not make sense to me. This flattenting of proc(x,y) vs S1,S2 explains alot. For some reasons I only use the latter but never the former.

I have also seen some differences compared to commands when applying add (apply command) via the context pannel to sequences. An error message is thrown (edit: in some instances). A good thing with the context pannel is that adding elements is only offered for lists and sets. All this prevents use errors.

whattype reveals that the minimum requirement for an expression sequence is: "Two there should be".

I though my first example adressed units sufficiently.

Anyway, all this was very helpfull and I hope MapleSoft considers some of it for future users

As so often, thank you for your tiime and patience!

@acer 

I fear that I have not been able to express myself sufficiently.
In software it is difficult to adress all possible use errors. This one occured in combination of units and add(sequence): add(sequence) worked fine before (but not with units).

Why was not obvious for me from the help page and also support could not spot the use error in a first iteration (concluding that this a bug).

After clarification I tested the use of sets, list and arrays with units with one element an excluded this solution in my original post. I should have made this clear.

The question I wanted to adress: Can this use error happen to other users and is it important enough to be adressed? I still cannot answer this. Hence this post.

I have further described my difficulties with the help page. Also here the question is: Do other users have the same difficulties and is it important enough to be adressed? I have also searched for a usefull example where adding operands makes sense. This seems to be a new functionality (which can come with new errors). Regarding the help page, support agreed that missinterpretation and use errors are possible and further examples would be helpfull.

If we leave the discussion as is, some might conclude that the user is the error (I have heard this statement about users from non-Maple developers). Unfortunately we do not have a representative sample of test users from beginners to experts at hand to validate this.

My takeway from the discussion is that passing sequences to procedures is in general not a good practise. I must have overlooked something in the documentation (programming guide?). If someone could point me to the corresponding pages, I will study them again. Maybe I am too biased from other languages.

@acer 

Good point. To preserve the lhs to make the output selfexplaning I have to

since the following is not printing in 2D

and convert does not allow options as indexes

(1@@0=(evalf*GetUnit)@Constant@convert[name])(x);

@all
More backround:

I ran into this by the habit of removing or not using brackets (?Definition,bracket) wherever it helps improving readability.

add works on many objects, including expression sequences, by simply using add(name). Some users, as myself, would not add overhead to it without good reasons (now I have one).

The degeneration of a seqence to a scalar expression and applying add to it is maybe rare and may not justify a code change of a well proven build-in function.

On the other hand, I cannot deduce from the add help page a good practise of converting a sequence to something safe. On the contraray, the help page highlights the addition of sequences in the first sentence: "The add function is used to add up an explicit sequence of values".

In fact, since add works so well I only consulted the help page after running into this problem. Then I contacted support which required developers to investigate. After clarification that the problem is on my side I got the suggestion to discuss it here.

After your comments, it seems even more likely that applying add to a scalar expression is dispensable and potentially "dangerous".

If reworking the help page is an option to adress this, I would suggest an example with sequences. Maybe this:

add(a[i]*x^i, i = 1 .. 1);# adopted from the help page. Upper bound of range changed for example in a loop
seq(a[i]*x^i, i = 1 .. 1):# user not knowing the range option of add
add(%); 
                             a[1] x

                            a[1] + x

I would also suggest moving bullet points 8, 9 before bullet point 7 (which adresses addition of operands). My preference would still be a warning or in this case returning an expression unevaluated.

I hope the discussion helps in the general context of learning to use Maple correctly, adopting good practise and avoiding errors.