(j3.2006) A loss for Fortran

[Bill Long]

I?m sure some enlightened administrator will eventually realize that the legacy C++ code critically needs to be rewritten in Julia. (Assuming that Julia has not self-desrructed by then).  

Cheers,
Bill


On Mar 15, 2017, at 3:12 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> 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.
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101