Re: [petsc-dev] examples/benchmarks for weak and strong scaling exercise
Jed, I tried cloning your tme-ice git repo as follows and it failed: % git clone --recursive git://github.com/jedbrown/tme-ice.git tme_ice Cloning into 'tme_ice'... fatal: unable to connect to github.com: github.com[0: 204.232.175.90]: errno=Connection timed out I'm doing this from an xterm that allows me to clone petsc just fine. Any idea what the problem might be? Dave ________________________________________ From: [email protected] [[email protected]] on behalf of Jed Brown [[email protected]] Sent: Wednesday, April 10, 2013 9:22 AM To: Chris Kees; [email protected] Subject: Re: [petsc-dev] examples/benchmarks for weak and strong scaling exercise Chris Kees <[email protected]> writes:
Hi guys,
Could somebody point me to some examples you guys routinely use for weak and strong scaling studies (maybe even with scripts, option files, or prior results on recent hardware)? I'm thinking of 3D Poisson with finite differences and geometric multigrid or something like that.
One option would be to use src/snes/examples/tutorials/ex48.c and use the configurations from http://dx.doi.org/10.1137/110834512 (http://59A2.org/files/hstat.pdf) which you can find in the paper repository: https://github.com/jedbrown/tme-ice Look in shaheen/b/. Those runs were using DMMG so the command line will have to be modified slightly, but it should be straightforward and you can compare to the runex48_* targets in src/snes/examples/tutorials/makefile.
We've been trying to work toward scaling studies of the field split and Schur complement preconditioners for our multiphase flow solvers, but I'm realizing that we need to do more thorough testing of the petsc installation itself and make sure we're using timing/profiling "best practices" and such.
We are using petsc-dev on the hardware below. I promise to quit using petsc-dev as soon as the next release comes out:)
We're actually happy to have people using petsc-dev. One motivation for our new workflow is that we can now provide a pretty stable 'master' so that we can interact with users on new features without the latency of a release cycle and without frequent breakage.
participants (1)
-
Nystrom, William D