Uploading your worksheet would help.  Use the green arrow.

@acer Yes, that appears to be true.  A little digging around indicates that the problem is caused by a single line in the plots/display routine (an unfortunate call to indets, which is exceptionally memory intensive). It appears that there is no reason to use ?indets here, ?select, which doesn't recurse into the structure, should do the trick.  I'll pass this along. 

For those who might not be aware, it is easy to create a custom version of ?identify that properly handles Digits while retaining the caching function. The techique used here is to include Digits as an otherwise unused argument to a local procedure that has the ?cache option. A call to forget clears the remember table of identify.

Identify := module()
local ModuleApply, Identify;

    ModuleApply := proc(x)
        Identify(x, Digits, _rest);
    end proc;
    
    Identify := proc(x, digits)
    option cache;
        forget('identify');
        identify(x, _rest);
    end proc;
    
end module:

s := 1.218041583332573:
Identify(s);
                               1.218041583332573

Digits := 15:
Identify(s);
                                    1/2   3
                                   2    Pi
                                   --------
                                      36

Digits := 14:
Identify(s);
                               1.218041583332573

I don't know what you mean by "updates all text".  Maybe you could upload a worksheet that illustrates the problem. Click the green arrow when replying to upload stuff.

I don't know what you mean by "updates all text".  Maybe you could upload a worksheet that illustrates the problem. Click the green arrow when replying to upload stuff.

Hello Ivar,

You can create, for example, a model in which the spring constant varies with length.  Alas, doing so the easy way, by inserting an expression into the value of the 'c' parameter, is not guaranteed to work.  It might; however, as I mentioned, that cannot be depended upon.  The following briefly explains the issues.

MapleSim uses the Modelica model description language to generate the model and then parses it to generate the equations. Modelica does not permit time-varying parameters. Consider, for example, the model of an electrical capacitor.  Internally, the current/voltage relationship is expressed as

  i = C*der(v)

where i is the current through the capacitor, v the voltage across it, and C the capacitance (a parameter).  The function der means the derivative with respect to time.  If a user provided an expression for C that varied with v, say, C = C0*v/V0, the resulting expression would be

  i = C0/V0*v*der(v)

That, however, is incorrect.  What is actually desired is the equation

 i = der(C*v) = C0/V0*der(v^2) = 2*C0/V0*v*der(v)

The problem arises because the differential equation for the capacitor assumes that C is fixed---that was done because it is a parameter and Modelica parameters are not permitted to vary during a simulation. 

That the MapleSim GUI currently permits inserting an arbitrary expression as a component parameter is an oversight---it will occasionally work but may result in invalid results depending on the model internals.  I strongly advise against it.

There are a few ways to avoid this issue.  You can create a custom component, using the Custom Component Template.  You can also use the Force 2 component (under 1D Mechanics -> Translational -> Motion Drivers) which provides a signal input that varies the force applied between two flanges.  Use signal blocks to create the appropriate algebraic expression as the input.

Hello Ivar,

You can create, for example, a model in which the spring constant varies with length.  Alas, doing so the easy way, by inserting an expression into the value of the 'c' parameter, is not guaranteed to work.  It might; however, as I mentioned, that cannot be depended upon.  The following briefly explains the issues.

MapleSim uses the Modelica model description language to generate the model and then parses it to generate the equations. Modelica does not permit time-varying parameters. Consider, for example, the model of an electrical capacitor.  Internally, the current/voltage relationship is expressed as

  i = C*der(v)

where i is the current through the capacitor, v the voltage across it, and C the capacitance (a parameter).  The function der means the derivative with respect to time.  If a user provided an expression for C that varied with v, say, C = C0*v/V0, the resulting expression would be

  i = C0/V0*v*der(v)

That, however, is incorrect.  What is actually desired is the equation

 i = der(C*v) = C0/V0*der(v^2) = 2*C0/V0*v*der(v)

The problem arises because the differential equation for the capacitor assumes that C is fixed---that was done because it is a parameter and Modelica parameters are not permitted to vary during a simulation. 

That the MapleSim GUI currently permits inserting an arbitrary expression as a component parameter is an oversight---it will occasionally work but may result in invalid results depending on the model internals.  I strongly advise against it.

There are a few ways to avoid this issue.  You can create a custom component, using the Custom Component Template.  You can also use the Force 2 component (under 1D Mechanics -> Translational -> Motion Drivers) which provides a signal input that varies the force applied between two flanges.  Use signal blocks to create the appropriate algebraic expression as the input.

@Alejandro Jakubi As Alejandro points out, Maple uses DAGs internally to represent expressions. Check out the ?ToInert and ?FromInert procedures, which convert Maple expressions to and from inert expressions, using unevaluated function calls as the data structure.

@Alejandro Jakubi As Alejandro points out, Maple uses DAGs internally to represent expressions. Check out the ?ToInert and ?FromInert procedures, which convert Maple expressions to and from inert expressions, using unevaluated function calls as the data structure.

It installs and runs on Linux 64.  Thanks for this practical utility.

I ran into two minor issues during installation. First, after selecting File -> Open to open the .mla file, I forgot to select the extension type (*.mla), so could not initially find the file where I downloaded it.  My mistake.  Second, after starting the installation, the dialog that opened had a "cancel" button but no "next" button.   Turns out the default dialog box size was too narrow on my machine, so the "next" button, which exists, does not appear unless the window is manually widened.  Took me a while to figure that out. This can be avoided by setting width=1000 when constructing the installer.

Your use of eventclear is cleaner than my use of initial.  Here is a slight tweak to the loop

A := Array():
Sol('eventenable'={1});
for cnt do
    tfired := eval(t, Sol(t1));
    if tfired >= t1 then break; end if;
    A(cnt) := tfired;
    Sol('eventclear'):
end do:

Your use of eventclear is cleaner than my use of initial.  Here is a slight tweak to the loop

A := Array():
Sol('eventenable'={1});
for cnt do
    tfired := eval(t, Sol(t1));
    if tfired >= t1 then break; end if;
    A(cnt) := tfired;
    Sol('eventclear'):
end do:

@faribasj Right click the Generate Procedure button, then click Edit.  Modify the statement

simfunc := eval(MapleSim[MapleSimTemplate][BuildProcedure](simModelRecord, SimOpts));

to

simfunc := eval(MapleSim[MapleSimTemplate][BuildProcedure](simModelRecord, SimOpts, maxcomponent=7));

You should then be able to correctly build the procedure.

Addendum:

Because preformatted lines don't wrap, you may not be able to see the entire line above. You should be able to cut and paste it, however, so that you know, I added the option maxcomponent=7 in the call to BuildProcedure.

@faribasj Right click the Generate Procedure button, then click Edit.  Modify the statement

simfunc := eval(MapleSim[MapleSimTemplate][BuildProcedure](simModelRecord, SimOpts));

to

simfunc := eval(MapleSim[MapleSimTemplate][BuildProcedure](simModelRecord, SimOpts, maxcomponent=7));

You should then be able to correctly build the procedure.

Addendum:

Because preformatted lines don't wrap, you may not be able to see the entire line above. You should be able to cut and paste it, however, so that you know, I added the option maxcomponent=7 in the call to BuildProcedure.

@PatrickT Maple lists are not limited to 100 elements.  Rather, the following operation raises an error with a list of more than 100 elements:

L := [seq(1..101)]:
L[1] := 0;
 Error, assigning to a long list, please use Arrays

The error message is confusing. What is happening here is that the assignment 

L[1] := 0;

is 'sort-of' modifying the first element of the list L.  However, it cannot actually do that, regardless the length of the list. Maple lists (and sets, and most data structures with the exceptions of tables and rtables) are immutable. Once created, they cannot be modified. At one time the above operation was not allowed in Maple (regardless the size of the list). A later release changed this so that if the list is small enough (100 elements or less), Maple would permit the operation. It still does not actually change the original list.  Rather it creates a new list with a different first element (now 0) and assigns it to L. The reason for the abitrary limit is that creating an entirely new list is inefficient. Without the warning a user might wonder why his bubble-sort routine is running in O(n^4) time. If you really want to be changing elements in a structure, then you should be using a mutable data structure (probably an rtable, i.e., Array).

That long-winded explanation does not directly answer the more pressing question as to why an Array was used and then later converted to a list---so here's another.  First the easy part.  The reason for converting to a list was simply because you  had originally requested a list as output. If an Array will suffice---and it seems as though it might---then that conversion can be eliminated.  

The reason for using an Array rather than a list to record the times is also due to the immutability of lists.  The typical way to create a list in such an application (a loop) is to create an entirely new list each time an element needs to be appended.  That generates a lot of unused data (the old lists) that must later be garbage collected. In a loop, that process is O(n^2) in time and space, meaning the processing time and memory usage is proportional to the square of the number of elements in the final list, assuming a new element is added one at a time.  For small n that inefficiency is insignificant in the scheme of things, however, for large n it can dominant a computation.  For older Maples, the usual way to avoid this in a loop is to use a table.  With newer Maples one can use a dynamically resizable Array.  Here I chose to use a dynamically resizable Array to illustrate its use.  The trick is to assign a new element using parentheses where you would normally use square brackets.