Table of ContentsHow to convert to the new syntax?This is simple: We provide a Python script to translate from the old syntax (before July 2014) to the new syntax (after July 2014): python src_py/translate.py uvspec.inp > uvspecnew.inp 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 doTry the “verbose” option! How does DISORT work?There are several sources that describe the inner workings of DISORT. Please check out:
How to redirect uvspec outputuvspec 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 machinesThere are two ways of utilizing the power of all processors on a multiprocessor machines for libRadtran/uvspec calculations.
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 UbuntuIt 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. I have problems compiling libRadtran under MacOSPlease be assured that libRadtran works nicely under MacOS since some of the developers work on a Mac. To be able to build the libRadtran C and Fortran libraries and associated tools, you will need a number of packages provided by either macports or Homebrew. Both build upon the Apple developer tools Xcode, available in the App Store. Please note that Xcode is not sufficient because it does not provide a Fortran compiler. E.g. for macports that implies that you install the GNU C compiler, sudo port install gcc and a number of other packages like the GNU Scientific Library (libgsl), the GNU Multiple Precision Library (libgmp), and the NetCDF library sudo port install gsl sudo port install gmp sudo port install netcdf ... The rest is easy. Open a terminal under Max OS X and follow the standard libRadtran installation instructions. How to implement loops in libRadtranAs 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.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 libRadtranFor 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 400.000 1.711472e+03 2.040234e-03 2.600588e+02 1.361946e+02 2.709903e-04 4.893769e+01 0.000 1.00000000 6.844470215e+01 6.844470215e+01 401.000 1.695302e+03 1.212575e-03 2.554139e+02 1.349078e+02 1.535584e-04 4.815027e+01 0.000 1.00000000 6.716767883e+01 6.716767883e+01 402.000 1.790552e+03 -8.538017e-04 2.677181e+02 1.424876e+02 -6.538203e-05 5.060664e+01 0.000 1.00000000 7.032174683e+01 7.032174683e+01 403.000 1.671323e+03 1.793135e-03 2.478811e+02 1.329996e+02 2.162131e-04 4.695971e+01 0.000 1.00000000 6.504595184e+01 6.504595184e+01 That's the line with the irradiances and actinic fluxes (7 columns) followed by the azimuth angles (here only one column) and then the radiances. What you probably might want is the radiance for each wavelength. This a typical application for an AWK oneliner: ../bin/uvspec < uvspec.inp | gawk 'NF==7{wvl=$1};NF==3{print wvl,$3}' will produce what you want: 400.000 6.844470215e+01 401.000 6.716767883e+01 402.000 7.032174683e+01 403.000 6.504595184e+01 Simple, isn't it? AWK is powerful enough to extract whatever you want, in whatever format you want. It is part of standard Linux installations and of cygwin. Please check the AWK manual if you need more information. Alternatively, there are more modern scripting languages like Python but AWK probably cannot be beat with respect to effectiveness (defined as action done divided by characters typed). netcdf doesn't work under Windows/cygwinSee here! User defined aerosolThe most general method to setup your own aerosol (or cloud) properties is the following: profile_file 1D aer1 your_aerosol1.dat profile_properties aer1 your_aerosol1.cdf interpolate profile_file 1D aer2 your_aerosol2.dat profile_properties aer2 your_aerosol2.cdf interpolate ... This way you may combine as many aerosol species as you need. The profile_file includes mass concentration altitude profiles and particle size. The netcdf profile_properties_files include the aerosol optical properties (extinction, single scattering albedo, phase matrix, Legendre polynomials of phase matrix … ) and can be generated using e.g. the Mie tool in libRadtran, where you can specify refractive index and size distribution parameters (see examples/MIE_2.INP). Run bin/mie < examples/MIE_2.INP and you may use the output wc.mie.cdf as example for an optical properties file. |