(j3.2006) A loss for Fortran

[Van Snyder]

On Wed, 2017-03-15 at 19:00 +0000, Clune, Thomas L. (GSFC-6101) wrote:
> I just learned at a telecon that the European Center for Medium-scale
> Weather Forecasting (ECMWF), _the_ premier weather forecasting center
> in the world, has started using C++ for their code architecture.   The
> bulk of the code will remain in Fortran for the foreseeable future,
> and those layers can/will remain at F90.       But the root
> decomposition into classes and responsibilities will be in C++3   The
> new layer is called OOPS if you want to google more.
> 
> The primary reasons for the switch to C++ was the lack of generic
> programming in Fortran.   Immaturity of F2003 implementations was also
> a concern at the time.  (Decisions were made many years back.  I only
> learned about them today.)

A similar thing happened at JPL.  In 1996 or so, the powers-that-be
decided that the six million lines of navigation software (orbit
determination, trajectory determination, trajectory planning...) that
had been developed in Fortran since about 1960, had to be re-written in
C++.

They asked for 120 work years of funding.  At the time, the maintenance
staff for the Fortran navigation software was 6.5 FTE.  I calculated
that if they reduced their maintenance cost to zero, they would break
even in 2023.  Three years ago, they came back to their sponsor and said
"We've almost finished.  We just have a few loose ends to tie up.  We
need another 126 work years of funding."  Of course, they didn't reduce
their maintenance cost to zero.  Les Hatton has looked at this
quantitatively, not using anecdotes.  His conclusion is that a C++ code
has six times the lifetime ownership cost of an equivalent program
written in C, Fortran or Ada.

During the conversion, one guy set to work to replace the Fortran 77 ODE
integrator.  He fiddled with it for 18 months, and didn't even produce
an interface that would do everything necessary.  I assume they used a
"C external" declaration for it, and kept on using it.  I've heard a
rumor that they're abandoning the tried-and-true variable order variable
step size Adams integrator, which solves second-order equations
directly, in favor of a brand new untried Runge-Kutta integrator that
requires breaking second-order equations into first-order systems.

The new code, called MONTE, was used beside the legacy code for the
Phoenix lander in Mars's arctic.  One of the navigators (staff who use
the codes, not develop them) whispered to me "it doesn't work!"

Of course, MONTE has a graphical front-end written in Python.