Re: [femm] FEMM now crashing!

[David Meeker <dmeeker@xxxxxxxx>]

ttelesky

wrote:

> FEMM is now
> acting very strange and not running.  It will not even 
> solve the demos.  Before the first incident of the problem, I made 
> some changes as follows:
>
> 1) Added USB external harddrive. (using a laptop)
> 2) Set the directory where files are saved to a new location
> 3) Imported some new materials. (this was done before the USB
> drive and they seemd to solve fine)
>
> On first model (imprted DXF), I first started to see an error message 
> in the solver "Cannot solve the problem" onthe firat iteration.  I 
> then loaded 2 or 3 of the demo problems and the solver seems to solve 
> but then hangs when opeing the results window.  I see the start of the
> title line but no more of the window is created.
>
> I have un-installed FEMM and re-installed, leaving all defaults etc 
> the same - but I stil have the same problem with the demos.  Now I 
> cannot solve any problem.
>
> Anyone have any ideas?  I sent the first file I had troible with to a 
> worker that has FEMM and he gets the same "Unable to solve problem" 
> error, but his other files still work.  I can send this file if 
> needed.  How do I do that by the way?
> Thanks
> Ted
Hmm--I can't see how FEMM would care about any of those changes.  The solver
only gives the "Couldn't solve the problem" message if it detects zeros on
the main diagonal of the matrix that is builds to solve for the fields.  This
is a sure sign that something is really wrong, though it may be hard to say
exactly what.  

Now, it's not impossible to get a dxf file that imports poorly, such that
triangle chokes when it tries to mesh it.  You could then get the"Couldn't
solve the problem"  message.  If this is the case, you'll end up having to
manual check the geometry's consistency (i.e. look for points right on top
of one another that really should be the same point).  However, FEMM is internally
not a very sophisticated program--it's hard to see how choking on one geometry
could affect the performance of any other problems.

The only time that I've seen anything that might be like this is when I was
analyzing a file that lived on a zip disk. The zip disk was nearly full,
so that there wasn't enough space to write the mesh to disk. When I the solver
tried to analyze the problem, it then gave the "Couldn't solve the problem",
because it had only read in about half the mesh. If I had attempted to analyze
additional geometries on the same filled-up drive, it would probably have
corrupted up those files, because there'd be no place to store them.

Dave.
-- 
David Meeker
dmeeker@xxxxxxxx
http://femm.berlios.de/dmeeker