Re: [femm] Suggestions

[dcm3c@xxxxxxx]

I've been sort of busy lately and haven't gotten around to doing many changes 
to femm lately. Anyhow, what I want to do is make some sort of "release" 
version of femm before really adding any more functionality, so that there 
can be a relatively bug-free "standard" version. Basically, I things seem to 
be pretty stable (except for a couple sort of odd-ball bugs that cropped up 
lately), and I really just need to update the documentation to reflect all of 
the difference and additional functionality between the 2.1 and 3.0 versions.

Then, there can be a new "official" development version that will include 
some of these suggestions, as well as Robin's lua extensions and some other 
stuff from Hang (bitblt stuff) that I haven't incorporated yet. The stuff 
that has been suggested that would be reasonable to tack in are:

1) Marker at the origin.

2) Highlight areas that the solver doesn't like because no material 
properties have been identified

3) Some sort of "Preferences" so that one can control the default view setup, 
colors, etc.

4) Copy a bitmapped image of the view, as well as metafile image.

There is some technical functionality that I'd like to add in, like:

1) Nonlinear harmonic problems based on a describing function approach

2) Figure out how to do time transient solutions in combination with the 
scripting

3) Maybe some sort of airgap elements to aid in problems with rotational 
motion.


In response to some of the other issues:

Grid "alignment" move around because, depending on the zoom, only a subset of 
the grid points are shown. If all of the grid points were displayed, the 
screen would tend to fill up with blue at when zoomed out. However, the 
physical alignment of the grid (i.e. what location the grid points map to) is 
constant, regardless of the zoom setting.

I don't know about the multiple undo levels. This probably wouldn't be that 
hard to implement, and it probably wouldn't be a bad idea....

Also, I should probably change the fonts around so that they are more 
readable when the display is run at a higher resolution.

As far as colors go, the reason that I didn't do a continuous variation is 
just a personal preference thing--it's hard for me to tell what flux density 
a color maps to if there are too many levels. With a finite number of 
levels, I can also pick the contour colors so that they don't interfere too 
badly with the colors that are used for rendering the other things in the 
geometry. N.B.--24 bit color is no longer actually a requirement. Things 
should be ok in 16 bit, and you can run it in 256, although the colors then 
tend to get dithered.

Keith had good answers for the other points.

Dave.
--
David Meeker
<A HREF="http://members.aol.com/_ht_a/dcm3c";>
http://members.aol.com/_ht_a/dcm3c</A>