This is an old revision of the document!


How serious are serious differences reported by "make check"?

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.

My input file doesn't do what I want it to do

Try the “verbose” option!

How does DISORT work?

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

Where is the tools directory?

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.

How to redirect uvspec output

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).

uvspec on multiprocessor machines

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.

I have problems compiling libRadtran under Ubuntu

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.

How to implement loops in libRadtran

As you probably already found out, libRadtran does not offer the possibility to loop over input parameters although this is part of everyday life, e.g. to calculate solar irradiance as a function of solar zenith angle, or top-of-atmosphere reflectivity as a function of cloud optical thickness. There are two good reasons for not implementing loops: (a) it would add enourmous complexity to the libRadtran source code if we allowed loops over various input parameters; and more important, (b) there is a nearly infinite amount of scripting languages and tools that allow implementing whatever you have in mind in a much more flexible way than we could ever offer, e.g. scripting languages offered by any Unix Shell (bash, cshell, …) or higher-level languages like Python, Perl, AWK, … or maybe even Excel Macros (haven't tried that but it certainly works). Here is a simple example how you might do that in Unix: Suppose you want to calculate solar irradiance as a function of solar zenith angle. First, create a uvspec input file:

   atmosphere_file ../data/atmmod/afglus.dat
   correlated_k kato2
   output sum
   output_user sza eglo
   sza SZA

and store it in uvspec.template. In order to use it, create a simple shell script, e.g. loop.sh. Under bash (which is the standard shell under Linux and also under cygwin) it might look like

   for sza in 0 15 30 45; do
     sed s/SZA/$sza/ uvspec.template uvspec.template > uvspec.inp
     ../bin/uvspec < uvspec.inp >> uvspec.out
   done

Here sed is used to replace SZA by the actual solar zenith angle and the uvspec is called. Execute the script with 'sh loop.sh'! Looks like magic, and you get the following output in uvspec.out:

  0.000  1.110098e+03
 15.000  1.068581e+03
 30.000  9.472776e+02
 45.000  7.558466e+02

which is exactly what you wanted: Global irradiance as a function of solar zenith angle. Now suppose that you want to do that for thousands of solar zenith angles stored in a file, sza.dat:

  1  23.45
  2  17.32
  3  45.93
  4  ...

That is equally simple: Replace the loop in the above script by

   for sza in `cat sza.dat | gawk '{print $2}'`; do
     ...

The line looks a bit weird. cat simple lists the file and gawk (GNU AWK) extracts the second column. Of course that's not all you can do - please refer to the manuals of bash, sed, AWK, … or whatever you use. You might need to spend some time learning a new language but be sure that it pays off! Everything which has been calculated and published by the libRadtran group has been done in a similar way, sometimes using more weird languages (Perl), sometimes more readable (Python).

How to interpret the radiance output of libRadtran?

For those not used to the standard UNIX tools, that may be a pain in the neck! All you want to have are radiances but instead you get

 
 
faq.1284371438.txt.gz · Last modified: 2010/09/13 10:50 by admin
Recent changes RSS feed Creative Commons License Valid XHTML 1.0 Valid CSS Driven by DokuWiki
Drupal Garland Theme for Dokuwiki