They are usually not as serious as it sounds. We haven't had a case where libRadtran worked on one computer and produced really wrong results on another. However, radiative transfer equation solvers like disort are numerical methods which are affected by the limited numerical precions of processors, and these differ from processor to processor and sometimes even from compiler to compiler. Usually, large differences occur for small numbers. As an example, in the near-infrared the diffuse downward irradiance is very small while the direct beam source is large - hence one may expect some uncertainty in the small diffuse radiation. Citing from DISORT2.doc:

 DISORT has certain intrinsic limitations because of computer precision.  
 These limitations are related to ordinary computer
 "roundoff error" and have nothing to do with user-controllable
 (through the number of streams NSTR) "truncation error". DISORT
 is free of the *catastrophic* growth of roundoff error that
 plagued pre-1980 discrete ordinate programs, but certain parts
 of the calculation (the eigenvalue/vector and Gauss quadrature
 rule computations, and to a much lesser extent the linear
 equation solving computations) are just inherently more sensitive
 to roundoff than the rest of DISORT, because they involve so many
 arithmetic operations.
 
 The reason DISORT.f does the eigenvalue/vector and Gauss
 quadrature rule computations in double precision is that DISORT
 was originally developed on 32-bit-single-precision computers
 (VAXen and IBMs) which were too inaccurate for those computations.
 Running DISORT.f on a typical 32-bit-single-precision computer
 usually gives results precise to at least 2-3 significant digits,
 although for certain special situations the precision can fall to
 one significant digit. Results can even have NO significant digits
 when they fall below about 10**(-8) times the driving radiation,
 as one can see in the fluxes in some of the test problems.

Also, disort does e.g. not return 0 in cases where it should. E.g. the irradiance reflected by a surface of albedo 0 usually assumes a tiny value different from 0 (sometimes even negative) which of course strongly depends on numerical precision. Hence it is difficult to estimate a-priori which deviations are serious and which are not. Deviations in the order of 1% or smaller are rarely serious, while in case of much larger differences the user is recommended to compare the output against the output stored in the examples directory to see what is the case for the deviation.

Try the “verbose” option!

There are several sources that describe the inner workings of DISORT. Please check out:

• The DISORT paper for a brief description.
• The DISORT report for a detailed description. Highly recommended.
• The DISORT IO documentation for a description of all input/output to DISORT.

The directory structure has changed a bit from version 1.3 to version 1.4. We made libRadtran a bit more compliant to the “standard” source code structure. All the sources are now in src, the library sources in libsrc_c and libsrc_f, and the binaries go into bin. While this is not a big improvement in itself, one may now use “make install” as with most other UNIX/Linux tools.

uvspec outputs both to stdout and stderr. Sometimes it is advantageous to redirect this output to different files. Two ways of doing this on a unix type machine within the bash shell are:

 (uvspec < uvspec.inp > uvspec.out) >& uvspec.err

and

uvspec < inp.inp > uvspec.out   2> uvspec.err

Choose whatever is your favorite. It is also possible to do this from within scripts. For an OS independent method implemented in python check out the uvspec graphical user interface (GUI).

There are two ways of utilizing the power of all processors on a multiprocessor machines for libRadtran/uvspec calculations.

1. Make a script the generates input files and takes care of output files. Start that script simultaneously as many times as you have processors. Make sure that all input and output files are uniquely named.

1. uvspec may be invoked by calling the uvspec() function from within a C-program. To avoid memory leakage use fork() to invoke uvspec. An example is provided in src/uvspecfunction.c. If you fork for e.g. 32 times, you will have 32 independent processes running. Convenient if you have a 32 processor machine.

If you have a single uvspec run that takes a long time there is no multiprocessor support other than that provided by the compiler. In such a case you may consider breaking up the input file if possible.

It appears that Ubuntu installs more than one Fortran compiler (f77 and gfortran) at the same time and the configure script may have trouble with that. A symptom for this problem is a configure log which looks as follows:

...
Fortran compiler:     f77 -O
Fortran linker:
Fortran libraries:
...

The solution is simple: You need to tell configure to use gfortran and this is done e.g. by setting a variable

export F77=gfortran

before calling configure.