Deposition problematic aspects when using the fp format

Description of the problem

The main problem is that the deposition is currently not working with the fp formated files as designed in WP4. Any tests with depositing species, both gase and particulate, show:

  • an absolute lack of dry deposition and
  • a partial lack of wet deposition.

In order to have a better understanding of the problem, a simple test case has been designed comprising a 12 hour emission in DEX33 tracked for 48 hours in forward mode (backward does not save the deposition fields) of SO4-aero species (particulate matter, SPECIES_012). Visual inspection of the deposition fields confirm the findings and the problems in generating correct or even existing depositing fields when FLEXPART is driven by the fp formatted files. A closer look at the code itself as helped identifying the problematic areas:

  1. A first issue is that in GRIB2FLEXPART, the landuses (xlanduse parameter) are dumped without the actual code to the reading and assigning routine and, therefore, setting them to 0. The routines readlanduse.f90 and assignland.f90 should be either read in previous to dumping or, depending on the solution selected, simply the xlanduse parameter should not be dumped into the fp files and read in and calculated during the FLEXPART run itself.
  2. calcpar*.f90 routines calculate some of the information required for dry and wet deposition. In particular, the deposition velocity is calculated (call to getvdep.f90). This requires to have in memory the assigned land uses, the information on all the dry deposition parameterisations and also, and very importantly, to have DRYDEP set to True. This variable is only set to True in readreleases.f90, which is not called in GRIB2FLEXPART and, therefore, having the deposition flags set always to False. That means: if we do not read the releases when generating the fpformat, the GRIB2FLEXPART code will consider that nothing related to dry or wet deposition needs to be calculated and, therefore, stored in the fp files. This in turn translates into that, at the time of doing the FLEXPART simulation, the variables related to deposition will be zero and thus, no dry deposition will occur. If readreleases (and readspecies, readdepo) would all be used in GRIB2FLEXPART to store all the deposition information the outcoming fp files would be tailored now NOT ONLY on whether they are forward or backwards BUT ALSO to the specifications of the EMISSION. This reduces the flexibility and we encourage to use the solution outlined below which is a bit more complex but ensures flexibility of the fp files (same files could be used for different types of emissions)

In summary:

  • the FP formated files generated with the current GRIB2FLEXPART will not provide realisitc total deposition fields for any depositing species.
  • the GRIB2FLEXPART will need to be modified to a) either acount for species information (which we do not recommend, since it would loose versatility) or b) to produce the needed fields and not the deposition velocities and the FLEXPART source code modified to calculate all the deposition-related parameters after the reading in of the fp files. A preliminary solution using the second approach is outlined in the following section.

Solution outline

The solution for FLEXPART version 9.X by which the fp files are independent on the SPECIES released is relatively simple. It requires the two following main steps:

1. Modifications in fpmetbinary_mod.F90 --> to skip loading variables that are unnecessary and/or related to the RELEASES and SPECIES

  • vdep(:,:,:,cm_index) should not be in there (also, mind that the third dimension in vdep is actually maxspec)
  • vdepn(:,:,:,cm_index,:)
  • xlanduse should not be read/dumped since it is defined previous to getfields

2. Modification in FLEXPART source code

  • timemamanger.f90 should include an if statement that, if the fpformat is used (already set in COMMAND) then after the call to getfpfields.f90 we should compute all the species depending routines that provide the input for the dry deposition, we may need a routine (we may call it depfromfp.F90) that loops over the grid and calls:
    • getvdep.f90 (and the depending routines, caldate, getrb, …)
    • getvdep_nests.f90
  • In calcpar, we should activate by default the calculation of z0 and relative humidity at surface or to add it into the getvdep* routines, as the code sninpet from calcpar_ecmwf.f90 shows:
212  ! 4) Calculation of dry deposition velocities
213  !********************************************
215  if (drydep) then
216  ! Sabine Eckhardt, Dec 06: use new index for z0 for water depending on
217  ! windspeed
218  z0(7)=0.016*ustar(ix,jy,1,n)*ustar(ix,jy,1,n)/ga
220  ! Calculate relative humidity at surface
221  !***************************************
222  rh=ew(td2(ix,jy,1,n))/ew(tt2(ix,jy,1,n))
224  call getvdep(n,ix,jy,ustar(ix,jy,1,n), &
225  tt2(ix,jy,1,n),ps(ix,jy,1,n),1./oli(ix,jy,1,n), &
226  ssr(ix,jy,1,n),rh,lsprec(ix,jy,1,n)+convprec(ix,jy,1,n), &
227  sd(ix,jy,1,n),vd)
229  do i=1,nspec
230  vdep(ix,jy,i,n)=vd(i)
231  end do
233  endif

This modification will of course affect as well the GRIB2FLEXPART code, which relies on the same routines.

One last remark is regaring implementation in FLEXPART version 10: a first inspection of the code suggests that the same modifications mentioned above would be well feasible in the new version. The main reason for this is that, other than timemanager.f90, most of the routines involved in these calculations are not parallelised. In addition, version 10 will have a largely modified wet deposition scheme, not only in terms of parameters from SPECIES that define it, but also how it is internally calculated, requiring additional fields (cloud liquid water content)

Last modified 3 years ago Last modified on Apr 6, 2016, 7:49:56 AM
hosted by ZAMG