Closed modelica-trac-importer closed 6 years ago
Modified by mtiller on 7 Oct 2008 18:14 UTC
Modified by mtiller on 7 Oct 2008 18:15 UTC
Comment by AHaumer on 17 Nov 2008 15:46 UTC In fact this should also work with non-differentiable signals (e.g. sawtooth). Additionally, it should be possible to reinit min resp. max after a period of time, if you want to detect min and max of a periodic signal during the last period = 1/f.
Comment by HansOlsson on 17 Nov 2008 16:04 UTC Many variants exist for implementing this, unfortunately they do not work well – except for sampling the signal, or using when y<0 in case of continuous signals. Comparing step-values only finds the min/max on the step after the min/max. Part of the problem is that normal root-finding ode-solvers does not include this capability; they only look at g(.) and finds roots of these functions – finding the min/max during the step requires another interface; which would influence interfaces to e.g. Simulink.
The proposed solution is a post-processing function, similar to e.g. the delay-operator, but preferably with the possibility to handle discontinuities.
Comment by mtiller on 17 Nov 2008 16:28 UTC Hans,
I'm not quite sure what to make of your comment. Are you saying that you recognize the need for such functionality? The main argument I have for including this in the language is that it is something that can only be implemented properly by a tool because only the tool has access to the solver side information required (e.g. events, extrapolated solutions, etc). It sounds to me like you are acknowledging these facts but I'm not entirely sure.
Comment by HansOlsson on 17 Nov 2008 16:34 UTC The point is that triggering an event for min/max requires changes in integration interfaces that are not possible.
Finding min/max for a signal in an interval can be done in a simple way, and use an operator similar to delay.
Comment by AHaumer on 30 Sep 2009 08:43 UTC Actually there's a practical application: Detetcting demagnetization of a permanent magnet. One can approximate the characteristic by 2 straight lines (the normal working line with small slope, and the demagnetization line with big slope) separated by a knee point:
[[Image(Demag.jpg)]]
[attachment:Demag.jpg]
When MMF falls below the knee point (i.e. on the steep demagnetization line), we have to remember the lowest MMF as new kneepoint. When MMF starts to rise again, we move on a new normal working line (with small slope) starting from the new kneepoint. To take into account also non-differentiable time behavuíour of MMF, I figured out the following test example (but I suppose it's not optimal):
model DetectDemag
parameter Real MMF0=-1;
parameter Real PHI0= 0;
parameter Real MMF1=-0.75;
parameter Real PHI1= 0.75;
parameter Real MMF2= 0;
parameter Real PHI2= 1;
final parameter Real slopeA=(PHI1-PHI0)/(MMF1-MMF0);
final parameter Real slopeB=(PHI2-PHI1)/(MMF2-MMF1);
parameter Real eps=1E-3;
Real MMF;
output Real PHI;
discrete Real MMFknee(start=MMF1);
discrete Real PHIknee(start=PHI1);
equation
MMF= -0.5 + 0.4*sin(2*Modelica.Constants.pi*2*time);
when MMF<(pre(MMFknee)-eps) then
MMFknee=MMF;
PHIknee=PHI0+slopeA*(MMFknee-MMF0);
end when;
PHI=if MMF<MMFknee then PHI0+slopeA*(MMF-MMF0) else
PHIknee+slopeB*(MMF-MMFknee);
end DetectDemag;
Comment by dietmarw on 26 Nov 2009 09:11 UTC Was not discussed.
Modified by ahaumer on 20 Aug 2012 13:02 UTC
Changelog removed by ahaumer on 20 Aug 2012 13:02 UTC
Comment by ahaumer on 21 Aug 2012 08:09 UTC Since I again stumbled upon the problem of maximum detection, here's a simpler stable code (but not really performant):
block HoldMax
extends Modelica.Blocks.Interfaces.SISO;
parameter Real eps=1e-3;
protected
discrete Real x;
equation
when u>pre(x)+eps then
x=u;
end when;
y=x;
end HoldMax;
I do not understand why some problems come up again and again, and they seem to be never solved ...
Comment by dietmarw on 21 Aug 2012 08:19 UTC Well it was never properly discussed at a design meeting. I guess that's the real problem.
Comment by ahaumer on 13 Mar 2014 08:41 UTC There's one more idea: have a special time event type which doesn't really behave like an event but results are interpolated at this point in time without interrupting the solver and iteration. One could simply sample the results (for detection of min / max, performing an FFT, and many more - esp. signal processing) at these special "events" (where nothing else regarding the dynamic behaviour happens).
Modified by beutlich on 16 May 2014 15:06 UTC
Comment by hansolsson on 23 Jun 2016 12:59 UTC Housekeeping to make it easier to find the active tickets for the specification.
These tickets are all expired, i.e. old with no action - and not clear that any action is needed. In most cases they are enhancements/discussions without any clear result.
Comment by beutlich on 16 Aug 2016 11:00 UTC Just some more cross-references that this is a hot topic:
Comment by dietmarw on 26 Aug 2016 06:21 UTC House keeping.
Modified by mtiller on 7 Oct 2008 18:14 UTC A frequent requirement is to either record or detect when a minimum or maximum has occurred in a signal. The two use cases are captured in these examples:
The recordMax and recordMin are convenience routines since they could be implemented using code fragments such as:
The important point here is that this requires integration with an underlying solver. When the solver either constructs polynomial approximations for the solutions and/or processes events that change the value of the signal being analyzed the it can trigger the detectMin and detectMax events.
Reported by mtiller on 7 Oct 2008 18:13 UTC A frequent requirement is to either record or detect when a minimum or maximum has occurred in a signal. The two use cases are captured in these examples:
The recordMax and recordMin are convenience routines since they could be implemented using code fragments such as:
The important point here is that this requires integration with an underlying solver. When the solver either constructs polynomial approximations for the solutions and/or processes events that change the value of the signal being analyzed the it can trigger the detectMin and detectMax events.
Migrated-From: https://trac.modelica.org/Modelica/ticket/109