(j3.2006) A loss for Fortran

[Clune, Thomas L. GSFC-6101]

Van,

Perhaps it is too early to tell, but the ECMWF C++ layer is considered to be successful, as opposed to your JPL story.   Otherwise I?d have labeled the thread ?A loss for ECMWF?  :-).

Indeed, OOPS is now being considered at NASA and NOAA for adoption to structure our data assimilation efforts.  Way to early to say that we will adopt it.   But it is certainly being evaluated.   F2003 maturity is much different now, so we have other options for the same capabilities, but ?. OOPS already exists and is well-designed for the task at hand.   Further, there are aspects of the problem that are much better suited to _parameterized_ polymorphism (e.g., templates in C++)  than to inheritance based polymorphism.     

- Tom




> On Mar 15, 2017, at 4: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