Opened 6 years ago
Last modified 6 years ago
#5350 new defect
MSL 3.2.3 FFT function does not work correctly
| Reported by: | Francesco Casella | Owned by: | Martin Sjölund |
|---|---|---|---|
| Priority: | blocker | Milestone: | 2.0.0 |
| Component: | Run-time | Version: | |
| Keywords: | Cc: | Lennart Ochel, Karim Adbdelhak, Andreas Heuermann, Niklas Worschech |
Description
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.
Change History (9)
follow-up: 2 comment:1 by , 6 years ago
follow-up: 3 comment:2 by , 6 years ago
Replying to perost:
The
RealFFTfunction is called at time point 4.975s in the simulation, after which the elements of bothAiandPhiibecome 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.
follow-up: 4 comment:3 by , 6 years ago
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].
comment:4 by , 6 years ago
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?
comment:5 by , 6 years ago
| Priority: | high → blocker |
|---|
OMC 2.0.0 should run all the MSL correctly, so I'm marking this as a blocker.
comment:7 by , 6 years ago
| Cc: | added; removed |
|---|
comment:8 by , 6 years ago
I discussed it briefly with Martin and it seems to be a rather complicated fix. It will be postpone for now.
The
RealFFTfunction is called at time point 4.975s in the simulation, after which the elements of bothAiandPhiibecome 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.