Save the file on your hard drive (not as a MapleSim attachment). Open Maple, enter the procedure assignment I suggested, and call it using the name of the saved file.  You will have to get the path right.  So the call will look like (on linux)

flatten( "/home/joe/tmp/basisFunction.mo", "basisFunction");

Here's what the equations flatten to (there are no variables, so everything fully evaluates in the flattener):

0 = 1/25,
1 = -.100000000000000000,
1 = -.500000000000000000e-1,
1 = -.200000000000000000e-1,
1 = -.100000000000000000e-1,
1 = 0.,
1 = .100136269596007174e-12707,
1 = .100000000000000000e-1,
1 = .200000000000000000e-1,
1 = .50000000000000000e-1,
1 = .100000000000000000

Clearly there are consistency issues.

I'm going to assume that the Modelica bug is for a particular vendor's Modelica parser, in which case it probably isn't an issue here since MapleSim has its own parser.

@rwong1231 A minor detail. I misread your original post.  The period and amplitude of the SawTooth should be 10 (or whatever the duration of time data is). Depending on what the signal is driving, you might find it helpful if the value of the starting and ending points are identical, to ensure continuity.

@rwong1231 A minor detail. I misread your original post.  The period and amplitude of the SawTooth should be 10 (or whatever the duration of time data is). Depending on what the signal is driving, you might find it helpful if the value of the starting and ending points are identical, to ensure continuity.

@Mac Dude LibraryTools:-Save is a higher-level version of ?savelib.  I find Save generally easier to use.  It doesn't overwrite the file; you can save multiple packages to the same archive, however, unless you have a script to do so all at once, I would avoid doing so. The reason is that occasionally something goes wrong and you have to recreate the archive. If you are using the archive for multiple packages, with no script to load them all, you'll have to load them individually, which is a needless hassle.

In my opinion, the example in the ?LibraryTools[Save] help page could be improved.  I find it generally better practice to explicity include the name of the mla to which you are saving (rather than depending on savelibname).  A problem with the latter is that if you forget to assign it, it frequently points to your main Maple archive and then writes there, if it has write permission. Actually, that's how ?savelib works; Save is better behaved.

If you are experiencing any weird issues with libraries, such as you know you've updated an archive but it appears to be using an old version, try using ?LibraryTools[FindLibrary] to see where Maple finds your code.

Acer's suggestion to save your source code as a text file is excellent.  Besides allowing the use of version control (I recommend git) it also permits using a decent code editor.

@Mac Dude LibraryTools:-Save is a higher-level version of ?savelib.  I find Save generally easier to use.  It doesn't overwrite the file; you can save multiple packages to the same archive, however, unless you have a script to do so all at once, I would avoid doing so. The reason is that occasionally something goes wrong and you have to recreate the archive. If you are using the archive for multiple packages, with no script to load them all, you'll have to load them individually, which is a needless hassle.

In my opinion, the example in the ?LibraryTools[Save] help page could be improved.  I find it generally better practice to explicity include the name of the mla to which you are saving (rather than depending on savelibname).  A problem with the latter is that if you forget to assign it, it frequently points to your main Maple archive and then writes there, if it has write permission. Actually, that's how ?savelib works; Save is better behaved.

If you are experiencing any weird issues with libraries, such as you know you've updated an archive but it appears to be using an old version, try using ?LibraryTools[FindLibrary] to see where Maple finds your code.

Acer's suggestion to save your source code as a text file is excellent.  Besides allowing the use of version control (I recommend git) it also permits using a decent code editor.

Please show what you've done.  Either paste in the input (as text), or use the green up-arrow to upload a worksheet that has the problem.

@asghar You must be using an older Maple, ?numelems was introduced in Maple 15. Use ?nops.  As I mentioned earlier, the getSizeList procedure you had is exceptionally poorly implemented. I suppose it doesn't matter for class work, but still, it's really bad (it's O(n) instead of O(1)).  At least it isn't O(n^2).

@asghar You must be using an older Maple, ?numelems was introduced in Maple 15. Use ?nops.  As I mentioned earlier, the getSizeList procedure you had is exceptionally poorly implemented. I suppose it doesn't matter for class work, but still, it's really bad (it's O(n) instead of O(1)).  At least it isn't O(n^2).

laughing.  thanks.

laughing.  thanks.

No, there isn't any exposed library code for this.  The functionality undoubtedly exists, in some form, inside the Maple library, however, it probably is not a stand-alone procedure that is readily accessible and documented, meaning there is no guarantee it would be there with the next release.  You are better served using your own procedure for this task.

No, there isn't any exposed library code for this.  The functionality undoubtedly exists, in some form, inside the Maple library, however, it probably is not a stand-alone procedure that is readily accessible and documented, meaning there is no guarantee it would be there with the next release.  You are better served using your own procedure for this task.

@Markiyan Hirnyk Replacing the symbol p with the explicit expression in terms of x does work [inside a procedure], that is how seq is intended to be used. But that  modification defeats the purpose of the operation, which is to check whether the results satisfy p.  That is the reason that you haven't seen this approach before.

@Markiyan Hirnyk Replacing the symbol p with the explicit expression in terms of x does work [inside a procedure], that is how seq is intended to be used. But that  modification defeats the purpose of the operation, which is to check whether the results satisfy p.  That is the reason that you haven't seen this approach before.

@Markiyan Hirnyk No offense, but the timing difference is largely irrelevant.  That is, if this operation were going to be executed many times, it would most likely be inside a procedure---particularly if speed were a concern.  But the statement (seq(p, x=sol1)) doesn't work inside a procedure, not unless p is declared as global, which is unlikely and poor practice. I'm biased because of the way I use Maple. The method you propose is handy at the top-level because it's terse, but not useful for Maple coding.