Re: Bug with g77 and -mieee on Alpha Linux

[Toon Moene <toon@moene.indiv.nluug.nl>]

First of all, I want to - belatedly - apologize to Martin and his
colleagues for the following insinuation:

> If people are
> forced to deal with badly written software in such large IT firms like
> Siemens, they'd better be prepared to pay up, or shut up.

It was uncalled for and wrong.  This will not happen again.

Martin Kahlert wrote:

> Please correct my if i am wrong, but meteorological simulation
> usually deals with elliptic partial differential equations in each time
> step (i don't think you have shocks). Since there is the maximum principle,
> i assume, you can theoretically prove that all of your floating point values
> are within good boundaries.

Possibly (numerically, the partitioning of PDEs in hyperbolic, parabolic
and elliptic is not very useful), but I am not sure these properties
still hold after discretization.  We tend to approach the issue from the
other direction: 

Given that the atmospheric quantities stay within certain limits, our
differential equations after discretization should also stay within
those limits.

Because weather forecasting is an initial/boundary-value problem, and
all forecast times are useful (up to a certain limit), we want this to
hold for the entire evolution from initial state to final state.

Hence, if our discretization gives rise to unboundedly growing errors,
we have to control them - we dissipate these waves by filters.

> Electrical circuit simulation is by a big amount more nasty thing than this!
> Each transistor has about 3 operation modes: One, where it doesn't do a lot,
> since the voltages are a bit too low, one rather linear part in the voltage-
> current graph (where amplification happens) and a saturation part.
> This graph has rather sharp edges and you don't know anything about, where
> the designer wants the transistor to work - and this has not neccessarily
> anything to do with where they actually work ;-).
> This might be rather simple to solve in the case of toy problems with less then 100
> transistors, but our simulation tool is inteded more in the range between
> 10000 and 100000 of them. Unfortunatly transient time simulation is the simpler
> part. A great deal of effort (and computation time)
> is put into finding an initial consistent solution.

And for this you use the Newton-Raphson root finder, if I understand
correctly.

> While in meteorological simulations the linear sets of equations are so well
> behaved, that usually iterative solvers converge, i don't know of any successful
> use of an iterative linear solver in analog circuit simulation.

The PDEs of atmospheric motion are non-linear, although not
spectacularly so - we also do not use iterative solvers (why do you
think so ? - we're not trying to calculate an equilibrium solution, but
a time evolution).

> I think, you didn't read Num. Rec. exactly: Can you tell me any globally convergent
> method for nonlinear methods, which can be coded to not produce FPEs?
> The rather trivial improvements of newton's method in NR, all suggest to calculate
> F(x_new) first (to ensure quadratical convergence near the solution).
> But this is not possible, if x_new has bad values inside it. Even something
> like if(x_new(i) .GT. 1D10) can throw an exception! The only thing you can
> savely do with these values is to not use them.

Yes, obviously, I didn't read it far enough.  Sorry for my rant.

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html