Name: ISCCP Simulator ICARUS/SCOPS What: Simulate ISCCP cloud products from GCM inputs Version: 3.5 Authors: Steve Klein Mark Webb (Mark.Webb@MetOffice.gov.uk) # *****************************COPYRIGHT******************************* # (c) COPYRIGHT Steve Klein and Mark Webb 2004, All Rights Reserved. # Steve Klein klein21@mail.llnl.gov # Mark Webb mark.webb@metoffice.gov.uk markwebb@mail.com # ISCCP SIMULATOR icarus-scops version 3.5 # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # See also http://www.gnu.org/copyleft/lesser.txt # # The Met Office hereby disclaims all copyright interest in # the ISCCP Simulator ( a library which converts model clouds into # direct equivalents to the satellite observations of the ISCCP) # written by Steve Klein and Mark Webb # # Catherine Senior, August 2004 # Manager Climate Sensitivy Group # Met Office Hadley Centre for Climate Prediction and Research # FitzRoy Road Exeter EX1 3PB United Kingdom # *****************************COPYRIGHT******************************* ! *****************************COPYRIGHT******************************* This README file is written by Mark, and so references to 'I' or 'me' refer to Mark. 0. Contents ----------- 0. Contents 1. About the code 2. Conditions of use 3. No warranty 4. Compilation and testing 5. Points to be aware of when using the code 1) Are you running a correct version? 2) Calling the code from within your model. 3) Passing the cloud types in correctly. 4) Setting NCOL. 5) Setting the seed correctly. 6) Memory usage 7) Check the results against your total cloud amount. 8) Set top_height=1 for best comparisons with ISCCP IR-VIS. 9) Handling sunlit points. A) Meaning of outputs from the ISCCP simulator. 6. Revision history of released versions 7. Some other issues to consider 1. About the code ----------------- This is a code that can be used to take cloud and atmosphere information from atmospheric models and convert it into something that is comparable to data from the ISCCP. It has, in principle, two parts, which may in time be more clearly separated in terms of the code. SCOPS - Subgrid Cloud Overlap Profile Sampler. This is the core of the code (written by Mark) which samples the subgrid distibution of clouds within a model gridbox using a pseudo-random sampling process. It takes vertical profiles of convective and large scale cloud amount as input and applies a choice of cloud overlap assumptions to provide a number of cloud profiles sampled from random positions within the gridbox. ICARUS - ISCCP Clouds and Radiances Using SCOPS. This is the code (written by Steve) that emulates the ISCCP retrieval using the profiles extracted from the GCM gridbox using SCOPS. For more information, see Klein and Jakob 1999; Webb et al. 2001. 2. Conditions of use -------------------- Please refer to the copyright statement at the top of this file. Please note that a condition of the LGPL is that any modifications you make to the code must be made available to all third parties (including the authors) without charge under the LGPL. Please email us to let us know if you are using the code so that we can let you know about new releases. Please also acknowledge us in anything you write up, and cite: Klein & Jakob (Monthly Weather Review 1999) and Webb, Senior, Bony & Morcrette (Climate Dynamics 2001) 3. Other sources of information. ------------------------------- Announcements regarding the code will be made on a mailing list - see below for details on how to subscribe: Two mailing lists are available for news, updates and comments on the ISCCP Simulator software: isccp-simulator@metoffice.com (for technical announcements and queries about the simulator) isccp-simulator-projects@metoffice.com (for projects using the simulator - e.g. CFMIP) To subscribe, send a message to majordomo@metoffice.com with the following message body: subscribe isccp-simulator your.email@address.com The list is a closed one so only subscribers may post to the list. Subscription requests may take up to two working days to process. See also www.cfmip.net 4. Compilation and testing -------------------------- How to compile me: gunzip icarus-scops-3.5.tar.gz tar xvf icarus-scops-3.5.tar cd icarus-scops-3.5 make clean make You may need to change the name of the compiler in the Makefile, e.g. F77=f90 ( T3E ) F77=g77 ( GNU FORTRAN compiler ) How to test me: make test A successful test will look something like the following. $ make test test_isccp_cloud_types.ksh make[1]: Entering directory `/home/hc0300/hadmw/icarus-scops-3.4' make[1]: `test_isccp_cloud_types' is up to date. make[1]: Leaving directory `/home/hc0300/hadmw/icarus-scops-3.4' tests passed ok. An unsuccessful test looks something like the following: e.g. t3ea> make test test_isccp_cloud_types.ksh `test_isccp_cloud_types' is up to date. STOP (PE 0) executed at line 92 in Fortran routine '$MAIN' STOP (PE 0) executed at line 92 in Fortran routine '$MAIN' STOP (PE 0) executed at line 92 in Fortran routine '$MAIN' STOP (PE 0) executed at line 92 in Fortran routine '$MAIN' STOP (PE 0) executed at line 92 in Fortran routine '$MAIN' STOP (PE 0) executed at line 92 in Fortran routine '$MAIN' 4225c4225 < 0.17 0.30 0.00 0.00 0.15 0.00 0.00 --- > 0.18 0.30 0.00 0.00 0.15 0.00 0.00 4912c4912 < 0.30 0.17 0.00 0.00 0.15 0.00 0.00 --- > 0.30 0.18 0.00 0.00 0.15 0.00 0.00 there may be a problem with the test - files stdout and stdout.expected do not match. Make: "test_isccp_cloud_types.ksh": Error code 1 cmd-2436 make: Stop. Minor differences like those seen in this case can be caused by rounding characteristics in formatting on different platforms. I'd be interested to see any test output that has more serious differences than these. If you see something like this: [mark@sagan icarus-scops-3.4]$ make test ./test_isccp_cloud_types.ksh make[1]: Entering directory `/home/mark/icarus-scops-3.4' f77 -c test_isccp_cloud_types.f f77 -c isccp_cloud_types.f f77 -c ran0.f f77 test_isccp_cloud_types.f isccp_cloud_types.o ran0.o -o test_isccp_cloud_types make[1]: Leaving directory `/home/mark/icarus-scops-3.4' 916c916 < meantaucld = 0.00000 --- > meantaucld = 3.25000 1942c1942 < meantaucld = 0.00000 --- > meantaucld = 1.67000 2968c2968 < meantaucld = 0.00000 --- > meantaucld = 1.89000 3704c3704 < meantaucld = 0.00000 --- > meantaucld = 3.25000 4440c4440 < meantaucld = 0.00000 --- > meantaucld = 1.67000 5176c5176 < meantaucld = 0.00000 --- > meantaucld = 1.89000 then you are most likely unable to read the unformatted files containing the optical thickness weights - try setting readbinary=.false. near line 24 of test_isccp_cloud_types.f 5. Points to be aware of when using the code -------------------------------------------- 1) Are you running a correct version? There are various versions of the code around. If you didn't get the code directly from me, Steve, the GCSS DIME website or www.cfmip.net, what you have may not be what is described in the version history below. Just because it says it's version x does not mean that it is. A good way to check is to take what you have, run the tests supplied with the latest version and see if the results are as expected. If you have a version that doesn't look like one of the ones below, please send me a copy so that I can incorporate any improvements into a future release. In particular, if you are running with a version that says version 1.13 in isccp_cloudtypes.f, the results may be incorrect. 2) Calling the code from within your model. Before the vector version of the code was available, people looped over model grid points, calling the code column by column, either on all model points, or just those with daylight. Now that the code accepts vector inputs, you have the choice of continuing to do this, or of passing full model fields into the code. The latter approach is likely to be more CPU efficient, particularly on vector processors, but will use more memory. See the section on memory usage if you run out of memory. Although the input arrays are mostly of the form (npoints,nlevs), there is no problem passing in arrays of the form (nx,ny,nlevs) if that is more convenient for you. As long as npoints=nx*ny, this should be fine, although it is worth switching the debug logical on occasionally to check that all of the arguments are being passed correctly. 3) Passing the cloud types in correctly. When running with convective cloud, cc represents the _total_ cloud amount, which includes the convective fraction conv. i.e. cc = conv + stratiform. It is a common mistake to assume that cc = stratiform and conv = convective. The treatment of convective cloud assumes that you can maximally overlap the convective cloud first and then overlap the stratiform cloud in the remaining cloud free space according to the specified overlap type. This is consistent with the overlap scheme in Edwards/Slingo (in the HadCM3) model ( convective cloud maximally overlapped within but may not be true for schemes used for overlapping separate convective and stratiform clouds in other models. 4) Setting NCOL. The simulator uses a Monte Carlo method for sampling various columns within each model gridbox. The number of columns is set by the value of NCOL. The value that you want to set NCOL to depends on the accuracy you want and amount of averaging you are doing on the outputs. The recommended rule of thumb recommended by the authors is that you should aim for something like 2400 samples to keep statistical noise to a reasonable level. For example, if you are doing no averaging, (i.e. you are be calling the simulator once on instantaneous model variables and looking directly at the results), you should set might expect that you need to set NCOL to something around 2400. If you are looking at daily means, and are calculating this by averaging 8 3-hourly calls to the simulator, NCOL should be set to 300 ( = 2400/8 ) If, say, you are looking at monthly means, and are calling the simulator, say, every 15 hours, NCOL should be set to 50 =2400/(24*30/15) If you are looking at monthly means, and are calculating this by averaging 8 3-hourly calls per day to the simulator, NCOL should be set to 10 ( = 2400/(8*30) ) *WARNING* Running with NCOL < 10 is not recommended even if you are doing a lot of averaging on the results - I have experienced systematic biases when doing this myself, although this might not be a problem if the random number generator is seeded properly. Finally, don't forget to set NCOLMAX to be at least as big as NCOL, ( but not bigger than necessary as the amount of memory used is proportional to NCOLMAX.) ( ** Note that ncolmax is not required for versions 3.2 onwards. ) 5) Setting the seed correctly. It is essential that the seed for the random number generator is set to a different value for each model gridbox it is called on, as it is possible that the choice of the same seed value every time may introduce some statistical bias in the results, particularly for low values of NCOL. In the simulations in Webb et al 2001, this was done by setting seed=(pfull(nlev)-int(pfull(nlev)))*100+1, although this may or may not work for you. I now recommend something more like: seed=(pfull(nlev)-int(pfull(nlev)))*100000+1 as always seeding with a small number could in theory cause problems. >From version 2.2 onwards, seed is passed as an argument to isccp_cloudtypes. ( Note that a seed value of 50 is required to get the correct test output. ) 6) Memory usage If you find that you run out of memory setting large values on NCOL, try calling the simulator repeatedly and averaging the results. If you do this, set the seed before the first call but let subsequent calls use the value of the seed returned by the previous call. If you set the seed to the same value for each call, each call will give exactly the same results, defeating the object of the repeated call. 7) Check the results against your total cloud amount. It is strongly recommended that you check that the code is giving results consistent with the overlap scheme used in your radiation code. This can be done by: a) setting the sample size to a large values, ideally 10000 ( ncol=10000 or an average of 100 calls with ncol=100 ) b) running the code on a varied selection of inputs from your model c) summing the output from all of the cloud classes (including the ones representing points with tau < isccp_taumin ) and checking that this is statistically equivalent to the total cloud amount diagnosed in your radiation scheme for sunlit points. If you can't get this to agree, switch on the debug flag and check that the values are being passed in properly. Look at the code and see if you are using a value of overlap that is consistent with the overaps used in your radiation code. Failing that, I may be able to help, but can't guarantee to be able to modify the code to match your overlap assumptions. 8) Set top_height=1 for best comparisons with ISCCP IR-VIS. It is recommended that for best comparison with ISCCP IR-VIS products the code be set to calculate effective rather than actual cloud top pressures i.e. set top_height to 1 for comparison with VIS/IR daytime products (consistent with Webb et al 2001.) However if you want to examine nighttime products from ISCCP, the option set top_height = 3 would be the best one to compare to at night. Using top_height = 1 at night would be significantly worse in this case. 9) Handling sunlit points. for top_height=(1 or 2) the input array sunlit should be set to 1 for day points and 0 for nighttime points. The outputs are set as described below: for the following values of top_height. These output domains are set on the assumption that the outputs will be compared with the ISCCP variables shown below (documented at http://eosweb.larc.nasa.gov/PRODOCS/isccp/table_isccp.html -> D1 parameters list. -> DX parameters list ) all points (A), sunlit points only (S) or not diagnosed (0) top_height=1 ------------ diagnostic domain comparable ISCCP diagnostic fq_isccp, S D1 30d-71d totalcldarea, A D1 12 Number of cloudy pixels meanptop, S D1 78 Mean PC for cloudy pixels (VIS-adjusted day, unadjusted night) meantaucld, S D1 92d Mean TAU for cloudy pixels boxtau, S DX 26. VALBTA : VIS retrieved cloud tau or surface albedo DX 30. VTAUIC : VIS retrieved ice cloud tau boxptop S DX 29. VPRS : VIS adjusted cloud top pressure Please note that currently meanptop is not diagnosed in the IS for night-time points if top_height=1, although ISCCP D1 item 78 is available for day and night points. For top_height=1, meanptop should only be compared to item 78 for sunlit points. top_height=2 ------------ as for top_height=1 top_height=3 ------------ diagnostic domain comparable ISCCP diagnostic fq_isccp, A d1 23-29 Cloud top pressure distribution (unadjusted PC) ( although this is in 7 classes rather than 49, so you need to sum over the different tau classes, excluding the ones for tau below isccp_taumin) * totalcldarea, A d1 13 Number of IR-cloudy pixels meanptop, A d1 79 Mean PC for IR-cloudy pixels (unadjusted) meantaucld, 0 not diagnosed boxtau, 0 not diagnosed boxptop A dx 18. IPRS : IR retrieved cloud top pressure * Note from Steve: Note that we have a problem here. One thing I didn't sort out was that for the ir-only method what would be a minimum cloud emissivity for which the ir-threshold method would not detect cloud. Probably the most defensible method, which would not be hard to implement, would be to compare the clear sky and cloudy sky brightness temperatures. If the difference is less than the ir-thresholds then the cloud would not be seen by ISCCP. The table of ir-thresholds is table 3.2.4 of ISCCP documentation. This table is scene-type (e.g. ocean/land/coastal/high topography/snow covered) dependent. Thus the simulator inputs would need to have this information included. This will take time to build. For now probably the best thing is to do is to note that the isccp_taumin thresholding is not the best but an interim measure until a proper method (i.e. the last paragraph) can be implemented. A) Averaging of outputs from the ISCCP simulator. It is important to be careful when averaging the outputs from the IS when top_height=(1 or 2) as some variables are output only on sunlit points. The way that I do this is to average the outputs as they come out, and also to average the values of the sunlit variable ( 0 = night, 1 = day ) ( note that the average needs to be a REAL although sunlit is an INTEGER.) The true average of the variables output on sunlit points can be calculated by dividing the variable average by the average of the sunlit indicator. An alternative approach is to set the nighttime points in the daytime only diagnostics to some sort of missing data indicator (not 0 though!) and average using some code that understands this. Mark Webb ________________________________________________________________________ 6. Revision history of released versions ---------------------------------------- Changes made by Mark Webb from version 3.4.1 to 3.5 Version released under LGPL ( GNU Public License ) Introduced a new random number generator to allow release under LGPL. Results should be statistically equivalent to 3.4 Minor changes to the README file on seeding. Updated Steve's email address _______________________________________________________________________________ Changes made by Mark Webb from version 3.3 to 3.4. Changes made by Mark Webb from version 3.4 to 3.4.1 Changes to the README file mainly on guidance for setting NCOL. Code exactly as 3.4 _______________________________________________________________________________ Changes made by Mark Webb from version 3.3 to 3.4. Default value for attrop changed to 120K, on request from Steve. Reference to nlevmax removed from isccp_cloud_types.f - this caused a segfault when running the tests under Linux/g77. Moved initialisation of tauchk to start of isccp_cloud_types.f as it was not being initialised for top_height = 2. Various minor changes to the README file requested by Steve. _______________________________________________________________________________ Changes made by Mark Webb and Steve Klein from version 3.2 to 3.3. Converted debug to be an integer value - 0 = no printing, non-zero specifies the step with which the printout loops over j. Added debugcol allow separate activation of box printout. Modified tropopause diagnosis: Previously, the code worked by starting at the top of the atmosphere and working down, setting the tropopause temperature to the layer temperature as long as the layer temperature is greater than in the layer below - i.e. the tropopause temperature was the temperature of the lowest layer that is in or near to the stratosphere. The problem with this is that if the atmosphere is isothermal, or if temperature monotonically decreases with height, attrop is never set, and the default value of ptrop of 50mb is used. The main effect of this was (in the cases where a tropopause was not found ) to set the cloud tops pressures for pixels with optical thickness around .3 or less to 50mb. This is not thought a serious problem, as most of the cloud affected is below the detection threshold for ISCCP anyway. This version has been modified to diagnose the tropopause as the coldest level between 400mb and 50mb. A tropopause will always be diagnosed if the inputs have pressure levels between these levels. Failing that, ptrop will be set to 50Mb, and attrop will be set to 0K. This is safer than setting attrop to, say, 200K as the emissivity correction for optically thin clouds does not work properly if the cloud temperature is lower than that of attrop. _______________________________________________________________________________ Changes made by Bryant McAvaney going from version 3.1 to 3.2. Bryant made the following changes: renamed: isccp_cloudtypes.f, test_isccp_cloudtypes.f, test_isccp_cloudtypes.f to isccp_cloud_types.f, test_isccp_cloud_types.f, test_isccp_cloud_types.f to avoid problems when using interactive debugger. itrop -> itrop(npoints) ( fix for bug in version 3.1 ) initialised attrop to 200K and itrop to 1 ( as were uninitialised on occasions where tropopause code failed to find a tropopause. ) now only do emcld adjustment to fluxtop if tau(j,ibox) .gt. (tauchk) - this aviods floating exceptions when ir inputs are passed with no or v. small vis values e.g. at dawn/dusk removal of ncolmax, nlevmax added debugcol logical for column printout modified most of ncolprint loops to work in vector mode re-ordered write statements under 'debug' to match argument list initialised boxtau,boxptop,box_cloudy moved bb emission calc out of ibox loop added rec2p13 to hold reciprocal of 2.13 added tauchk to hold -1.*log(0.9999999) value moved btcmin calc out of ibox loop _______________________________________________________________________________ Changes made by Mark Webb in going from Version 3.0 to Version 3.1 ( ** Please note that a bug has been found in this version. The tropopause index itrop was not dimensioned over npoints. This is corrected in version 3.3 ) This version is scientifically equivalent to version 3.0, but is optimised to run more efficiently on vector processors such as the NEC SX-6. It should be bit reproducible with version 3.0. Please let me know if you find a situation where the two versions give difference answers for consistent inputs. To do this I have had to modify isccp_cloudtypes.f to accept vector inputs rather than single column inputs. This version can still be called column by column, ( just set npoints to 1 ), but this is very inefficient on vector architectures. A few new arguments have been added - I have put these at the start of the argument list to make them easier to spot. debug is a logical which, if set to true, tell isccp_cloudtypes to print out lots of diagnostics to unit 6 and unit 9. debug is set to true in test_isccp_cloudtypes.f, and is useful for checking that you are passing all of the relevant arguments in correctly. npoints is the number of grid points in the horizontal that you want to process. Most of the input variables now have npoints as their first array dimension, and most of the inner loops in isccp_cloudtypes loop over this array dimension, (and do vectorise on the sx-6). The larger the value of npoints, the better the performance you are likely to get on a vector processor. The code is not structured to vectorise over loops over ncol/ibox, although a small number of these do. sunlit should be set to 1 for day points and 0 for nighttime points. See the section below on handling sunlit points for a discussion of the related issues. Added sections on setting NCOL, handling sunlit points, and averaging to the 'things to bear in mind' section. _______________________________________________________________________________ Changes made by Steve Klein in going from Version 2.2.1.1 to Version 3.0 *** Please note that moving to this version changes the results given by the code *** 1. Based upon e-mail correspondance with Bill Rossow, the minimum visible optical thickness ISCCP is assumed to detect is set to 0.3. Previous versions used 0.1. 2. Provisions haven been made for an IR-only cloud top pressure adjustment. This permits comparison to ISCCP data at night. This is done by adding a third option to top_height which will be the IR-only adjusted top option. Note that the previous adjusted option used the visible optical depth to adjust the cloud emissivity. NOTE that one must still pass the visible optical depth to the code even if one wishes IR-only calculations. This is done primarily to count the abundance of cloud types in different visible optical thickness categories. Comparison to IR-only ISCCP data is accomplished by summing over all categories of optical thickness for a given cloud top pressure interval. 3. Previous versions of the code assumed that tau-ir = tau_vis / 2.13 . Note that 2.13 is the ice microphysics conversion factor. An error comes from using this factor for liquid phase clouds where the appropriate factor is 2.56. This has been accomodated by a small iteration loop after the calculation of the cloud brightness temperature. If the cloud brightness temperature is greater than 260K (ISCCP's ice cloud threshold) then the calculation of cloud brightness temperature is repeated using 2.56 instead of 2.13. The next minor correction is based upon a more careful reading of page 86 of the ISCCP documentation (available from the ISCCP web site): Rossow, W.B., A.W. Walker, D.E. Beuschel, and M.D. Roiter, 1996: International Satellite Cloud Climatology Project (ISCCP) Documentation of New Cloud Datasets. WMO/TD-No. 737, World Meteorological Organization, 115 pp. 4. Following the calculation of TRANS-MAX described towards the bottom of page 86, cloud top pressure is set to the tropopause pressure if tau < taumin based upon transmax. In previous versions though, conversion of taumin from IR-tau to VIS-tau before comparison to tau(ibox) was overlooked. Also at this point, the cloud top temperature is assumed to be 5 K colder than the tropopause temperature. Note that the documentation says the "cloud top pressure equals tropopause pressure". ============================================================================ Changes made by Mark Webb in going from Version 2.2 to Version 2.2.1.1 A very minor change was applied to test_isccp_cloudtypes.f to avoid a problem with some stricter compilers which do not allow constants arguments to be overwritten in the called routine. This was happening because I was passing a constant 50 into the seed argument of isccp_cloudtypes instead of the variable seed. Minor changes also made to Makefile and test_isccp_cloudtypes.ksh to remove the need for . in $PATH. Mark Webb 2/7/2002 ============================================================================ Changes made by Mark Webb in going from Version 2.1 to Version 2.2 1) seed is now passed in as an argument. This makes it easier for the user to follow the advice in the README file wrt setting different seed values for subsequent calls. 2) a couple of lines were > 72 chars long, which gave errors with my compiler. 3) use of formatted write statements to print out values of totalcldarea, meanptop, meantaucld ( unformatted writes make the tests fail with different compilers as they output different white space characters. I can't ignore white space in the comparison because this could mask errors in the overlap output. ) 4) changes to the formats of some other write statements to reduce false errors with different rounding characteristics in formatting on different platforms. 5) the binary files containing the enery weightings only work on some platforms - I have added formatted versions that can be used as alternatives - specify readbinary=.false. in test_isccp_cloudtypes.f. Mark Webb 26/6/2002 ============================================================================ Changes made by Steve Klein in going from Version 2.0 to Version 2.1 The code was modified so that the primary subroutine, ISCCP_CLOUD_TYPES, now returns the fraction of columns that contain cloud ('totalcldarea'), the mean cloud top pressure in the cloudy portion of the grid box ('meanptop'), and the energy-weighted mean optical thickness ('meantaucld'). Note that if the grid box contains no clouds whatsoever that meanptop and meantaucld are both zero. In addition, the code now returns the output on a column by column basis of the cloud top pressure ('boxptop') and optical depth ('boxtau'). If no cloud exists in the column then both these variables are zero. In computing the energy-weighted mean optical thickness, the tables used by ISCCP are applied. These tables are in binary files 'tautab.bin' and 'invtau.bin' supplied in the tar file. Note that the size of the invtau vector is 45021, rather large. These binary files are read by the test_isccp_cloudtypes.f and passed as new input arguments to ISCCP_CLOUD_TYPES. The 'stdout.expected' file is modified from that of version 2.0 in that the additional fields output by ISCCP_CLOUD_TYPES (totalcldarea, meanptop, meantaucld, boxtau, boxptop) are added. Apart from the additions the stdout.expected file is identical to that in version 2.0. ============================================================================ What's new in 2.0 since 1.17.1.1: o No functional changes o The tests can now be run using 'make test' o There is now a README file o All write statements in the tests should use formatted I/O, which makes it easier to check whether the tests have passed on different platforms. _______________________________________________________________________________ Version 1.17.1.1 was made available to a few people by Steve in a tar file called new_isccp_mark_steve.tar. Note that the version number in isccp_cloudtypes.f is 1.16 although this version is not the same as version 1.16. The contents were: $ tar tvf new_isccp_mark_steve.tar rwxr-xr-x 1116/77 0 Oct 28 18:57 1999 isccp_mark_steve/ rw-r--r-- 1116/77 389120 Oct 28 18:59 1999 isccp_mark_steve/Makefile rw-r--r-- 1116/77 2595 Aug 15 18:02 1999 isccp_mark_steve/coldecomp.steve.data rw-r--r-- 1116/77 4534 Aug 14 15:57 1999 isccp_mark_steve/input.data rw-r--r-- 1116/77 870 Aug 14 15:40 1999 isccp_mark_steve/input.data.mark rw-r--r-- 1116/77 4534 Aug 14 15:56 1999 isccp_mark_steve/input.data.steve rw-r--r-- 1116/77 34106 Oct 28 18:55 1999 isccp_mark_steve/isccp_cloudtypes.f rw-r--r-- 1116/77 325816 Aug 15 17:50 1999 isccp_mark_steve/output.steve.data rw-r--r-- 1116/77 601 Aug 14 16:06 1999 isccp_mark_steve/ran0.f rw-r--r-- 1116/77 442 Aug 5 16:25 1999 isccp_mark_steve/rcs_ids rw-r--r-- 1116/77 3045 Aug 15 18:19 1999 isccp_mark_steve/test_isccp_cloudtypes.f What was new in 1.17.1.1 compared to 1.17. o No functional changes o Steve's changes to various boolean expressions to improve portability. _______________________________________________________________________________ What was new in 1.17 compared to 1.16. o new code to handles water vapour o uses a better tau - emissivity relationship o notes cloud amounts with tau < 0.1 Version 1.17 was distributed by Steve in a tar file which was most likely called isccp_mark_steve.tar ( I don't have a copy or the tarfile! ). Note that the version number in isccp_cloudtypes.f is also 1.16 although this version is not the same as version 1.16. This version of isccp_cloudtypes.f is 33348 bytes long. _______________________________________________________________________________ Version 1.16 was distributed by Mark in a file called isccp_mark.tar ( as were some previous versions ). This was in August 1999 The contents were: $ tar tvf isccp_mark.tar r--r--r-- 275/107 28516 Aug 3 17:20 1999 isccp_mark/isccp_cloudtypes.f r--r--r-- 275/107 2769 Aug 5 16:22 1999 isccp_mark/test_isccp_cloudtypes.f r--r--r-- 275/107 587 Jul 29 10:51 1999 isccp_mark/ran0.f r--r--r-- 275/107 791 Aug 5 16:24 1999 isccp_mark/input.data r--r--r-- 275/107 432 Aug 3 15:57 1999 isccp_mark/Makefile rw-r--r-- 275/107 442 Aug 5 16:25 1999 isccp_mark/rcs_ids What was new in 1.16 compared to 1.13. o correct treatment of top_height=2 o correct treatment of convective cloud in random & max overlap cases o correct treatment of stratiform cloud above convective cloud _______________________________________________________________________________ Version 1.13 was distributed by Mark in a file called isccp_mark.tar in July 1999. Note that this version was still in development and had the following problems which were ironed out later: o doesn't work for top_height=2 o convective cloud not treated properly in random or max overlap cases o stratiform cloud above convective cloud not quite right -rw-r--r-- 1 hadmw mec 40960 Mar 20 09:53 isccp_mark.tar $ tar tvf isccp_mark.tar r--r--r-- 275/107 27454 Jul 29 10:48 1999 isccp_mark/isccp_cloudtypes.f r--r--r-- 275/107 3931 Jul 29 10:54 1999 isccp_mark/test_isccp_cloudtypes.f r--r--r-- 275/107 587 Jul 29 10:51 1999 isccp_mark/ran0.f r--r--r-- 275/107 1619 Jul 29 11:07 1999 isccp_mark/input.data r--r--r-- 275/107 582 Jul 29 11:36 1999 isccp_mark/Makefile rw-r--r-- 275/107 441 Jul 29 11:36 1999 isccp_mark/rcs_ids What was new in 1.13 compared to 1.1. o Various changes to make FORTRAN code consistent with Mark's PV-Wave including: o support for convective as well as stratiform clouds in the same gridbox o pseudo-random sampling method to fix 'left fill' problem _______________________________________________________________________________ Version 1.1 Steve's box code, as used in Klein & Jacob 1999. Received by Mark in July 1999. isccp_cloudtypes.f is 22230 bytes long. This version doesn't support convective clouds, and suffers from the 'left fill' problem. _______________________________________________________________________________ 7. Some other issues to consider --------------------------------- Steve's email accompanying distribution of release 1.1 in Jan 1999. > NOTES/QUESTIONS/ISSUES TO BE RESOLVED BY THE GROUP AS A WHOLE > > 1. Following our discussion, we have agreed that the optical depth used > should be exactly the same as that used in the host GCM. Thus the > program takes as input the optical depth in each model level. OK? > > 2. The program takes each vertical profile of cloud cover and subdivides > an atmospheric column into homogenous columns. The suggested number of > columns is 100. It is important to note, that the cloud COVER not > cloud FRACTION of each model level is required as input. For example > the GISS GCM assumes something that the clouds do not fill the grid > box in the vertical completely (at least they did in DelGenio's 1996 > paper). They will need to convert their cloud fraction to a cloud cover > before input. > > 3. Cloud top pressure is determined by 2 methods. If top_height is set > to 2, then the cloud top pressure is set to be the mean pressure of the > highest cloudy level of each sub-column that contains clouds. This is > done in the line: > > ptop(ibox)=pfull(ilev) > > A choice is made here in that one could use the half-pressure level at > the top of a given pressure level. I suppose users will customize. OK? > > 4. The second method for determining cloud top pressure (used it top_height > is set to 1), computes an approximate 11 micron radiance and then follows > ISCCP procedures (assuming a single level of cloud) to determine the cloud > top pressure. To do this the program requires more input including: > the model's cloud 11 micron emissivity in each level, the surface skin > temperature, the air temperature, and the surface's 11 micron emissivity. > Questions that arise here are: > > (a) Should we include a rough simulation of the water vapor continuum > as is done in Yu et al., Climate Dynamics, 1996, pages 389-401.? > If we do, we will need the specific humidity of water vapor in each > level, and a formula for the continuum. I would use the Roberts > formula used in Yu et al. which is much simpler than the one used > by ISCCP (see D level documentation page 77). > (b) If data is not easily available, should we assume a longwave > emissivity for the skin or a temperature relationship between the > model's temperature and the skin temperature? ( Note Steve added the continuum treatment at version 1.17 ) > 5. What is the minimum optical depth we should assume ISCCP clouds can detect? > 0.1 (the default of the program) or 0.2? Should we create (not done in > the current program) a separate tau category for all the clouds with tau > less than taumin. ISCCP experts opinions are most needed here. ( also done at 1.17 ) > 6. To distribute the clouds, you need to have an overlap assumption. Currently > the program has 3 options: maximum, random, and maximum-random. The > program default is max-random, so that to use the other programs you will > need to edit the program and uncomment the alternative line of code to > change the overlap assumption. Don't forget to comment the line of code > for max-random then. (Search the program for 'CLOUD OVERLAP > ASSUMPTION' to find these lines of code) > > 7. Horizontal Cloud Inhomogeneity. Currently the program distributes the > cloud optical depth (and longwave emissivity if used) evenly in the hor- > izontal. Users may wish to do other things here depending on their > model's assumptions. Note that if you change this, you have to make > an assumption about the vertical correlation of the cloud inhomogeneity > (e.g. are the thicker parts of the cloud in level i, directly beneath > the thicker parts of the cloud in level i+1). The line of code to change > for optical depth is: > > do 16 ibox=1,ncol > tau(ibox)=tau(ibox)+real(BOX(ilev,ibox))*dtau(ilev) > 16 continue > > where ibox is the index variable for the number of columns. > The three places the longwave emissivity is used (variable name dem) > will also need to be changed if you decide to have horizontal cloud > inhomogeneity. > > Cheers, > Steve _______________________________________________________________________________