| 40 | | The turbulent resolved-scale momentum flux ''u*v*'' is defined as the product of the deviations of the horizontal velocities from their respective horizontally averaged mean values. These mean values are stored in array {{{hom(..,1,1,sr)}}} and {{{hom(..,1,2,sr)}}} for the u- and v-component, respectively. Since due to the staggered grid, u and v are not defined at the same gridpoints, they have to be interpolated appropriately (here to the center of the gridbox). The result of the calculation is stored in array {{{sums_l}}}. The second index of this array is the identification number of the profile which must match the one given in the previous step 2. |
| | 40 | The turbulent resolved-scale momentum flux ''u*v*'' is defined as the product of the deviations of the horizontal velocities from their respective horizontally averaged mean values. These mean values are stored in array {{{hom(..,1,1,sr)}}} and {{{hom(..,1,2,sr)}}} for the u- and v-component, respectively. Since due to the staggered grid, u and v are not defined at the same gridpoints, they have to be interpolated appropriately (here to the center of the gridbox). The result of the calculation is stored in array {{{sums_l}}}. The second index of this array is the identification number of the profile which must match the one given in the previous step 2. \\\\ |
| | 41 | [#part_2 '''2. Output of user-defined timeseries'''] \\\\ |
| | 42 | This example shows the output of two time series for the absolut extremal values of the horizontal velocities u and v. If more than one user-defined quantity shall be output, the following steps have to be carried out in the same way for each of the quantities.\\\\ |
| | 43 | 1. For each time series quantity you have to give a label and a unit (subroutine [../int#user_init user_init]), which will be used for the netCDF file. They must not contain more than seven characters. The value of {{{dots_num}}} has to be increased by the number of new time series quantities. Its old value has to be stored in {{{dots_num_palm}}}. |
| | 44 | |
| | 45 | dots_label(dots_num+1) = 'abs_umx' |
| | 46 | dots_unit(dots_num+1) = 'm/s' |
| | 47 | dots_label(dots_num+2) = 'abs_vmx' |
| | 48 | dots_unit(dots_num+2) = 'm/s' |
| | 49 | |
| | 50 | dots_num_palm = dots_num |
| | 51 | dots_num = dots_num + 2 |
| | 52 | |
| | 53 | Only those parts in red have to be adjusted by the user. |
| | 54 | |
| | 55 | 2. These quantities are calculated and output in subroutine [../int#user_statistics user_statistics] for every statistic region {{{sr}}} defined by the user, but at least for the region "total domain": |
| | 56 | |
| | 57 | ts_value(dots_num_palm+1,sr) = ABS( u_max ) |
| | 58 | ts_value(dots_num_palm+2,sr) = ABS( v_max ) |
| | 59 | |
| | 60 | |
| | 61 | [part_3 '''3. Output of user-defined 2d cross sections or 3d volume data'''] \\\\ |
| | 62 | |
| | 63 | This example shows the output of the quantity "square of the u-component" ('''Note:''' this quantity could of course easily be calculated from the u-component by postprocessing the {{{PALM}}} output so that calculation within {{{PALM}}} is not necessarily required). If more than one user-defined quantity shall be output, the following steps have to be carried out in the same way for each of the quantities. |
| | 64 | |
| | 65 | 1. The quantity has to be given a unique string identifier, e.g.'' 'u2'.'' This identifier must be different from the identifiers used for the {{{PALM}}} standard output (see list in description of parameter [../../d3par#data_output data_output]). To switch on output of this quantity, the user has to assign the string identifier to the parameter [../../userpar#data_output_user data_output_user], eg.: |
| | 66 | {{{ |
| | 67 | data_output_user = 'u2', 'u2_xy_av' |
| | 68 | }}} |
| | 69 | The pure string'' 'u2' ''switches on the output of instantaneous 3d volume data. Output of cross section data and time averaged data is switched on by additionally appending the strings'' '_xy', '_xz', '_yz', ''and/or'' '_av' ''(for a detailed explanation see parameter [../../d3par#data_output data_output]).\\\\ |
| | 70 | 2. In order to store the quantities' grid point data within PALM, a 3d data array has to be declared in module [../int#user_module user]: |
| | 71 | {{{ |
| | 72 | REAL, DIMENSION(:,:,:), ALLOCATABLE :: u2, u2_av |
| | 73 | }}} |
| | 74 | The second array {{{u2_av}}} is needed in case that output of time averaged data is requested. It is used to store the sum of the data of the respective time levels over which the average has to be carried out. \\\\ |
| | 75 | 3. The data array has to be allocated in subroutine [../int#user_init user_init]: |
| | 76 | {{{ |
| | 77 | ALLOCATE( u2(nzb:nzt+1,nys-1:nyn+1,nxl-1:nxr+1) ) |
| | 78 | }}} |
| | 79 | In case that output of time averaged data is requested, the array containing the sum has possibly to be read from the restart file (local filename BININ) by executing the following code in [../int#user_init user_init]: |
| | 80 | |
| | 81 | IF ( initializing_actions == 'read_restart_data' ) THEN |
| | 82 | READ ( 13 ) field_char |
| | 83 | DO WHILE ( TRIM( field_char ) /= '*** end user ***' ) |
| | 84 | |
| | 85 | SELECT CASE ( TRIM( field_char ) ) |
| | 86 | |
| | 87 | CASE ( 'u2_av' ) |
| | 88 | ALLOCATE( u2_av(nzb:nzt+1,nys-1:nyn+1,nxl-1:nxr+1) ) |
| | 89 | READ ( 13 ) u2_av |
| | 90 | |
| | 91 | CASE DEFAULT |
| | 92 | PRINT*, '+++ user_init: unknown variable named "', & |
| | 93 | TRIM( field_char ), '" found in' |
| | 94 | PRINT*, ' data from prior run on PE ', myid |
| | 95 | CALL local_stop |
| | 96 | |
| | 97 | END SELECT |
| | 98 | ENDDO |
| | 99 | ENDIF |
| | 100 | |
| | 101 | |
| | 102 | 4. The quantity has to be given a unit (subroutine user_check_data_output): |
| | 103 | |
| | 104 | CASE ( 'u2' ) |
| | 105 | unit = 'm2/s2' |
| | 106 | |
| | 107 | Otherwise, PALM will abort. |
| | 108 | |
| | 109 | |
| | 110 | 5. The vertical grid on which the quantity is defined (given by the levels 'zu' or 'zw', on which the u- or w-component of the velocity are defined) has to be specified for the NetCDF output files in subroutine user_define_netcdf_grid: |
| | 111 | |
| | 112 | CASE ( 'u2', 'u2_xy', 'u2_xz', 'u2_yz' ) |
| | 113 | grid = 'zu' |
| | 114 | |
| | 115 | As the example shows, this grid has to be defined for the 3d volume data as well as for all of the three cross sections. |
| | 116 | |
| | 117 | |
| | 118 | 6. After each timestep, the quantity has to be calculated at all gridpoints and to be stored. This has to be done in subroutine user_actions at location 'after_integration': |
| | 119 | |
| | 120 | CASE ( 'after_integration' ) |
| | 121 | ! |
| | 122 | !-- Enter actions to be done after every time integration (before |
| | 123 | !-- data output) |
| | 124 | !-- Sample for user-defined output: |
| | 125 | DO i = nxl-1, nxr+1 |
| | 126 | DO j = nys-1, nyn+1 |
| | 127 | DO k = nzb, nzt+1 |
| | 128 | u2(k,j,i) = u(k,j,i)**2 |
| | 129 | ENDDO |
| | 130 | ENDDO |
| | 131 | ENDDO |
| | 132 | |
| | 133 | |
| | 134 | 7. In case that output of time-averaged data is requested, the sum- and average-operations as well as the allocation of the sum-array have to be carried out in subroutine user_3d_data_averaging: |
| | 135 | |
| | 136 | IF ( mode == 'allocate' ) THEN |
| | 137 | ... |
| | 138 | CASE ( 'u2' ) |
| | 139 | IF ( .NOT. ALLOCATED( u2_av ) ) THEN |
| | 140 | ALLOCATE( u2_av(nzb:nzt+1,nys-1:nyn+1,nxl-1:nxr+1) ) |
| | 141 | ENDIF |
| | 142 | u2_av = 0.0 |
| | 143 | ... |
| | 144 | ELSEIF ( mode == 'sum' ) THEN |
| | 145 | ... |
| | 146 | CASE ( 'u2' ) |
| | 147 | DO i = nxl-1, nxr+1 |
| | 148 | DO j = nys-1, nyn+1 |
| | 149 | DO k = nzb, nzt+1 |
| | 150 | u2_av(k,j,i) = u2_av(k,j,i) + u2(k,j,i) |
| | 151 | ENDDO |
| | 152 | ENDDO |
| | 153 | ENDDO |
| | 154 | ... |
| | 155 | ELSEIF ( mode == 'average' ) THEN |
| | 156 | ... |
| | 157 | CASE ( 'u2' ) |
| | 158 | DO i = nxl-1, nxr+1 |
| | 159 | DO j = nys-1, nyn+1 |
| | 160 | DO k = nzb, nzt+1 |
| | 161 | u2_av(k,j,i) = u2_av(k,j,i) / REAL( average_count_3d ) |
| | 162 | ENDDO |
| | 163 | ENDDO |
| | 164 | ENDDO |
| | 165 | |
| | 166 | |
| | 167 | 8. For output of 2d cross sections, the gridpoint data of the quantity has to be resorted to array local_pf in subroutine user_data_output_2d. Also the vertical grid, on which the quantity is defined, has to be set again: |
| | 168 | |
| | 169 | CASE ( 'u2_xy', 'u2_xz', 'u2_yz' ) |
| | 170 | IF ( av == 0 ) THEN |
| | 171 | DO i = nxl-1, nxr+1 |
| | 172 | DO j = nys-1, nyn+1 |
| | 173 | DO k = nzb, nzt+1 |
| | 174 | local_pf(i,j,k) = u2(k,j,i) |
| | 175 | ENDDO |
| | 176 | ENDDO |
| | 177 | ENDDO |
| | 178 | ELSE |
| | 179 | DO i = nxl-1, nxr+1 |
| | 180 | DO j = nys-1, nyn+1 |
| | 181 | DO k = nzb, nzt+1 |
| | 182 | local_pf(i,j,k) = u2_av(k,j,i) |
| | 183 | ENDDO |
| | 184 | ENDDO |
| | 185 | ENDDO |
| | 186 | ENDIF |
| | 187 | |
| | 188 | grid = 'zu' |
| | 189 | |
| | 190 | The ELSE case is only needed in case that output of time-averaged data is requested. |
| | 191 | |
| | 192 | As a special case, xy cross section output can also be defined at one single level at height k=nzb+1 on the u-grid. This features is useful for output of surface data (e.g. heat fluxes). In this case, the corresponding 2d data has to be resorted to the array local_pf(i,j,nzb+1). In addition to this, the grid in user_define_netcdf_grid as well as in user_data_output_2d must be set to grid = 'zu1'. |
| | 193 | |
| | 194 | CASE ( 'u2_xy' ) |
| | 195 | IF ( av == 0 ) THEN |
| | 196 | DO i = nxl-1, nxr+1 |
| | 197 | DO j = nys-1, nyn+1 |
| | 198 | local_pf(i,j,nzb+1) = u2(j,i) |
| | 199 | ENDDO |
| | 200 | ENDDO |
| | 201 | ELSE |
| | 202 | DO i = nxl-1, nxr+1 |
| | 203 | DO j = nys-1, nyn+1 |
| | 204 | local_pf(i,j,nzb+1) = u2_av(j,i) |
| | 205 | ENDDO |
| | 206 | ENDDO |
| | 207 | ENDIF |
| | 208 | |
| | 209 | grid = 'zu1' |
| | 210 | two_d = .TRUE. |
| | 211 | |
| | 212 | Note that two_d = .TRUE. is necessary for output of a 2d data slice. |
| | 213 | |
| | 214 | |
| | 215 | 9. For output of 3d volume data, the gridpoint data of the quantity has to be resorted to array local_pf in subroutine user_data_output_3d.: |
| | 216 | |
| | 217 | CASE ( 'u2' ) |
| | 218 | IF ( av == 0 ) THEN |
| | 219 | DO i = nxl-1, nxr+1 |
| | 220 | DO j = nys-1, nyn+1 |
| | 221 | DO k = nzb, nz_do |
| | 222 | local_pf(i,j,k) = u2(k,j,i) |
| | 223 | ENDDO |
| | 224 | ENDDO |
| | 225 | ENDDO |
| | 226 | ELSE |
| | 227 | DO i = nxl-1, nxr+1 |
| | 228 | DO j = nys-1, nyn+1 |
| | 229 | DO k = nzb, nz_do |
| | 230 | local_pf(i,j,k) = u2_av(k,j,i) |
| | 231 | ENDDO |
| | 232 | ENDDO |
| | 233 | ENDDO |
| | 234 | ENDIF |
| | 235 | |
| | 236 | The ELSE case is only needed in case that output of time-averaged data is requested. |
| | 237 | |
| | 238 | |
| | 239 | 10. In case of job chains, the sum array has to be written to the (binary) restart file (local filename BINOUT) in subroutine user_last_actions: |
| | 240 | |
| | 241 | IF ( ALLOCATED( u2_av ) ) THEN |
| | 242 | WRITE ( 14 ) 'u2_av '; WRITE ( 14 ) u2_av |
| | 243 | ENDIF |
| | 244 | |
| | 245 | Otherwise, the calculated time-average may be wrong. In the restart run, this quantity has to be read from the restart file by including the following code in subroutine user_read_restart_data: |
| | 246 | |
| | 247 | IF ( initializing_actions == 'read_restart_data' ) THEN |
| | 248 | READ ( 13 ) field_char |
| | 249 | DO WHILE ( TRIM( field_char ) /= '*** end user ***' ) |
| | 250 | |
| | 251 | SELECT CASE ( TRIM( field_char ) ) |
| | 252 | |
| | 253 | CASE ( 'u2_av' ) |
| | 254 | IF ( .NOT. ALLOCATED( u2_av ) ) THEN |
| | 255 | ALLOCATE( u2_av(nzb:nzt+1,nys-1:nyn+1,nxl-1:nxr+1) ) |
| | 256 | ENDIF |
| | 257 | READ ( 13 ) tmp_3d |
| | 258 | u2_av(:,nysc-1:nync+1,nxlc-1:nxrc+1) = & |
| | 259 | tmp_3d(:,nysf-1:nynf+1,nxlf-1:nxrf+1) |
| | 260 | |
| | 261 | CASE DEFAULT |
| | 262 | PRINT*, '+++ user_init: unknown variable named "', & |
| | 263 | TRIM( field_char ), '" found in' |
| | 264 | PRINT*, ' data from prior run on PE ', myid |
| | 265 | CALL local_stop |
| | 266 | |
| | 267 | END SELECT |
| | 268 | |
| | 269 | READ ( 13 ) field_char |
| | 270 | |
| | 271 | ENDDO |
| | 272 | ENDIF |
| | 273 | |
| | 274 | [#part_4 '''4. Output of user-defined DVRP objects'''] \\\\ |
| | 275 | This example shows the output of the quantity "square of the u-component", u2. If more than one user-defined quantity shall be output, the following steps have to be carried out in the same way for each of the quantities. First, steps 1 - 6 of part 3. (2d cross section or 3d volume data) are required. Second, the gridpoint data of the quantity has to be resorted to array local_pf in subroutine user_data_output_dvrp as follows: |
| | 276 | |
| | 277 | CASE ( 'u2', 'u2_xy', 'u2_xz', 'u2_yz' ) |
| | 278 | DO i = nxl, nxr+1 |
| | 279 | DO j = nys, nyn+1 |
| | 280 | DO k = nzb, nz_do3d |
| | 281 | local_pf(i,j,k) = u2(k,j,i) |
| | 282 | ENDDO |
| | 283 | ENDDO |
| | 284 | ENDDO |
| | 285 | |
| | 286 | Only those parts in red have to be adjusted by the user. |
| | 287 | |
| | 288 | After performing these steps, the user-defined quantity 'u2' can be selected like standard model quantities by the dvrp_graphics package parameter mode_dvrp. |
| | 289 | |
| | 290 | [part_5 '''5. Output of user-defined spectra'''] \\\\ |
| | 291 | This example shows the output of the quantity "turbulent resolved-scale horizontal momentum flux" (u*v*). If more than one user-defined quantity shall be output, the following steps have to be carried out in the same way for each of the quantities. |
| | 292 | |
| | 293 | 1. The calculation of user-defined spectra is closely linked with the calculation of part 1. (user-defined vertical profiles) and part 3. (user-defined 3d volume data). Therefore, the following prerequisites apply for each user-defined spectra quantity: |
| | 294 | |
| | 295 | 1. From part 1. (user-defined vertical profiles) steps 2 and 3. |
| | 296 | See the sample code (as comment lines) for 'u*v*' and ustvst, respectively. (Actual output of vertical profiles - step 1 - is not required.) |
| | 297 | 2. From part 3. (user-defined 3d volume data) steps 2, 3, 4, 5, and 6. |
| | 298 | See the sample code (as comment lines) for 'u*v*' and ustvst, respectively. (Actual output of 3d volume data - step 1 - is not required.) |
| | 299 | 3. The quantity has to be given a unique string identifier, e.g. 'u*v*'. This identifier must be different from the identifiers used for the PALM standard output (see list in description of package parameter data_output_sp). To switch on output of this quantity, the user has to assign the string identifier to the package parameter data_output_sp, eg.: |
| | 300 | |
| | 301 | data_output_sp = 'u*v*' |
| | 302 | |
| | 303 | A. and B. as prerequisites for C. require a naming convention of identical identifiers, e.g. data_output_pr_user = 'u*v*', data_output_user = 'u*v*' and data_output_sp = 'u*v*'. This naming convention applies only in case of user-defined spectra. |
| | 304 | |
| | 305 | 2. Edit the subroutine user_spectra (only those parts in red) as follows: |
| | 306 | |
| | 307 | IF ( mode == 'preprocess' ) THEN |
| | 308 | |
| | 309 | SELECT CASE ( TRIM( data_output_sp(m) ) ) |
| | 310 | |
| | 311 | CASE ( 'u', 'v', 'w', 'pt', 'q' ) |
| | 312 | !-- Not allowed here since these are the standard quantities used in |
| | 313 | !-- preprocess_spectra. |
| | 314 | |
| | 315 | CASE ( 'u*v*' ) |
| | 316 | pr = pr_palm+1 |
| | 317 | d(nzb+1:nzt,nys:nyn,nxl:nxr) = ustvst(nzb+1:nzt,nys:nyn,nxl:nxr) |
| | 318 | |
| | 319 | CASE DEFAULT |
| | 320 | PRINT*, '+++ user_spectra/preprocess: Spectra of ', & |
| | 321 | TRIM( data_output_sp(m) ), ' can not be calculated' |
| | 322 | |
| | 323 | END SELECT |
| | 324 | |
| | 325 | ELSEIF ( mode == 'data_output' ) THEN |
| | 326 | |
| | 327 | SELECT CASE ( TRIM( data_output_sp(m) ) ) |
| | 328 | |
| | 329 | CASE ( 'u', 'v', 'w', 'pt', 'q' ) |
| | 330 | !-- Not allowed here since these are the standard quantities used in |
| | 331 | !-- data_output_spectra. |
| | 332 | |
| | 333 | CASE ( 'u*v*' ) |
| | 334 | pr = 6 |
| | 335 | |
| | 336 | CASE DEFAULT |
| | 337 | PRINT*, '+++ user_spectra/data_output: Spectra of ', & |
| | 338 | TRIM( data_output_sp(m) ), ' are not defined' |
| | 339 | |
| | 340 | END SELECT |
| | 341 | |
| | 342 | ENDIF |
| | 343 | |
| | 344 | Note that spectra output is an optional software package (see chapter 3.7). Therefore user-defined spectra also require the package activation via mrun -p spectra. |
