| 2 | | |
| 3 | | ---- |
| 4 | | '''Latest news''' |
| 5 | | |
| 6 | | 13/10 |
| 7 | | * As a first step, lets aim to: |
| 8 | | 1. run tests at grass. '''''This is different than in the curren/old test suite, which is implemented to run in bluehive,''''' |
| 9 | | 1. scp chombos to clover. '''''We can solve this problem locally, with the BCC guys, instead of doing it though the CRC,''''' |
| 10 | | 1. do postprocessing at clover, |
| 11 | | 1. post results in the wiki. |
| 12 | | ---- |
| 85 | | |
| 86 | | === Showcase tests === |
| 87 | | |
| 88 | | ||= Test folder name =||= Brief description =||= Result type =||= Est. time to run =||= Test wiki page =|| |
| 89 | | ||06-2D_shocked_clump || Over-dense clump in pressure equilibrium is overrun by a planar shock || Multi-panel PNG image showing fluid variables (n, vx, vy, p, T, clump tracer) at end of simulation || 5 min. (single-proc, grass) || To-Do || |
| 90 | | |
| 91 | | {{{#!comment |
| 92 | | '''Introduction''': As with any collaborative effort, updates to a computational code must be validated to ensure no degradation of the code base. Mistakes can be minor (affecting only a problem module) to major (breaking AMR or parallel). If a coder does not carefully validate his or her update, uncaught mistakes can bring the productivity of the entire group to a halt until the mistakes are tracked down and fixed. |
| 93 | | |
| 94 | | Therefore, a test suite is to be run whenever checking in updates to the code. The test suite should validate that all components of the code are working as expected. Unless and until all components are validated as working properly, the coder should not attempt to update the code. |
| 95 | | |
| 96 | | What follows is the list of tests run in the test suite. |
| 97 | | |
| 98 | | || '''Test Name''' || '''Designed to test''' || '''Analytic solution?''' || |
| 99 | | || 1D Sod shock tube || Integration methods || Yes || |
| 100 | | || 2.5D Sedov problem || || Yes || |
| 101 | | || 1D oscillatory instability of radiative shocks || Source term methods || || |
| 102 | | || 1D nonlinear heat conduction front || HYPRE diffusion || || |
| 103 | | || 2D improper nesting on n levels of AMR || AMR || || |
| 104 | | || 2D wind-step || Static and dynamic decomposition; static and dynamic grid adapt methods || || |
| 105 | | || 2D field-loop advection || Divergence checkers; showcase: robustness to field strength || || |
| 106 | | || 3D cloud collapse w/ sink particles || Restarts || || |
| 107 | | || 3D MHD jet || MUSCL/sweep; showcase || || |
| 108 | | || 2D cloud collapse w/ improper nesting || HYPRE stencils || || |
| 109 | | || 2.5D Central gravity w/ cylindrical coordinates || || || |
| 110 | | || 2D non-ablative RT || || || |
| 111 | | || 2D perturbations caused by small AMR grids || || || |
| 112 | | || 3D MHD turbulence || || || |
| 113 | | || 2D Kelvin-Helmholtz || (showcase) || || |
| 114 | | || 2D shocked clump || (showcase) || || |
| 115 | | || 3D clumpy jet || (showcase) || || |
| 116 | | |
| 117 | | }}} |
| 118 | | |
| 119 | | Still to be tested: |
| 120 | | * Robustness of build on multiple architectures (MPICH2, OpenMPI, VAMPICH, !BlueGene; Intel, GFortran) |
| 121 | | |
| 122 | | [[BR]] |
| 123 | | |
