14
$\begingroup$

Case studies in my PhD thesis require that I have interval extensions of Fortran subroutines in CHEMKIN-II (apologies for the link; it's the best one I could find for a package no longer distributed by Sandia National Laboratory). CHEMKIN-II is a chemistry package used in combustion chemistry; since it's the standard package used in combustion, I can't (or rather, would really prefer not to) use a different package out there.

In order to get the required interval extensions, I've been using a tool developed in-house called DAEPACK. The old binaries I have used to be able to generate the required interval extensions of the CHEMKIN-II subroutines I needed on a 32-bit OS (with a version of libstdc corresponding to gcc 2.95) a couple years ago, but have since fallen out of date, and would be a tremendous ordeal to use (because I'd have to find 32-bit versions of every other piece of software I used). The source code for this package is also proprietary, but since it was originally developed at MIT, and I work at MIT, I was able to (after a great deal of effort) get the source code for DAEPACK. Using the source code I have, I was able to compile a version of DAEPACK compatible with 64-bit versions of Linux and versions of libstdc corresponding to gcc 4.x.x. However, this source code, which I suspect is old, compiles into an executable that does not successfully generate the interval extension code I need in order to complete my thesis. I have contacted the developer in an attempt to get his help in fixing the source code, but from previous contact with the developer, I know that it will take time for him to fix the source code, if he does at all.

Here's the big problem: I have 6 months left until I need to graduate because I run out of funding. I can't rely on the developer to fix DAEPACK quickly enough for me to successfully complete my PhD thesis, which is where you guys come in.

I need a package that does the following:

  • Generates interval extensions, Taylor models (using interval arithmetic), and derivatives of almost arbitrary Fortran 77 code; I think the only structures that aren't parsed by DAEPACK are DO loops and IF statements. Since I need Taylor models, the code must also have automatic differentiation (AD) capability.
  • Generates these interval extensions and Taylor models by source-to-source translation of the Fortran 77 code (i.e., it parses the source code like a compiler to generate the source code that calculates the interval extensions and Taylor models).

In a pinch, I can use software that does the above two things to C code instead of Fortran 77 code, and then pass everything through f2c. I'd really prefer not to do it this way, because I have no idea whether or not passing everything through f2c will even work, but I'm pretty desperate.

Can you guys help a desperate PhD student out?

To anticipate some possible suggestions, here are approaches that will NOT work for me, given the time constraints:

  • Trying harder to get DAEPACK to work; believe me, I've tried. And I'm bugging the developer frequently.
  • Tools that calculate interval extensions or Taylor models using object-oriented (or object-oriented-like) approaches. I don't have time to recode CHEMKIN-II (or any other similarly large library) with new types; it's too big.
  • Using any language other than Fortran 77/90 or C. The CHEMKIN-II code is in Fortran. I can convert it to C using f2c, or if need be, use a Sandia-based clone of CHEMKIN-II called TChem. My old results use CHEMKIN-II; my new results should replicate my old results, and I already know that Cantera won't replicate what CHEMKIN-II does based on case studies and unit testing. Furthermore, the graduate student that preceded me did some black magic to the CHEMKIN-II source code to get interval arithmetic to work especially well. It would be difficult for me to replicate that in any other package.
Improve this question
$\endgroup$
11
  • $\begingroup$ Change your thesis topic immediately. Get rid of that silly interval arithmetic and do something useful, ideally with software that works. ;-D $\endgroup$
    – Jed Brown
    Mar 3, 2012 at 16:52
  • 6
    $\begingroup$ Taking your existing results, shoehorn them into an interpretation of your thesis topic, do a nice writeup, and buy your defense committee great snacks. $\endgroup$
    – Matt Knepley
    Mar 3, 2012 at 17:22
  • $\begingroup$ @Geoff Oxberry: Help me understand what you mean by interval extension; $f:\mathbb{R}\to\mathbb{R}$ extended to $F:(\mathbb{R},\mathbb{R}_0^+) \to ((\mathbb{R},\mathbb{R}_0^+)$, where $F(a,b)=f([a-b,a+b])$? I assume your functions do not have some nice properties like monotonicity etc. Is this a robust optimization problem? $\endgroup$
    – Deathbreath
    Mar 4, 2012 at 1:11
  • 1
    $\begingroup$ Basic overviews of interval arithmetic can be found on Wikipedia (which includes the concept of interval extension), and in the references mentioned on this page. The best introduction to Taylor models that I could find is here. Automatic differentiation is typically used in the implementation of Taylor models; I've never heard of or seen anyone use numerical approximations instead. $\endgroup$
    – Geoff Oxberry
    Mar 4, 2012 at 1:35
  • 2
    $\begingroup$ @MishaBrukman: Oh, I just punted on all of that. $\endgroup$
    – Geoff Oxberry
    May 22, 2014 at 18:19

1 Answer 1

Reset to default
2
$\begingroup$

Assuming that the issue is that DAEPACK works in 32-bit mode but not 64-bit mode, here are some approaches to address this.

Compile DAEPACK in 32-bit mode on a 64-bit OS

See how to do this in another question. This may be an easy way to continue to work with it.

If the issue is that the generated code is having issues in 64-bit mode, compile the generated code with similar 32-bit flags or in a 32-bit environment (64-bit OS can run 32-bit code given appropriate libraries, but not vice versa).

Recreate an entire DAEPACK-safe environment

  1. Create a full 32-bit environment in a virtual machine using, e.g., VirtualBox, such that DAEPACK is happy running in it, whether from old binaries, or recompiled in this environment. You can get a release of an open-source OS and compiler as old as you need to get a working version of the software.

  2. Take the output from DAEPACK and transfer them to the host machine or a separate virtual machine where the environment is appropriate for the other software and continue working. This can be a more recent 64-bit OS, for example, and continue working there.

    Using the shared folders feature in VirtualBox should make this easy for you.

Enlist others to help fix DAEPACK

I noticed that you said that neither you nor the software author have the time to fix this, but no one said you can't enlist anyone else's help! Consider these options:

  • Hire some undergraduate MIT CS students to help fix the 32-bit vs. 64-bit issues. Note that to entice them to work on it, you may have to compensate them, whether with money or pizza (and/or beer, if they're of legal drinking age), for example. Or consider asking if your advisor can hire some part-time undergraduates to help with this (may be an issue with funding, if your own funding is running out). Or ask for some favors from research programmers in your department.

  • Lobby for an open-source release of DAEPACK. It looks like its licensing status is unclear, but note that MIT has an eponymous open-source license that's rather well-known; releasing it under an open license may help get more eyes on the problem and help fix the 32-bit vs. 64-bit issues.

    Note that depending on your department, legal, administrative, etc. offices may take longer than the 6 months that you have left for your Ph.D., so consider starting this early, while pursuing other alternatives.

Good luck!

Improve this answer
$\endgroup$
3
  • $\begingroup$ After spending a while writing up this answer, I just realized that you wrote your question in 2012 with a 6 month deadline, so this discussion is rather moot. Sorry about that! I'm still curious what you ended up doing in this case. $\endgroup$
    – Misha Brukman
    May 22, 2014 at 16:08
  • $\begingroup$ During my PhD, I tried all three approaches you mentioned with no success. The problem, IIRC, was that it would generate buggy code; compiling it (although a pain in the ass, because I had to modernize parts of it) was actually the least of my problems. DAEPACK is unlikely to be released open source, since it's the key technology of a company. It is also thorny to get other people outside of that company and my former adviser's lab to fix it, and I doubt enterprising MIT CS students would want to take that thankless job on. $\endgroup$
    – Geoff Oxberry
    May 22, 2014 at 18:22
  • $\begingroup$ @GeoffOxberry sorry to hear that, but that is (unfortunately) all too prevalent in so-called "research-quality" software. Congrats on persevering and completing your degree nonetheless! $\endgroup$
    – Misha Brukman
    May 22, 2014 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.