I have attached the code package of HIRLAM's radiation scheme adopted to ARPEGE/ALADIN system. The text below contains following topics: 1. Description of the F90-code. 2. Status of the RADIA implementation work. 3. radia.F90 in HIRLAM? 4. Cleaning issues. 5. Questions to Bent about implementation of STRACO and RADIA to Aladin. 1. Description of the code: ############################ The radiation scheme of HIRLAM has been build up over the Bent's straco2aladin implementation dated 24.5.2005. The package contains following RADIA related files. arp/module/yomhir3.F90 (former COMRAD.inc) apr/setup/suhir3.F90 (main part of former subroutine inirad) arp/phys_dmn/suhirad.F90 (remaining part of former subroutine inirad) apr/phys_dmn/aradia.F90 (former subroutine aradia) apr/phys_dmn/radia.F90 (former subroutine radia) apr/phys_dmn/cloudhir.F90 (former CLOUD.f) Other files related to Aladin: apr/setup/suphir.F90 (calls suhir[1-3].F90) apr/phys_dmn/aplparh.F90 (Aladin's PHYS) apr/phys_dmn/hirlamrad.F90 (interface from aplparh to radia) At the moment, the current implementation designed to be used together with other HIRLAM physics (i.e. straco). Therefore, all the files from Bent's implementation are also required. Module "yomhir3.F90" replaces the former common block from "COMRAD.inc". Some non-used variables were removed from the module (see comments from the file). By contrast, emc, csusa, fabso3 and cadd were added as dynamical arrays. Module YOMHIR3 is initialized by "suhir3.F90" and "suhirad.F90" (SUHIR3 + SUHIRAD = HIRLAM's inirad). "suhir3.F90" sets up variables, which does not need any information about number of levels etc. "suhirad.F90" sets up the rest (emc,csusa, fabso3 and cadd). The "cloudhir.F90" is the HIRLAM's "CLOUD.f". I had to change the name, because APREGE/IFS/ALADIN already has a code named "cloud.F90". I don't know do we actually need this. Maybe we could use some of the Aladin codes (e.g ACNEBT,ACNEBR,ACNEBN). "aradia.F90" is the interface from HIRLAM's PHYS.f to radia.F90. "hirlamrad.F90" is the interface from Aladin's "aplparh.F90" to "radia.F90". Here, I calculate some input parameters for radia, which are not directly available from Aladin. An additional logical switch (FROMHIR) is added to argument lists of "radia.F90" and "suhir3.F90". The purpose of this is to skip the parts of the code, which are not needed, if the code is called from Aladin. The switch is used when updating the declination and zenith angles. 2. Status of the RADIA implementation work. ############################################ I have placed the codes to Aladin system (cy28t3) installed in hpcd@ecmwf. They are compiled, but not yet tried. There are still some open questions (see section 5). As mentioned earlier, RADIA should work together with straco. I have utilized Bent's switch LHIR (namelist NAMHIR), which activates HIRLAM physics in ALADIN. The output from RADIA to ALADIN consists 4 variables: SW and LW surface fluxes (sswdn and slwdn), and SW and LW net fluxes on half levels (swnet and lwnet). All these were already available in RADIA. 3. radia.F90 in HIRLAM? ####################### I have tried to modify the code gently, so it would be possible to use it in HIRLAM Fortran77 environment. However, the F90 code still would require some editing, if it is used in HIRLAM. All the codes use extensively Aladin's module PARKIND, which defines the accuracy of the floting point numbers. This module should be taken from the Aladin. There are also some debugging(?) modules (DrHook), which might have to be commented out in HIRLAM environment. If all the other physics codes are from original HIRLAM except the radiation, the modules YOMHIR1 (CONFYS.inc) and YOMHIR2 (COMCONDS.inc) should be replaced with original common blocks. 4. Cleaning issues. ################### When doing the RADIA modification, I haven't really touched the code cleaning issues. One might say that the new F90 code is even messier than the original one due to splitting of the inirad. However, there are several places to improve. Laura has a preliminary list of these spots and I try to summarize some of my findings. Some cleaning I did. The arrays emc, cadd, fabso3 and csusa are removed from the parameter list of RADIA and placed to the module YOMHIR3. It seems to be useless to carry these variables through different subroutines, when they are initialized once and used only in RADIA. Variables csur2, cetyp, chybcr, remx are not used anywhere, and therefore are removed from the module YOMHIR3. RADIA updates variables related to sun-earth geometry (e.g. declination angle) inside the code. It would be more attractive to "externalize" the updates of these variables (declination and zentih angles). If HIRLAM would have this kind of update routine (as it is in Aladin), then the FROMHIR switch would become unnecessary. In RADIA, there are some variables like zbeta, tlow and npower, which are not used. These should be deleted. Is the ARADIA really needed anymore? It declares several working arrays of RADIA. If these declarations are not needed anymore then ARADIA could be abandoned. Then the number of input parameters of RADIA could be considerably reduced. 5. Questions to Bent about implementation of STRACO and RADIA in Aladin. ######################################################################## Finally, some questions that arised when I studied the codes. i) RADIA needs the amount of cloud condensate as input parameter. ACONDS has 2 output parameters PQL and PQI, which I have interpreted to be cloud water and cloud ice, respectively. I sum (cw=PQI+PQL) these before RADIA call. Is this right thing to do? This addition is done also in CONDST. However, the result is multiplied by 100000. Why is that? Does the values of PQL (cw) and PQI (cice) really come out from the straco? They are labeled as input/output arguments in ACONDS, but only input arguments in CONDS! ii) Another input parameter for RADIA is the 3-D fractional cloud cover "totcov". You have stored the content of totcov in variable PA (in APLPARH). Can I use it as "totcov" in RADIA? iii) RADIA's input parameter dpf (pressure difference between model half levels) is needed also in ACONDS. I have used ALADIN's variable PDELP. You have calculated this in ACONDS. Is there some reason, which I have missed, not to use PDELP? iv) The last question arised in the compiling phase. In the "cpg.F90", you have introduced 2 new input parameters for MF_PHYS (between !cbhs comments). However, in mf_phys.F90 there is only one extra input parameter (PAT0). Should there be one or two extra parameters? I took the latter one away from the MF_PHYS call. Is this OK?