Opened 11 years ago

Last modified 4 years ago

#25 accepted Enhancement

Dynamic memory allocation

Reported by: pesei Owned by: anphi
Priority: major Milestone: FLEXPART 10
Component: FP coding/compilation Version: none
Keywords: Cc:


(from minutes of FpDev Workshop 2012)

Introduce dynamic memory allocation at least for all variables related to meteorological input data

Change History (8)

comment:1 Changed 11 years ago by saeck

  • Status changed from new to accepted

comment:2 Changed 10 years ago by pesei

  • Milestone FLEXPART 9.2 deleted

comment:3 Changed 10 years ago by anphi

  • Owner changed from saeck to anphi
  • Status changed from accepted to assigned

comment:4 Changed 10 years ago by anphi

  • Status changed from assigned to accepted

comment:5 Changed 9 years ago by pesei

Dynamic allocation for particle number-related arrays

It would be nice to have that as well. However, we don't know the number of particles required in advance - only a maximum number can be determined from RELEASE, and it may be not necessary and not desired to use this maximum. On the other hand, allocating it only in releaseparticles.f90 can lead to non-contiguous memory usage.

comment:6 Changed 9 years ago by pesei

  • Milestone set to FLEXPART 10

I suggest this for v10. Don & Delia, is this maybe a by-product of your CTBTO work?

comment:7 Changed 9 years ago by dearn

We will take into consideration this suggestion. The dynamic allocation shall be implemented within the CTBTO work but this largely depends on how and when the tasks are assigned. This ticket will be updated whenever needed.

comment:8 Changed 4 years ago by pesei

In v10, dynamic allocation has been introduced for many fields.

However, the following fields are still statically allocated, and thus there dimensions may need to be adjusted in par_mod.f90:

  • meteorological fields
  • lage
  • variables related to receptor output (depend on maxreceptor)
  • variables related to the particle number (maxpart) except xscav_frac1
  • auxgrid (depends on nclassunc)
  • various arrays depending on maxspec
  • various arrays depending on maxwf or maxnests
  • various arrays depending on numwfmem, including meteo fields (mother grid)
  • arrays related to the domain-filling option depending on maxcolumn
  • rannumb(maxrand)
  • arrays depending on ncluster

The following parameters have to be set in par_mod.f90 while at least some associated arrays are dynamically allocated with these values:

  • maxageclass (output-related arrays dynamically allocated)
  • maxreceptor (creceptor0 is dynamically allocated, but other variables not)
  • maxpart (only xscav_frac1 dynamically allocated)
  • maxspec (only output-related arrays and those describing the species are dynamically allocated)
  • numwfm (only nested meteorological fields)

The following parameters are set in par_mod.f90 but appear not to be used at all:

  • integer,parameter :: maxxOH=72, maxyOH=46, maxzOH=7

Don Morton reported in a developer meeting that they found a significant negative impact on the runtime if the meteorological fields were dynamically allocated. This should be re-checked, especially in the light of the fact that nested meteo fields are currently dynamically allocated.

In any case, there are inconsistencies in the handling of arrays and more can be done, even though it is not necessary to allocate arrays dynamically whose dimension will rarely change.

In principle, most people will compile FLEXPART themselves, thus setting parameters for array dimension should not be too much of a problem. Note, however, that there is a Debian package (and then derived from it also Ubuntu) of FLEXPART which provides a precompiled binary.

Note: See TracTickets for help on using tickets.
hosted by ZAMG