Please create an account to participate in the Slashdot moderation system


Forgot your password?

A C++ Library That Brings Legacy Fortran Codes To Supercomputers 157

gentryx writes "In scientific computing a huge pile of code is still written in Fortran. One reason for this is that codes often evolve over the course of decades and rewriting them from scratch is both risky and costly. While OpenMP and OpenACC are readily available for Fortran, only few tools support authors in porting their codes to MPI clusters, let alone supercomputers. A recent blog post details how LibGeoDecomp (Library for Geometric Decompostition codes), albeit written in C++, can be used to port such codes to state-of-the-art HPC systems. Source code modification is required, but mostly limited to restructuring into a new pattern of subroutines."
This discussion has been archived. No new comments can be posted.

A C++ Library That Brings Legacy Fortran Codes To Supercomputers

Comments Filter:
  • Code... (Score:4, Informative)

    by gigaherz ( 2653757 ) on Saturday September 21, 2013 @12:39PM (#44912119) rice, is not countable. At least not since I learned the word.
  • Author here. (Score:4, Informative)

    by gentryx ( 759438 ) * on Saturday September 21, 2013 @01:36PM (#44912479) Homepage Journal
    The IEEE and Los Alamos National Laboratory seem to have a different opinion [] on this. And even the Oxford dictionary knows the use of codes []. But surely those guys can't even spell gigahertz.
  • Very limited indeed (Score:5, Informative)

    by gentryx ( 759438 ) * on Saturday September 21, 2013 @02:03PM (#44912601) Homepage Journal

    I took a look at TFA and followed up by reading the description of LibGeoDecomp:

    If your application iteratively updates elements or cells depending only on cells within a fixed neighborhood radius, then LibGeoDecomp may be just the tool you've been looking for to cut down execution times from hours and days to minutes.

    Gee, that seems like an extremely limited problem space, and doesn't measure up at all to the title of this Slashdot submission. It might really be a useful tool, but when I clicked to this article I expected to read about something much more general purpose, in terms of 'bringing Legacy Fortran to Supercomputers'.

    Correct. We didn't try to come up with a solution for every (Fortran) program in the world. Because that would either take forever or the solution would suck in the end. Instead we tried to build something which is applicable to a certain class of applications which is important to us. So, what's in this class of iterative algorithms which can be limited to neighborhood access only?

    It's interesting that almost(!) all computer simulation codes fall in one of the categories above. And supercomputers are chiefly used for simulations.

    By the way, regarding the use of the word 'codes': I don't think English is the first language of this developer. Cut some slack.

    Thanks :-) You're correct, I'm from Germany. I learned my English in zeh interwebs.

  • by poodlediagram ( 1944244 ) on Saturday September 21, 2013 @02:48PM (#44912825)

    ...and has done for years.

    We write a scientific code for solving quantum mechanics for solids and use both OpenMP and MPI in hybrid. Typically we run it on a few hundred processors across a cluster. A colleague extended our code to run on 260 000 cores sustaining 1.2 petaflops and won a supercomputer prize for this. All in Fortran -- and this is not unusual.

    Fortran gets a lot of bad press, but when you have a set of highly complex equations that you have to codify, it's a good friend. The main reason is that (when well written) it's very easy to read. It also has lot's of libraries, it's damn fast, the numerics are great and the parallelism is all worked out. The bad press is largely due to the earlier versions of Fortran (66 and 77), which were limited and clunky.

    In short, the MPI parallelism in Fortran90 is mature and used extensively for scientific codes.

  • by cwebster ( 100824 ) on Saturday September 21, 2013 @06:00PM (#44913783)

    Please don't learn FORTRAN, learn Fortran instead. (For the pedantic, all caps is F77. Normal caps is F90 and later.)

  • Re:FUD (Score:4, Informative)

    by stenvar ( 2789879 ) on Saturday September 21, 2013 @06:47PM (#44914005)

    Care to backup those claims with actual code/numbers?

    You claim to be writing high performance code and you don't understand the difference between Boost multi-array and Fortran arrays? I'm sorry, but if you do any kind of high performance computing, you should at least have a decent understanding of one of the major tools used for it, namely modern Fortran. Once you do, you can then make an informed choice, instead of behaving like an immature language zealot.

    Here are two places you should start looking: [] []

    (The Fortran code on is cringe-inducing and inefficient.)

    And, FWIW, I'm primarily a C++ programmer, because that's what the market demands, not a Fortran programmer, but at least I know my tools and their limitations.

    My experience is that if you use C++ correctly, you get code which at least matches Fortran code.

    If you use C, assembly, or Java "correctly", you can usually match Fortran code. That is entirely not the point.

  • Re:Code... (Score:4, Informative)

    by cas2000 ( 148703 ) on Saturday September 21, 2013 @08:47PM (#44914625)

    actually, "codes" is common usage amongst researchers and has been since at least the 1970s.

    most of them are not programmers or geeks or computer scientists, they're researchers or academics or post-grad students who happen to do a little programming or simply use someone else's "codes".

    it used to make me cringe every time i heard it when working with academics and researchers and on HPC clusters, but then i got used to it and stopped caring.

    and, really, they're not interested in a lecture or why it's a dumb usage of the word. they've got stuff they want to get done ("codes to run") and don't give a damn.

Exceptions prove the rule, and wreck the budget. -- Miller