XY_MAP MEMORY

###
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.