HIRLAM physics cleanup week 26-30 september 2005 ================================================ Call Tree PHCALL -> PHTASK -> PHYS ---------------------------------- Questions pertaining to routine PHCALL: 1. Do we need "multiple dynamics time steps per physics time step" ? NO. 2. Do we need "multiple diffusion time steps per physics time step" ? NO. Can be recoded if needed. 3. Do we need a loop over tasks (note that most operational implementations nowadays use MPI's domain decomposition, such that the "physics" code already is run on a subdomain) ? There are physical steps inside PHTASK that should be moved elsewhere. Should also ask Kalle Eerola and Jose Antonio Garcia. This needs more study, because of the size of the work arrays. If PHTASK goes, PHCALL could go also. 4. Can we eliminate the phcoef array ? 3 are used in RADIA, 1 in HOLTSLAG. Recompute inside those routines. 5. Can we eliminate the phstat array ? Is this output anywhere ? If not, it can go. [stphys]. Is controlled by setting NSTPHI in NAMRUN to a value. For each time step a multiple of NSTPHI some ASCII output is written. Still needed for diagnostic value. Cleanups pertaining to routine PHCALL: 1. Eliminate variables lsamedt, lnewpht, nsphys, conacp. Also eliminates a small amount of logic in routine PHCALL and routine PHTASK. YES. 2. Eliminates variable nsvdif. Also eliminates a small amount of logic in routine PHCALL, routine PHTASK and routine PHYS. YES. 3. Eliminates variables lserial, ntask, ktask, arrays kstart and kstop and the routine PHTASK. NO. And ... we should keep lserial for debugging purposes (everything in the area in one array) anyway. 4. Eliminates the array phcoef (actual argument coming in) and a small amount of processing. YES (if processing moved to RADIA/HOLTSLAG). 5. Eliminates the array phstat (actual argument coming in) and a small amount of processing. NO. Questions pertaining to routine PHTASK (if it remains): 1. Do we need "multiple dynamics time steps per physics time step" ? NO. 2. Do we need "multiple diffusion time steps per physics time step" ? NO. 3. Do we need a loop over tasks (note that most operational implementations nowadays use MPI's domain decomposition, such that the "physics" code already is run on a subdomain) ? YES, KEEP. 4. Can we eliminate the phcoef array ? YES (see above). 5. Can we eliminate the phstat array ? NO. 6. Move accumulation to separate subroutine ? Accumulate accumulations. OK. Cleanups pertaining to routine PHTASK (if it remains): 1. Eliminates variables lsamedt, lnewpht and all related processing. YES. 2. Eliminates passing variable nsvdif to routine PHYS. YES. 3. Eliminates this routine. NO. 4. Eliminates passing this array to routine PHYS. YES (if processing is moved to RADIA/HOLTSLAG). 5. Eliminates passing this array to routine PHYS. NO. 6. Create new subroutine to do accumulations. Call it in PHCALL or PHTASK. YES. Questions pertaining to routine PHYS: 1. Does routine INIPHYS have to reside in the same source file ? YES. 2. Do we need "multiple dynamics time steps per physics time step" ? NO. 3. Do we need "multiple diffusion time steps per physics time step" ? NO. Cleanups pertaining to routine PHYS: 1. Place routine INIPHYS in its own file and eliminate it from the file with the source code of routine PHYS. OK. 2. Eliminate variables lsamedt, isame, lnewpht and associated processing. YES. 3. Eliminate variable nsvdif and associated processing. YES. Further cleanups. ----------------- Without restructuring the arrays of the model / surface state into structures, the argument lists of the routines will remain large. One way of bringing order in them is to structure them as follows: SUBROUTINE PHCALL ( & & NPROC, & & KSTEP, & ... & MAXTSK ) IMPLICIT NONE USE PARKIND1, ONLY : JPIM, JPRM INTEGER(KIND=JPIM), INTENT(IN) :: NPROC ! Comment describing NPROC INTEGER(KIND=JPIM), INTENT(IN) :: KSTEP ! Comment describing KSTEP .... INTEGER(KIND=JPIM), INTENT(IN) :: MAXTSK ! Comment describing MAXTSK This combines in one line the type, intent and explanation of each of the dummy arguments. One could also structure the argument list by splitting it up with comments stating what the role of the arguments following is, like housekeeping, diagnostics, prognostics, ... One argument per line might overrun the limit of continuation lines. --------------------- Structure code such that a 1D model can be easily extracted from the the Reference System, using #ifdef 1D ... #endif (Sander writes this up).