Alas, that won't be terribly efficient.

I don't know of any reasonable way to do this using ListTools.  You can make a small improvement by doing

S := sort([indices(T,'nolist')]);

Assuming L consists of nonnegative integers, the more interesting way to do this is

sort(add(x^i, i=L),'ascending')

The production of the sorted structure is fast, but by the time the polynomial is converted to a listlist, I don't believe there is any savings.  The code could be a bit shorter, but the applicability is restricted. However, if you don't need to access all the elements, it could be useful.

@onder What version of MapleSim are you using?  With MapleSim 5, running the model you sent with no changes, it ran here in 10 seconds.

@onder What version of MapleSim are you using?  With MapleSim 5, running the model you sent with no changes, it ran here in 10 seconds.

@onder No, those settings (ZoH)  would only affect run-time.  The "system is inconsistent" error occurs during equation generation. Unreferencing an array (I cannot read your question when replying, so ... ) and connecting it to a signal i/o is fine, you don't need an array type at the other end.

When you disable a block, the connections to it must also be disabled (a minor nusiance).

@onder No, those settings (ZoH)  would only affect run-time.  The "system is inconsistent" error occurs during equation generation. Unreferencing an array (I cannot read your question when replying, so ... ) and connecting it to a signal i/o is fine, you don't need an array type at the other end.

When you disable a block, the connections to it must also be disabled (a minor nusiance).

Alas, diagnosing inconsistent equations isn't easy; depending on how they were reduced, it can be hard to tell what precisely is causing the inconsistency.  In this case it appears as though distinct values have been computed for `Main.valueFunction1.bPen[10]`(t).  Probably some other block (to which the basisFunction block is connected) is attempting to enforce a value for `...bPen[10]` (10th component of the bPen array). With loops, which this model has, the actual cause could be any signal in the loop.  Maybe you can break loops to isolate the probem?

For example, if I disable the the basisFunction block, and signals that connect to it (by highlighting and clicking the enable/disable button [the circle with red slash]), I still get an "inconsistent system" error.  This suggests the error is elsewhere.  Keep disabling portions of the overall circuit, that should allow you to narrow the search.

Alas, diagnosing inconsistent equations isn't easy; depending on how they were reduced, it can be hard to tell what precisely is causing the inconsistency.  In this case it appears as though distinct values have been computed for `Main.valueFunction1.bPen[10]`(t).  Probably some other block (to which the basisFunction block is connected) is attempting to enforce a value for `...bPen[10]` (10th component of the bPen array). With loops, which this model has, the actual cause could be any signal in the loop.  Maybe you can break loops to isolate the probem?

For example, if I disable the the basisFunction block, and signals that connect to it (by highlighting and clicking the enable/disable button [the circle with red slash]), I still get an "inconsistent system" error.  This suggests the error is elsewhere.  Keep disabling portions of the overall circuit, that should allow you to narrow the search.

This is another case where the useful error message is being replaced with a less helpful generic message.  Currently the engine doesn't handle (nor ignore) attributes on equations.  For example, you have

phi = flange_a.phi "Position state";

The string at the end is a Modelica annotation.  It is legal and should be allowed, but that's causing the problem (the standard Modelica library does not annotate equations, so we hadn't seen this before).  Remove those from your Modelica source files (you can leave the annotations for parameters and variables).  Your best bet is to convert them to comments:

phi = flange_a.phi; // "Position state";

This is another case where the useful error message is being replaced with a less helpful generic message.  Currently the engine doesn't handle (nor ignore) attributes on equations.  For example, you have

phi = flange_a.phi "Position state";

The string at the end is a Modelica annotation.  It is legal and should be allowed, but that's causing the problem (the standard Modelica library does not annotate equations, so we hadn't seen this before).  Remove those from your Modelica source files (you can leave the annotations for parameters and variables).  Your best bet is to convert them to comments:

phi = flange_a.phi; // "Position state";

The problem is that the theta_r, theta_p, and s parameters of the basisFunction model are public (that's the default) and so the GUI allows the user to modify these. There is a bug in the code that munges the parameter names.  To work around this, specify that those parameters are protected. In the Modelica source for basisFunction, add a protected keyword right before the parameter declaration.  Because the model interfaces follow, add a public keyword to re-expose them.  Here is the appropriate snippet:

protected
  parameter Real theta_r[sn]=linspace(-0.3, 0.3, sn) "Generates sn values for position";
  parameter Real theta_p[sn]=linspace(-1, 1, sn) "Generates sn values for velocity";
  parameter Real s[1,2]=[(theta_r[2]-theta_r[1])/1.7,(theta_p[2]-theta_p[1])/1.7];
public
  Modelica.Mechanics.Rotational.Interfaces.Flange_a flange_a ;
  Modelica.Blocks.Interfaces.RealOutput bPen[sn * sn] ;

To get this to work, regenerate the block and save the worksheet and msim file. Then delete the old basisFunction1 block from the model.  Insert the new basisFunction model.  You may have to close and restart MapleSim before inserting the new basisFunction model---I'm not sure about that, but if you still see the now protected parameters in the parameter inspector, try exiting.

With that change I got other errors (incompatible structure size). I haven't looked at that; its resolution may be apparent to you.

Followup

Only parameter s needs to be protected. The problem is that its default value depends on components of theta_r and theta_p, which cause the problem.  Leaving theta_r and theta_s exposed allows you to modify their values.

The problem is that the theta_r, theta_p, and s parameters of the basisFunction model are public (that's the default) and so the GUI allows the user to modify these. There is a bug in the code that munges the parameter names.  To work around this, specify that those parameters are protected. In the Modelica source for basisFunction, add a protected keyword right before the parameter declaration.  Because the model interfaces follow, add a public keyword to re-expose them.  Here is the appropriate snippet:

protected
  parameter Real theta_r[sn]=linspace(-0.3, 0.3, sn) "Generates sn values for position";
  parameter Real theta_p[sn]=linspace(-1, 1, sn) "Generates sn values for velocity";
  parameter Real s[1,2]=[(theta_r[2]-theta_r[1])/1.7,(theta_p[2]-theta_p[1])/1.7];
public
  Modelica.Mechanics.Rotational.Interfaces.Flange_a flange_a ;
  Modelica.Blocks.Interfaces.RealOutput bPen[sn * sn] ;

To get this to work, regenerate the block and save the worksheet and msim file. Then delete the old basisFunction1 block from the model.  Insert the new basisFunction model.  You may have to close and restart MapleSim before inserting the new basisFunction model---I'm not sure about that, but if you still see the now protected parameters in the parameter inspector, try exiting.

With that change I got other errors (incompatible structure size). I haven't looked at that; its resolution may be apparent to you.

Followup

Only parameter s needs to be protected. The problem is that its default value depends on components of theta_r and theta_p, which cause the problem.  Leaving theta_r and theta_s exposed allows you to modify their values.

Some of the contents of the msim file were corrupted.  I recovered what I could and put them back.  Most of the attachments were recovered: recover.msim

Some of the contents of the msim file were corrupted.  I recovered what I could and put them back.  Most of the attachments were recovered: recover.msim

I don't know the cause, though have seen an "invalid file format" occasionally.  If you need the file back, I might be able to recover it (no guarantees) if you upload it (use the green arrow, here).