[Scilab-users] "Smoothing" very localised discontinuities in (scilab: to exclusive) curves.

[Tim Wescott]

I wish you'd made this response to the list.

Here's another thought, to address your overall problem:

* Find out what flavor of splines FEMM uses (there are subtleties).
* Figure out what Scilab calls them (naturally, everyone uses
  different names -- particularly when there's multiple countries
  and/or disciplines involved)
* Get your bad data point problem beaten to the ground
* Use Scilab to find the minimum number of points and their
  locations which, when smoothed with the right kind of
  splines, gives an acceptably close match to your B-H curve.
  Determining what's "acceptably close" is your job,
  of course.

You may find that minimizing the number of points helps the speed, you
may not -- it may just be that FEMM's numerical solver doesn't like a
large second derivative in the B-H data, in which case you'll just need
to smile and accept long solver times.

On Mon, 2016-04-04 at 08:43 -0800, scilab.20.browseruk at xoxy.net wrote:
> Tim,
> 
> (sorry for the earlier "Tom"; finger trouble not name recognition problems :)
> 
> > If your FEM software can't handle non-monotonic data, can it handle
> > noisy data?
> 
> That's a good (and open) question.
> 
> The software is FEMM (www.femm.info) which is widely held in high esteem.
> 
> When entering BH curve values into the materials definitions for those with non-linear magnetic properties, the program simply won't allow you to enter non-monotonic data; hence my need to remove these discontinuities before I can progress my project.
> 
> Once given data it will accept, it then manipulates the data to allow it to ... "do its thang". It's easier (and far more accurate) for me to quote David Meaker here than try to paraphrase him:
> 
> "Since FEMM interpolates between your B-H points using cubic splines, it is possible to get a bad curve if you haven’t entered an adequate number of points. “Weird” B-H curves can result if you have entered too few points around relatively sudden changes in the B-H curve. Femm “takes care of” bad B-H data (i.e. B-H data that would result in a cubic spline fit that is not single-valued) by repeatedly smoothing the B-H data using a three-point moving average filter until a fit is obtained that is single-valued. This approach is robust in the sense that it always yields a single-valued curve, but the result might be a poor match to the original B-H data. It may also be important to note that FEMM extrapolates linearly off the end of your B-H curve if the program encounters flux density/field intensity levels that are out of the range of the values that you have entered. This extrapolation may make the material look more permeable than it “really” is at high flux densities. You have to be careful to enter enough B-H values to get an accurate solution in highly saturated structures so that the program is interpolating between your entered data points, rather than extrapolating. Also in the nonlinear parameters box is a parameter, φhmax. For nonlinear problems, the hys-teresis lag is assumed to be proportional to the effective permeability. At the highest effective permeability, the hysteresis angle is assumed to reach its maximal value of φhmax. This idea can be represented by the formula: φh(B) = ( µe f f (B) ) / ( µe f f ,max ) φhmax "
> 
> So the first goal is to get data that FEMM will accept. After that there are other criteria that may require the raw data to be further manipulated.
> 
> I've demonstrated that 'inconveniently real-world' data can interact badly in (at least) two different ways. with FEMMs manipulation and use of that data in its Tensor equations:
> 
> 1) Unless the final points approach a slope of 0 very closely, it can extrapolate the data to produce ludicrously high B values. (Eg. the 'best# I achieved was 67.7T!)
> 
> 2) Unless the data values works with FEMM's interpolations rather than against them; it can result in extraordinarily long processing times as the Newton-Ralphson iterations oscillate and converge very slowly. 
> 
> The former is fairly easy to deal with by simply appending a few artificial values to the dataset that ensure a very near 0 slope.
> 
> The latter is far harder to get a handle on. One of the reasons I'm being quite adamant about making a little change to the real data as possible is so as to give me a chance to determine the absolute minimum requirements for ensuring accurate simulations with minimal run times.
> 
> The typical approach to the latter problem seems to be to approximate the data using some nicely behaving mathematical approximations (1-exp( tanh ) or similar), and feed those values as the materials definition. 
> 
> The problem with that is that it throws away much of the subtlety of the data; which for silicon steel laminates doesn't matter; but for amorphous/nono-crystalline  metals, can mask important parts of their desirable behaviours.
> 
> Indeed, my entire foray into learning SciLab is to try and establish a good method for pre-processing these kind of curves so that it strikes the balance between horrendous run times; and using artificial substitutes that ignore those subtleties.
> 
> And yes. You've certainly given me food for thought :)
> 
> 
> 
> > 
> > I'm taking "smoothing" to mean "filtering" here.
> > 
> > In general the filtering problem is to decide on the characteristics of
> > your desired signal, the characteristics of your noise, and then make
> > some mathematical transformation that minimizes the effects of anything
> > with noise-like characteristics while retaining as much of anything with
> > desired-signal-like characteristics.
> > 
> > This has two salient corollaries: first, you have to know what the
> > characteristics of your signal and noise are; and second, the more that
> > your signal resembles your noise, the less of it you will be able to
> > recover.
> > 
> > You can spin off from there in a number of different directions, leading
> > you to a number of different filtering techniques.
> > 
> > It appears that you're doing your measurements by varying some
> > controlled parameter along the vertical axis and measuring along the
> > horizontal axis.  If this is the case, then I would start by trying
> > filtering techniques using the vertical axis as your "time" axis.
> > 
> > There is no linear filtering technique (i.e., output sample = weighted
> > some of a vector of input samples) that you can use that guarantees
> > monotonicity for all possible inputs.  If you use linear filtering then
> > you need to verify monotonicity by experiment.  If your FEC program is
> > messed up by noise as much as non-monotonicity, then this is not a bad
> > thing -- it's just an indication that you're filtering heavily enough.
> > 
> > If the problem really, truly is monotonicity, then take the derivative
> > at each point, and snip out the points that go the wrong direction.  I
> > suspect this won't lead to joy, but it'll meet your stated objectives.
> > 
> > If the problem with the smoothing filters that you've tried is that it
> > works well in some spots and not in others, then consider using a filter
> > whose properties vary depending on where on the axis your output sample
> > is located.  This isn't something that you'll find pre-packaged --
> > you'll have to whomp something up using more primitive functions of
> > Scilab.
> > 
> > I could go on and on -- sorry for coming to a disorganized end here, but
> > I hope I'm giving you some food for thought.
> >
> 
> ____________________________________________________________
> FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
> Visit http://www.inbox.com/photosharing to find out more!
> 
> 
> 
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

-- 

Tim Wescott
www.wescottdesign.com
Control & Communications systems, circuit & software design.
Phone: 503.631.7815
Cell:  503.349.8432