XY_MAP MEMORY
Keywords: class

Next: DSB2SSB Language Internal Help Up: XY_MAP Previous: XY_MAP TUNING Contents Index

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