XY_MAP MEMORY

        MAP\XY_MAP: memory and efficiency

    All  the  considerations  below about memory consumption and file access
    efficiency are described in details in the document "class-gridding.pdf"
    in the CLASS documentation.

    XY_MAP  relies  on the Sic logical VOLATILE_MEMORY as an upper limit for
    its temporary memory comsuption. The current  value  of  VOLATILE_MEMORY
    can be checked and modified as follows:
      LAS> sic log volatile_memory        ! Current value
      volatile_memory = 90%
      LAS> sic log volatile_memory 50%    ! % of total RAM
      LAS> sic log volatile_memory 512MB  ! Explicit size
      LAS> sic log volatile_memory 4GB    !
    90% is a correct value if you are not sharing the resources with several
    people, or if you are not running other memory consuming software at the
    same time.

    If the problem (input table and output cube) fits in memory, the context
    is ideal: XY_MAP will process all the channels in a single run. This  is
    the most efficient from a file access point of view. This means that you
    should set VOLATILE_MEMORY as large as possible.

    If the problem does not fit in memory, the good point is that XY_MAP  is
    still  able  to  process  the data. However, this implies processing the
    channels by slices (intermediate smaller velocity ranges).

    When slicing is enabled, the default ordering of the table is not ideal,
    and  each  slice  implies traversing the whole input table (knowing that
    disk accesses are usually slow). If you want to avoid this,  it  may  be
    worth producing in advance a transposed ".bat" table with the command:
      LAS> TRANSPOSE mytable.tab mytable.bat 21
    This transposition takes also time, but the overall time will be smaller
    than letting XY_MAP dealing with a ".tab" table. On the other hand, this
    duplicates the table data on disk, and the .bat table must be regenerat-
    ed each time .tab table is updated.

    Also when slicing is enabled, the default LMV order for the cube is ide-
    al.  Trying to produce directly a VLM cube (/TYPE VLM) is still possible
    to some point, but this enlarges the memory consumption (one  more  buf-
    fer)  and increases the number of slices and the processing time. Prefer
    LMV order if possible.