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).

@xumin If you set the message console reporting to verbose, then rerun the simulation, the following error message appears:

    maximum number of event iterations reached (100) at t=2620.4998

That indicates the integrator is having a problem resolving an event. 

Looking at the probe plots, I see that probe 7 is approaching zero asymptotically.  That signal is connected to the denominator of a divisor block, which is problematic. Fortunately, there is a simple solution.

Change the solver to an implicit scheme.  In the settings panel (right side), click solver and select rosenbrock.  Rerunning the simulation allows it to proceed to the end without an error.

@xumin If you set the message console reporting to verbose, then rerun the simulation, the following error message appears:

    maximum number of event iterations reached (100) at t=2620.4998

That indicates the integrator is having a problem resolving an event. 

Looking at the probe plots, I see that probe 7 is approaching zero asymptotically.  That signal is connected to the denominator of a divisor block, which is problematic. Fortunately, there is a simple solution.

Change the solver to an implicit scheme.  In the settings panel (right side), click solver and select rosenbrock.  Rerunning the simulation allows it to proceed to the end without an error.

@xumin Are you willing and allowed to upload the model?  If so you can use the green arrow (here) to do so.

@xumin Are you willing and allowed to upload the model?  If so you can use the green arrow (here) to do so.

@acer Your code is clean and easy to understand and doesn't use any particular Maple tricks.  I was hoping the following might run slightly faster for large lists, but if it does, it is undetectable.

palin1 := proc(L)
local i,m;
    m := iquo(nops(L),2);
    for i to m while L[i]=L[-i] do od;
    evalb(i=m+1);
end proc:
 

@acer Your code is clean and easy to understand and doesn't use any particular Maple tricks.  I was hoping the following might run slightly faster for large lists, but if it does, it is undetectable.

palin1 := proc(L)
local i,m;
    m := iquo(nops(L),2);
    for i to m while L[i]=L[-i] do od;
    evalb(i=m+1);
end proc:
 

You could linearize a Multibody model, the run the state space matrix through the custom discrete state space template and you would, indeed, get a discrete, linear model of the multibody block. However, it won't be a multibody block anymore, so won't generate visualization data. I don't know how to robustly create a 3D visualization.  For a simple model, say a pendulum, you may be able to do this by driving a partially constrained visualization element with the linearized signal.

You could linearize a Multibody model, the run the state space matrix through the custom discrete state space template and you would, indeed, get a discrete, linear model of the multibody block. However, it won't be a multibody block anymore, so won't generate visualization data. I don't know how to robustly create a 3D visualization.  For a simple model, say a pendulum, you may be able to do this by driving a partially constrained visualization element with the linearized signal.

?ExcelTools[Export] and ?writedata

?ExcelTools[Export] and ?writedata

Here's the basic idea, using discrete signals.  A discrete signal doesn't change during the integration, only at events.  You can do something similar with non-discrete signals, but in the when-statement use, say, reinit(preV[i],V[i]; reinit(V[i], i); You should be able to declare the vector generated by basisFunction as discrete (and use regular equations in the when-statement).

model Main
    parameter Integer n = 3;
    discrete Real V[n];
    discrete Real preV[n]; // stores previous values
    Boolean clock;
initial equation
    V = zeros(n);
    preV = V;
equation
    clock = sample(0,1);
    when clock then
        for i in 1:n loop
            preV[i] = pre(V[i]);
            V[i] = i;
        end for;
    end when;
end Main;

Here's the basic idea, using discrete signals.  A discrete signal doesn't change during the integration, only at events.  You can do something similar with non-discrete signals, but in the when-statement use, say, reinit(preV[i],V[i]; reinit(V[i], i); You should be able to declare the vector generated by basisFunction as discrete (and use regular equations in the when-statement).

model Main
    parameter Integer n = 3;
    discrete Real V[n];
    discrete Real preV[n]; // stores previous values
    Boolean clock;
initial equation
    V = zeros(n);
    preV = V;
equation
    clock = sample(0,1);
    when clock then
        for i in 1:n loop
            preV[i] = pre(V[i]);
            V[i] = i;
        end for;
    end when;
end Main;

Could you clarify what you mean by "Ctrl-V"? Are you thinking what is represented in LaTeX as \hat{V}?

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.