MSL 3.2.3 FFT function does not work correctly

[casella]

The ​Modelica.Math.FastFourierTransform.Examples.RealFFT1 model calls the Modelica.Math.FastFourierTransform.realFFT function, which apparently returns only zero values, since the simulation results and the saved files only contain zero amplitude and phase values for all frequency.

I'm not sure what exactly goes wrong in the chain of calls that ultimately calls the external C function ModelicaFFT_kiss_fftr(), this should be further investigated.

[perost]

The RealFFT function is called at time point 4.975s in the simulation, after which the elements of both Ai and Phii become non-zero. The results returned from the function does not match those in the reference results, e.g. Ai[1] becomes 0.0325 instead of 5.0, but the function does at least return something non-zero.

I can't really tell where it goes wrong since it gives the same results with both the frontends, so I've got nothing to compare against. This probably needs someone who knows more about this kind of models to take a look at it.

[casella]

Replying to perost:

The RealFFT function is called at time point 4.975s in the simulation, after which the elements of both Ai and Phii become non-zero. The results returned from the function does not match those in the reference results, e.g. Ai[1] becomes 0.0325 instead of 5.0, but the function does at least return something non-zero.

If I run the example from OMEdit Ai and Phii are displayed as constant zeros. Also the saved .mat file has all zeros in the second and third column. I'm running OMEdit v1.14.0-dev-45-g9f3d0f7c (64-bit) connected to v1.14.0-dev-114-gb5e109e1b (64-bit).

Where do you see those non-zero values?

I can't really tell where it goes wrong since it gives the same results with both the frontends, so I've got nothing to compare against. This probably needs someone who knows more about this kind of models to take a look at it.

If you look at the documentation layer, it's pretty clear. The signal y is the superposition of a constant and of two sinusoids, so when you compute the FFT, the Ai's at the corresponding frequencies are expected to have the value of the amplitude of the component, while all other components should be zero.

[perost]

Replying to casella:

Where do you see those non-zero values?

You can see them in the link you posted yourself, see for example ​Ai[1].

[casella]

Replying to perost:

Replying to casella:

Where do you see those non-zero values?

You can see them in the link you posted yourself, see for example ​Ai[1].

You are right, sorry, I forgot about that. In fact, there is an inconsistency between the results obtained on Linux via scripts (reported by Hudson) and on Windows from OMEdit, which I reported in this ticket.

Maybe this gives some additional hints so as to where the problem is?

[casella]

OMC 2.0.0 should run all the MSL correctly, so I'm marking this as a blocker.

[casella]

Try to get 100% MSL coverage with 1.14.0

[lochel]

I discussed it briefly with Martin and it seems to be a rather complicated fix. It will be postpone for now.

[casella]

Rescheduled for 2.0.0