1. 15 Jun, 2017 1 commit
  2. 11 Mar, 2016 1 commit
    • Christopher Subich's avatar
      Add caching for array-rebalance in multigrid · 3164ef96
      Christopher Subich authored
      The multigrid solver regularly "rebalances" arrays, by which
      it takes an input array and moves complete rows (i fixed, j
      variable) such that the same global arrays divides
      differently.  This is used on initial calling (to adjust the
      input problem specification), on coarsening, and finally to
      collapse "down" processors when near the coarsest level.
      
      However, this code was written naïvely: it built (and
      divided) the global array split at each invocation, using a
      number of MPI_Allgather calls on each processor.  Profiling
      (courtesy Kris Rowe) has found that this can be agonizingly
      slow; in at least one test case on one particular system it
      consumed over 50% of wallclock-time.
      
      This patch fixes the problem by allowing rebalance_array
      (now moved into the multigrid solver class) to cache these
      array divisions.  It requires the caller to specify one of a
      few categories, with the division being computed (with
      Allgathers) only on the first invocation per multigrid
      level and type.  The divisions currently are:
      
      FFine, UFine, FCoarse, and UCoarse
      
      where 'F' and 'U' refer to the error and solution terms
      respectively.  Confusingly, coefficients of the Laplacian
      itself (such as the uxx term) belong to the 'error' space in
      terms of call structure.
      
      This caching eliminates all but setup calls to Allgather.
      3164ef96
  3. 30 Jul, 2012 1 commit
    • Christopher Subich's avatar
      Initial commit · 58fbdb5d
      Christopher Subich authored
      This is the initial commit of SPINS to a git repository, coming from
      an essentially unmanaged environment.  While this is a *complete*
      archive, this is probably not the most useful form for development
      going forward.  Notably, the future management should be:
      
      1) Pare down the case files
      
      2) Establish branches for individual users.  Not as a long-term goal,
         but instead to keep user-specific case files from lingering in
         the main repository long after their use is obsolete.
      
      2b) Establish semipermanent branches for typical users.  A release
         branch should include the basic documentation cases, a benchmark
         case should include benchmarking cases, and there are probably
         others that aren't coming to mind now.
      
      3) Add helpful MATLAB processing scripts to the repository.  Too
         much of that is ad-hoc now, completely unmanaged.
      
      4) For papers/etc, establish tagged versions.
      58fbdb5d