next up previous contents index
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.



Gildas manager 2018-08-18