Fortran - Trying to Learn Enough to Move Forward - LSODE

[hockswender]

I am attemmpting to rework some Fortran 77/90 routines related to solvers for differential equations. The LSODE [single or double precision] solver 'comes with' a calling program to exercise the solver.
All compiles and links [G77, FTN77, gfortran] OK but all runs lead to a run time error indicating the subroutine is being called by the main with arguments that are incorrect.
I suspect that a compile or more likely link option will fix this but don't know where to start.
I would untimately like to obtain the Visual Compiler but need some indication that the solver will work.
Any ideas from the readers?
Tom

[mecej4]

The LSODE code has been around for decades and there are several versions at various places. It is well-tested and works quite well. However, it was written in a rather lax style of the time, and a current compiler may object to some parts of it, especially if error checking is turned on. For the version from LLNL, see the comments under "Portability" in file dlsode.f and make the suggested changes to NEQ, RTOL and ATOL, and all will be well.

[John4]

Instead of describing the error, do you care to show the actual error ---maybe indicating the name of the compiler or compilers that give you such error?

I'd suggest you to drop G77 and stick to gfortran (I'm not so sure about FTN95 vs. FTN77). In general, you can use Fortran 90+ compilers to compile fixed-source code just fine.

Also, it's not clear what you mean by "reworking". Do you intend to modify/improve the code? If that's the case, putting all the procedures in modules and adding IMPLICIT NONE will help you a lot.

EDIT: Ups, I hadn't noticed that the code you were referring to was ODEPACK, so please ignore the third paragraph in this post, and apply the code changes suggested by mecej4.

[hockswender]

Thanks for the input John. For the compilers, G77 and FTN77 both gave the same error. The gfortran run just crashed with no error message [I may need to better understand the 'internal linking' to generate error messages].
I did the changes suggested. It was to Dimension each as (1). The runtime error from NEQ is now targeted at RTOL.
"Attempting a call [from main ] with parameter 7 as a Real*4 when a procedure is expected".
I tried to add the executable to this note but the page doesn't allow for it properly.
Tom

[hockswender]

Thanks for the help.
I made the changes They were to Dimension (1) each of NEQ, RTOL, ATOL.
[this seems as if it would reduce portability but ???]
Now the target of the problem has moved down the calling line:
"Attempting a call [from main ] with parameter 7 as a Real*4 when a procedure is expected".
I suspect the root cause is something else but can't yet find it.
Tom

[mecej4]

Without knowing the following, it is very difficult to help.

1. The source code as modified, or source of original code and description of modifications

2. Compiler, version, compiler options, OS (Win XP, 7, 32-bit, 64 bit, etc).

3. Complete error message, with routine names and line numbers.

[TimP]

If a declaration of a subroutine argument such as dimension neq(1), rtol(1), atol(1) were used in the common, but non-standard, pre-1977 way, with the meaning of (*) as instituted in 1977, such a change would improve compatibility to any compiler of the last 30 years, although the ancient hack is widely recognized still.
A procedure name argument in the caller must be declared EXTERNAL (or INTRINSIC, if it is an intrinsic, such as SIN, EXP, ....). The latter case is one where making it compatible with the standard of the last 20 years might not have worked in prior years. I wouldn't count on any scheme for avoiding the current standard requirement there.

[mecej4]

Tim, the trick used in this old code is a little different than what you mentioned. Three dummy arguments to the solver subroutine are declared as arrays. However, the caller sometimes passes scalars instead, relying on the assumption that A and A(1) have the same address. To be specific, here is an illustration of what the code does:

subroutine sub(A,n)
dimension A(n)
..

is called either as

A=1.5
call sub(A,1)

or

dimension A(3)
data A/1.0,2.0,3.0/
..
call sub(A,3)
..

depending on which test problem is being run.

As long as no checks are turned on, the code (see link in my response, #1) compiles and runs fine with Gfortran and Ifort.

The code has been modified and replicated in various repositories, including Netlib and NASA over the years, and we do not know which version the OP is using.

[DavidWhite]

Which version of LSODE are you using. I just looked up the version I have on my machine (1987!) and found that the changes required to make it work are immense (like changing all the arguments from hollerith strings to character strings).

I suggest you download a newer version which has already been made more compatible with newer compilers. The code on netlib looks like it is more likely to compile (have not tried it). Why replicate work that has already been done?

location is http://www.netlib.org/odepack/

Routine is now called DLSODE and has been upgraded to double precision.

Regards,


David

[mecej4]

The version that I used (to which I gave a link in #1) is dated 2003. The link is to the author's LLNL site:

https://computation.llnl.gov/casc/odepack/download/lsode_agree.html

The codes downloaded from there compile and run fine, as I already stated. On the other hand, I don't know which version the OP is using.

It is not clear if you were replying to #7 or to one of the other posts in this thread.

[TimP]

For what little it's worth, the f66 compiler on which I first learned, and had to use on my job for 14 years, didn't work with the ingenious trick of passing a scalar to an array dummy argument. As far as I was concerned, that was just one of a number of tricks to assure that the code would work only on the combination of compiler and machine available to the original author. It's simply not possible for a compiler to cover reliably all those schemes for making code non-portable.
I don't know how the compiler could diagnose it as an expected function reference if it should have been an expected array reference.

[hockswender]

Thanks for your help. I downloaded the files and thet compiled and ran without error!

I should be able to compare the various versions and learn how to fix similar issues I have encountered
with some older Fortran routines!
Your time and input is much appreciated.
Tom.