(j3.2006) A loss for Fortran
Wed Mar 15 16:19:46 EDT 2017
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).
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
> 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
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
More information about the J3