DLR Noise Lib for inclusion into MSL

[modelica-trac-importer]

Reported by dzimmer on 13 Jun 2014 15:58 UTC The DLR-Noise Lib is available under:

https://github.com/DLR-SR/Noise

It provides a generic solution for the generation of stochastic signals. As features it contains:

• event-free random number generation
• state-free filtering
• modeling of frequency characteristics
• modular composition
• user friendly

We propose its inclusion into MSL in the near future. Comments and Discussion are welcome. Contributions are also welcome in form of a pull request.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1514

[modelica-trac-importer]

Comment by beutlich on 18 Jun 2014 15:16 UTC Tickets #1336 and #1347 also deal with random number generators for MSL 3.2.2. To avoid proliferation I would prefer to have a consistent solution if Noise Lib will be included in MSL one day.

[modelica-trac-importer]

Comment by sjoelund.se on 19 Jun 2014 08:41 UTC OpenModelica says:

Could not find library Design 1.0.3, used by Noise 0.2

What library is this?

[modelica-trac-importer]

Comment by beutlich on 19 Jun 2014 08:54 UTC Replying to [comment:2 sjoelund.se]:

OpenModelica says:

Could not find library Design 1.0.3, used by Noise 0.2

What library is this?

Noise issues should be discussed at github. See here for the corresponding ticket: https://github.com/DLR-SR/Noise/issues/10

[modelica-trac-importer]

Comment by sjoelund.se on 19 Jun 2014 15:06 UTC Oh, there was a ticket for that (*goes make a comment there*). This ticket says MSL-Noise integration issues can be discussed here though...

[modelica-trac-importer]

Comment by sjoelund.se on 23 Jun 2014 14:12 UTC https://github.com/DLR-SR/Noise/issues/19 is also a fun ticket. #789 is related :)

[modelica-trac-importer]

Comment by hansolsson on 27 Jun 2014 15:07 UTC Sorry, I cannot see that this library should be included in MSL in this stage and form, and I could not easily provide this information in the evaluation form.

To me this is a library for people experimenting with noise-models and important as such (although some important functionality is missing in my opinion), but outside the scope of MSL. Thus this is not a ticket at github.

For MSL I would want a library of easy-to-use noise components for end-users, and the library does not provide that. Parts of the library can be used as a basis for an end-user library, but it will require a drastic re-think of the library. In addition there are too many abbreviations from an end-user perspective.

For an end-user it should be straightforward to drag in a noise component in their model and run it and just get a “noisy” result – without having to consider additional issues.

The reason this is not intuitive is explained below, in particular dragging in two noise-components will generate the same noise twice; and re-running the simulation will give the same result; and sometimes there will be other problems.

Roughly the library is comprised of three parts:

1. Pseudo-random-number-generators
2. Turning the basic pRNG into distributions
3. Generating signals based on the distributions

Pseudo-random-number-generators: The included pseudo-random-number generators do not include any good ones (the most known is MT19937 (developed in 1997, according to wikipedia it is also the most widely used pRNG; apart from being used in most statistical software it is also included in Dymola as Design.Experimentation.RandomNumber.Internal.Uniform - but just use it, ignoring the documentation for Dymola 2015; probably relevant in earlier ones)).

The included LCGs and MRG have known defects, and have non-user-friendly parameterization; and instead the library includes ways to reduce the impact of these defects. Thus I cannot recommend the included pRNGs; and would just remove them for an end-user library. This is similar to MSL only having an eigenvalue function, but not shifted inverse iteration functions which people studying how to make eigenvalue functions look at.

Furthermore having the state in each component is in itself error-prone; and the user will have to change the seed to get different noise-sequences – and will still get the same seed the next time. Moving the basic noise generation to ModelicaServices would be one option (e.g. as one impure function generating (0,1] uniform noise) – or just including it in MSL in some form using MT19937 or Well1024a, but we need to consider how the seed should be handled.

Regarding the “seed-handling” I can see three use cases:

1. Just use random global seed every simulation (and report it due to the next use case).
2. Re-run a simulation with a known seed.
3. Re-run a sub-system with a known seed; this seems less important, and I am not exactly sure how to handle this – without making the other use-cases more complicated.

Turning the basic pRNG into distributions: These are useful, but not that intuitive and it does not seem like the most useful ones: e.g. Irwin-Hall (and Bates?) to me seem primarily like an approximate way of generating normal distribution (I first saw Irwin-Hall with n=12 in the Intercal-library) and I would not include them among the top 7 distributions (I would expect Beta and F before these). The Box-Muller distribution does not have a good name for end-users: instead I would use the “Normal” since it exactly generates the normal distribution.

Generating signals based on distributions: Only the sample-based should be included at this moment as it represents widely recognized state-of-the art that can be handled in tools.

Any model with continuous-time noise will become a stochastic differential equation; which you cannot reliably integrate with normal ODE-solvers – which most tools use (I remember reading Øksendal when studying; and that there are different variants like Itô and Stratonovich (but not which one is which); and that the common method for handling them is just using explicit Euler, which loses half an order; but I don’t see the library even recognizing this issue). Apart from losing order the noise will also mess up the error estimator for the ODE-solvers.

[modelica-trac-importer]

Comment by sjoelund.se on 27 Jun 2014 15:39 UTC Yes, Mersenne twister is a good PRNG algorithm. We use it in OpenModelica to get a reliable cross-platform pRNG (with a fixed seed in order to reproduce the same results across platforms).

I think a good way to handle the seed would be an inner component with some global settings (to choose which seed(s) to use). And each component having a random seed stored as a default modifier when dragged onto a diagram (I suppose this would require tool support); or having the seed depend on something like the hash of getInstanceName() as a default random, reproducible seed.

But you are correct in that it is a bit complicated for MSL.

I would rather not have it in ModelicaServices.

[modelica-trac-importer]

Comment by sjoelund.se on 27 Jun 2014 15:40 UTC Replying to [comment:6 hansolsson]:

In addition there are too many abbreviations from an end-user perspective.

This has another ticket: https://github.com/DLR-SR/Noise/issues/32

[modelica-trac-importer]

Comment by awittkop on 27 Jun 2014 19:49 UTC One would also need to be really careful as to when to use such a component, restricting it's use to only very simple models.

From an integrator perspective, even restricting to Euler methods, if any constraints are present in the model (i.e. it is a DAE), then a projection iteration would need to be run, which may never stabilize in the presence of noise.

Similar, but perhaps stronger comments also apply to models with events - event iteration processes may never stabilize if a component of a model is random.

[modelica-trac-importer]

Comment by anonymous on 25 Aug 2014 14:24 UTC Was there any decision taken on this? It seems like Martin Otter recently removed the noise blocks from MSL with the reason "A more powerful package for Noise from DLR shall be included.": https://github.com/modelica/Modelica/commit/b546fbb19a3bd79d18451892c342ec65d397618b

[modelica-trac-importer]

Comment by otter on 25 Aug 2014 14:45 UTC Replying to [comment:9 awittkop@…]:

One would also need to be really careful as to when to use such a component, restricting it's use to only very simple models.

From an integrator perspective, even restricting to Euler methods, if any constraints are present in the model (i.e. it is a DAE), then a projection iteration would need to be run, which may never stabilize in the presence of noise.

Similar, but perhaps stronger comments also apply to models with events - event iteration processes may never stabilize if a component of a model is random.

Sorry, I do not understand this comment (the reason might also be that the description of the random blocks is not yet satisfactory): The planned random blocks have basically two features:

1. The random function is called at sample points (so a sampled data system, where at every sample point a function returns a random value, but only once since this is a time event).
2. The random function is basically called at sample points (internally, but not generating events) and these points are interpolated (either with linear interpolation or with a smooth interpolation).

From a DAE perspective, both cases are nothing special, but either standard sample data system or an algebraic, continuous function. So, all the prerequisites of hybrid DAEs are fulfilled, and from a formal point of view all the requirements of hybrid integrators are fulfilled (e.g. multi-step methods with varying step-size can be used without problems)

[modelica-trac-importer]

Comment by otter on 25 Aug 2014 14:49 UTC Replying to [comment:10 anonymous]:

Was there any decision taken on this? It seems like Martin Otter recently removed the noise blocks from MSL with the reason "A more powerful package for Noise from DLR shall be included.": https://github.com/modelica/Modelica/commit/b546fbb19a3bd79d18451892c342ec65d397618b

DLR is currently working on a revised version of the DLR Noise library taking the helpful comments into consideration. Furthermore, more tests are currently performed. It is expected that a new version will be provided in the next weeks. This new version is much better as the very restricted version that was included in MSL (without any previous discussion).

[modelica-trac-importer]

Comment by hansolsson on 25 Aug 2014 15:17 UTC Replying to [comment:11 otter]:

2. The random function is basically called at sample points (internally, but not generating events) and these points are interpolated (either with linear interpolation or with a smooth interpolation).

From a DAE perspective, both cases are nothing special, but either standard sample data system or an algebraic, continuous function. So, all the prerequisites of hybrid DAEs are fulfilled, and from a formal point of view all the requirements of hybrid integrators are fulfilled (e.g. multi-step methods with varying step-size can be used without problems)

Only true for the first case, which isn't problematic (and thus removed above).

The second case with a random signal without sampling may be continuous, but formally a ODE/DAE-solver require a certain number of continuous derivatives as well. Since we don't know which solver will be used we formally need an infinite number of derivatives.

Practically speaking it should have smooth enough derivatives up to a certain order (i.e. some solvers may work if the discontinuities are small enough in some cases, but mathematical tricks to generate infinitely smooth functions will not really help). When it works it creates a model depending on solver and tolerance, which is not good.

Note: both of these variants will also limit the band-width of the noise (to the sampling rate); whereas true stochastic differential equations have no such limit (and for these you are "lucky" if your solver gets half an order of convergence).

[modelica-trac-importer]

Comment by otter on 25 Aug 2014 16:00 UTC Replying to [comment:13 hansolsson]:

The second case with a random signal without sampling may be continuous, but formally a ODE/DAE-solver require a certain number of continuous derivatives as well. Since we don't know which solver will be used we formally need an infinite number of derivatives.

To be more concrete: The underlying mathematical theory is to generate random signals at a given grid (say every 0.1 seconds a random variable is drawn) and these values are interpolated. This is just a standard table interpolation where the y-values may vary stronger as for a usual interpolation. Now, the idea is to use this mathematical model, but do not generate events on the Modelica side (but formally, exactly the same result will be produced, if on the Modelica side the sample(..) operator is used, at every sample point a random number is drawn and between sample points the variable is interpolated. Its only a technical trick to avoid events at a high sampling rate).

Practically speaking it should have smooth enough derivatives up to a certain order (i.e. some solvers may work if the discontinuities are small enough in some cases, but mathematical tricks to generate infinitely smooth functions will not really help). When it works it creates a model depending on solver and tolerance, which is not good.

Note: both of these variants will also limit the band-width of the noise (to the sampling rate); whereas true stochastic differential equations have no such limit (and for these you are "lucky" if your solver gets half an order of convergence).

One application of the random blocks is the ability to simulate control systems with noise. Controllers are designed to reduce noise as much as possible. Therefore, the better the controller, the less influence the noise has on the closed loop dynamics of the system. In turn this means, the better the controller, the less influence the noise has on the step-size of the integrator.

There are certainly applications where only the sampled-data approach for random signals will work. But there are by sure many applications (and in particular controller applications), where the concept of interpolated random signals will give good results by an order of magnitude faster simulation (and this is what the end-user is interested in; note, the interpolated random signal does not directly influence the integrator, but via the control system this signal is filtered and the effect of this interpolated signal on the integrator is significantly reduced).

Maybe wait with further comments for the next version of the Noise library, which has several suggestions/comments taken into account, a better structure, no abbreviations, better documentation and use cases that demonstrate the usefulness.

[modelica-trac-importer]

Comment by dietmarw on 19 Dec 2014 07:01 UTC Ticket retargeted after milestone closed

[modelica-trac-importer]

Comment by otter on 19 Feb 2015 11:26 UTC Closed the ticket, because superseded by a completely restructured, and largely newly implemented version of the Noise library, see ticket #1662.

[modelica-trac-importer]

Modified by dietmarw on 9 Mar 2015 07:27 UTC

[modelica-trac-importer]

Modified by beutlich on 21 Oct 2015 10:23 UTC