- 26 Oct, 2017 1 commit
-
-
Christopher Subich authored
First and most trivially, this change adds a few more timing push/pop invocations relating to multigrid and especially to some of the MPI synchronization steps that might cause processors to wait on each other. More substantively, this change also adds a new tridiangonal solver based on the bog-standard forwards/backwards elimination Thompson algorithm (see Wikipedia). This should be acceptable because the 1D problems being solved themselves come from a 2D problem, so we don't expect ill-conditioning; calling out to the GMRES banded solver was surprisingly a computational bottleneck perhaps because of pivoting. This change seems to decrease the line-solve time by about 80%, which in turn decreases the overall runtime (tank_rho test case) by 40%.
-
- 29 Jun, 2017 2 commits
-
-
Christopher Subich authored
-
Christopher Subich authored
-
- 26 Jun, 2017 1 commit
-
-
Christopher Subich authored
This commit adds stack-structured timing code, such that bits of SPINS can be instrumented with > timing_push("short name") > [... work goes here] > timing_pop() This is recursive, such that already-timed portions of the code can call the timing code to further instrument subroutines or discrete code segments, and the resulting structure follows the -dynamic- call stack. This does have the odd result that portions of the code that are re-used (namely spectral derivatives) can show up as several 'leaf' nodes in the graph. To print out the report to standard error, call > timing_stack_report() The exact format of the report should be considered tentative.
-
- 15 Jun, 2017 1 commit
-
-
Christopher Subich authored
-
- 11 Mar, 2016 1 commit
-
-
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.
-
- 24 Aug, 2015 1 commit
-
-
Christopher Subich authored
-
- 04 Oct, 2012 1 commit
-
-
Christopher Subich authored
In a Valgrind check, several usages of uninitialized memory in the multigrid code were being caught. This was related to the check for boundary-condition indefiniteness/validity at the coarsest level. In effect these errors were harmless, but fixing them will make future Valgrind checks cleaner.
-
- 30 Jul, 2012 1 commit
-
-
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.
-