1 / 31

Implementing the ECOCLIMAP database in HIRLAM

First Step towards a Well Structured Surface Scheme Source Code Han The. Implementing the ECOCLIMAP database in HIRLAM. LAI*. Parameter fields. ECOCLIMAP: structure. landuse dataset. Equations. parameters per landuse class.

svein
Download Presentation

Implementing the ECOCLIMAP database in HIRLAM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. First Step towards a Well Structured Surface Scheme Source Code Han The Implementing the ECOCLIMAP database in HIRLAM

  2. LAI* Parameter fields ECOCLIMAP: structure landuse dataset Equations parameters per landuse class *LAI implemented as a fixed parameter per land use class (10-days avg.)

  3. ECOCLIMAP Quick Implementation: • Use the ECOCLIMAP software to create the parameter fields to replace the Climate script Disadvantages: • Current HIRLAM code not suitable to handle all parameters • Future implementation of assimilated LAI not possible

  4. New Structure (F77-based; provisional) purpose To cluster single fields into logical multi-dimensional arrays to: • reduce the number of function arguments • simplify the global structure • simplify the introduction of new fields and layers

  5. New Structure: storage • (mostly) constant surface fields:REAL TOPO(NX,NY,NFLD)roughness lengths, tile fractions, LAI etc. • index fields:INTEGER ITOPO(NX,NY,MFLD)soil type and vegetation type index • soil physical quantities stored as 3-D arrays:soil moisture, soil temperature: SWI(NX,NY,NSOIL,NTYPE)

  6. New Structure: access to separate fields Field names are stored in include file TOPO.inc as parameters

  7. TOPO.inc (provisional) integer NFLD c fields in TOPO array integer _LAI, _VEG, _ROOT, _RSMIN, _ALB, _SALB, + _Z0VEG, _Z0H, _SAND, _CLAY, _FIS, _TILE, + _SEA, _ICE, _BAR, _LOW, _HIGH, + _Z0ORO, _LAKE, _LAND, _Z0SEA, _TSCL, _SWCL parameter (_SEA = 1, ! sea fraction + _ICE = 2, ! ice fraction ... + _ALB = 8, ! grid albedo + _Z0H = 15, ! z0 for heat + NFLD = 15) ! total number of climate fields c fields in ITOPO array integer MFLD parameter (MFLD = 1) integer _SOIL parameter (_SOIL = 1) ! soil type integer NSOIL parameter (NSOIL = 2) ! number of soil layers <EOF>

  8. New Structure: rules • Never use the parameter value, e.g.:TOPO(1,1,_ALB) instead ofTOPO(1,1,8) • At lowest level pass the required field and not TOPO as an argument, e.g.: CALL SURCOF_LAND(KSTART,KSTOP,NHOR,NLEV,JTYP,LHIRSN, + TOPO(1,_Z0VEG),TOPO(1,_Z0ORO),ZWS,ZWSMX,ZWFC, + ZITM,ZSNS,ZTS,ZVEG0, … • First five fields in TOPO(:,:,:) correspond to the tile fractions FRACI(:,:,:), i.e. you can pass TOPO as a function argument for the tile fractions (FRACI) instead of TOPO(1,1,1)

  9. New Structure: storage ITOPO replaces constructions like: JQQ=NINT(((PFRACI(JL,JTYP)-RFRLIM)/(ZEPS+ABS(PFRACI(JL,JTYP) & -RFRLIM))+1.)*0.5) JSOL=NINT(PSOILI(JL,JTYP))*JQQ+1-JQQ JSOL=MAX(1,MIN(JSOL,11)) by: JSOL = ITOPO(JL,_SOIL)

  10. New Structure: code • Modifications based on version 6.3.7 • Numbers of files affected: 40

  11. Other points of discussion concerning the recoding

  12. Naming conventions • Currently, there are no strict directions • Many different names for the same variable • Unclear coding and • Reduncancy (unnecessary temporary arrays and variables)

  13. Naming conventions Generally, semantic-related naming conventions do not improve coding except for external/global variables: • where to find the variable declaration/initialisation (e.g. reference to an include file) • type (parameter, index, structure, etc.) • usage (Hirlam code) Generally, there is a need for stricter definitions of variable names e.g.: fixed names for global variables (passed through as function arguments) throughout the code

  14. Naming conventions: examples In SAPP.f: Land fraction is defined twice: FRLAND (function argument; not used) ZFRLAND (local variable; initialised and used instead)

  15. Constant parameter fields

  16. Constant parameter fields: initialisation • TXT.DAT: saturation point, field capacity, wilting point • INIISBA: fractions of sand and clay • INI_VEG: veg parameters + WROUS, WVEG, WLAI • INIPHY: tile fraction, vegetation type • SUR2RAD: albedo

  17. Constant parameter fields: checks • INIPHY: most fields, tile fractions, vegetation type • ISBAH4: soil type and vegetation type, z0veg JSOL=MAX(1,MIN(JSOL,11)) JVEG=MAX(1,MIN(JVEG,18)) • TQUV: roughness length DO I=1,NHOR Z0(I)=MAX(Z0(I),5.E-4) Z0(I)=MIN(Z0(I),3.) ENDDO • SAPP: land fraction • SUR2RAD: vegetation type

  18. Constant parameter fields: tile fractions

  19. Constant parameter fields: tile fractions In HDF-file: sum of fraction equals 1 (within single precision) With conversion to GRIB precision is lost. Internal check is always required before usage Currently, this happens in INIPHY In the surface analysis routines there is no check. As a result the land masks in AN en FC differ

  20. Constant parameter fields: tile fractions in ANALYSIS: FIELD PARAMETER INDEX LONG. LAT. AVERAGE STD. DEV. FRACTION OF LAND (1=LAND; 1 -41.61 11.95 0.461639 0.475845 in FORECAST: FIELD PARAMETER INDEX LONG. LAT. AVERAGE STD. DEV. FRACTION OF LAND (1=LAND; 179 -13.63 26.51 0.449246 0.479794

  21. Constant parameter fields: I/O There must be a single API routine to read/write for both Hirlam and Hirvda: GETDAT/PUTDAT • All consistancy checks must do done within GETDAT • The user must have the guarantee that the fields throughout the code is obtained from GETDAT

  22. Function declarations and calls

  23. Function declarations and argument lists: examples Not readable (representative): C----------------------------------------------------------------------- SUBROUTINE ACVEG ( KIDIA,KFDIA,KLON,KLEV, C----------------------------------------------------------------------- C - INPUT 2D . * PAPRSF, clrb PFRSO, * SSWNET, PQ,PQSAT,PT, clre C - INPUT 1D . * PD2,PITM,PIVEG, clr PALB, * PLAI,PNEIJ,PVEG,PRSMIN, * PCHROV,PGWDCS,PWFC,PWSAT,PWL,PWWILT,PWP,PQSATS, C - OUTPUT 1D . * PHQ,PHTR,PHU,PHV,PWLMX, C - TEMPORAIRE 1D . * PZDELTA,PZRSTO )

  24. Function declarations and calls: examples Not useful (I: integer; R real): SUBROUTINE LNDTQ2( KMONTH, KDAY, I KLON , KLAT , KLEV , KTYP R , PAHYB , PBHYB ... Random: SUBROUTINE POSTPP(MYPE $ ,NLON_GLOBAL ,NLAT_GLOBAL X ,NLEVML, LTYPML,ALEVML,NWMOML,IWMOML X ,NSL , LTYPSL, IWMOSL, ALEVSL X ,LPHYS , LOMEGA $ ,NLEV , NLON , NLAT , NTYP ...

  25. Function declarations and calls: proposed format SUBROUTINE ACVEG ( r KIDIA, KFDIA, KLON, KLEV, PAPRSF, r SSWNET, PQ, PQSAT, PT, PD2, PITM, PIVEG, r PLAI, PNEIJ, PVEG, PRSMIN, r PCHROV, PGWDCS, PWFC, PWSAT, PWL, PWWILT, PWP, PQSATS, w PHQ, PHTR, PHU, PHV, PWLMX, m PZDELTA, PZRSTO) rinput (constant/readable): must be initialised before call; no local copy needed; woutput (writable): no initialisation needed; making a local copy in calling function depends on usage; minput/output (modified): initialised; local copy depending on usage;

  26. Implementation of the above rules

  27. Example of variable life cycle: Original code SWI: surface layer soil water index DSWI: surface layer soil water tendency CALL PHYS(...,SWI,...,DSWI,...) WSWI = SWI ! WSWI: local variable DSWI = 0 CALL ISBAH4(...,SWI [PSWI],...,DSWI [PDSWI],...) PSWI = MIN(PSWI, 0.5) ZWS = PSWI*RD1*GCONV ! unit conv PSWI; ZWS: local variable ZDWS = 0 ! local variable CALL SURTEND_LAND(...,ZWS [PWS],...,ZDWS [PDWS],...) ZSWP = PWS + calculated change ! local variable ZDSW = ZSWP - PWS ! local variable PDWS = ZDSW*ZRDT/ZCONS10 ! unit conversion of tendency END SURTEND_LAND PDSWI = ZDWS END ISBAH4 WSWI = WSWI + DTVDIF*DSWI DSWI = (WSWI - SWI)/ZDTIME END PHYS

  28. Improved code m/c SWI: surface layer soil water index w DTSWI: surface layer soil water tendency CALL PHYS(...,SWI,...,DTSWI,...) CALL ISBAH4(...,SWI,...,DSWI,...) SWI = MIN(SWI, 0.5) CALL SURTEND_LAND(...,SWI,...,DWSI,...) DSWI = calculated change ! in correct units END SURTEND_LAND END ISBAH4 DTSWI = DSWI/ZDTIME END PHYS

  29. Gain: • removal of 12 temporary fields: WSWI(NHOR,NTYP), DSWI(NHOR,NTYP),ZWS(NHOR), ZDWS(NHOR) • similarly for second soil water layer • simplified code

  30. Life cycle of variables • where are the variables initialised • where are the variables modified • what are the modifications • pathways of the variables

  31. Summary • 2D fields are clustered into 3-dimensional arrays to improve structure and enhance future flexibility • Documented naming conventions based on functionality rather than semantic meaning of the variable • Well structured I/O of climate fields is required (GETDAT) • Description of the life cycle of the time-dependent variables must be included in the documentation

More Related