[If you want to be on the project pages mailing list, email Malcolm.]



On Tue, 9 Jun 1998, Project ELLIPTIC/Ed Seidel wrote:

>  [just in case everyone forgot to read and/or reply to this important 
>  message, I am sending it again...] 
>   
>   
>   
>  Dear All, 
>   
>          There has been a lot of independent activity on elliptic solvers 
>  lately.  They are still one of our major bottlenecks (sometimes 95% of run 
>  time!), and they are increasingly needed:  maximal slicing is still one of 
>  the most successful slicings,  and new work in Palma with eigenmethods 
>  relies on it, too;  an entire family of shift conditions involves coupled 
>  ellitpptics; and recently Kip Thorne has been visiting us in Potsdam and 
>  has some proposal for gauge conditions that involves 3 or 4 coupled 
>  elliptics that we want to try out. 
>   
>          I just had a long talk with Dan Bullok and Paul Saylor at Illinois 
>  on Friday.  Dan plans to take a look at our elliptic problems over the 
>  summer, and would like to get started soon.  He has developed his own 
>  "patch" multigrid solver that can interface to Cactus through Petsc.  I 
>  brought him up to date on Bernd's BAM multigrid solver, and he would like 
>  to take a look at it to see if he might have some ideas about optimizing 
>  it.  Bernd, could you help point Dan to the minimal setup he would need to 
>  check it out, with say, maximal slicing in Cactus? 
>   
>          Gerd and Mark, could assist Dan if he needs some help with Cactus? 
>   
>          At the same time, Paul wrote a Matvec operator that would hook 
>  directly to our matrix setup for elliptics.  Faisal and Paul have discussed 
>  using this as the core of an iterative package we could put together, like 
>  CMstab was in the old G code.  Dan might be able to easily write some 
>  simple CG based iterative solvers around that that we could experiement 
>  with.   Paul, could you point Dan and the rest of us to that? 
>   
>          Dan's own multigrid solver might be used through Petsc, or perhaps 
>  directly through our elliptic solver interfaces in Cactus.  Paul, Mark, 
>  Bernd, it would be helpful if you could lend a hand to Dan to see what 
>  would be required to connect it directly as a thorn. 
>   
>          Finally, having all this together would allow us to experiment with 
>  different ways of solving elliptics, possibly ussing MG as a preconditioner 
>  for iterative solvers, with Petsc or our own home grown solvers.  I suspect 
>  they all would have some use, some strngths, and weaknesses. 
>   
>          Let us try to organize this and march forward. 
>   
>          Thanks, 
>          Ed 
>   


Hi everyone,

I also believe that elliptic solvers are an important problem, and it
becomes even more important for initial data and slicing conditions as
our various project move along. We should make a better effort to stay in
touch and collaborate! So here is a post to the project pages, YOU should
post, too ;) 

My focus is thorn_BAM_Elliptic.
Recent developments:
- Octants with stencil width 2.
- Performance testing on T3E with Tom Clune: there is a certain bottleneck 
  for fixed problem size on varying numbers of processors, but for the
  case we are most interested in because of memory requirements for big
  simulations, i.e. fixed problem size per processor, BAM_Elliptic does
  surprisingly well. Parallelization by itself is not the next problem to
  address. 
- Vector laplacian implemented, some simple tests done for minimal strain
  and minimal distortion shift conditions.
- BH puncture data including momenta and spins.
- Gerd and I got BAM_Elliptic to work with Gerd's BoxInBox mesh
  refinement for Brill wave initial data.

Currently under development/projects on my list:
- Mark implemented solving the 4 coupled equations for the initial
  value problem (neat!). BAM_Elliptic fails for certain cases, I'll look
  into it. Partially related to that, I intend to implement a 4-vector
  native BAM_Elliptic mode. 
- Implement and investigate Thorne's minimal strain/algebraic lapse
  equation which is a special case (might degenerate away from elliptic).
- Experiment with preconditioning, say BAM_Elliptic preconditions for
  Petsc.
- Use special solver on coarsest grid of multigrid stack, say Petsc or 
  something based on Paul's matvec routines.
- Work with Friedbert on BAM_Elliptic an Petsc performance.


Most pressing issue: 
- Get reasonable performance for maximal slicing runs. (We are also
  working on algebraic slicings!) 
  In the original BAM evolutions, maximal slicing accounted for only about
  60% of the run time, with cactus we seem to be back to 95% to 99%.
  Ryoji and I are taking a close look at how these runs are done.
  It already turned out that certain runs were at least a factor of three
  too slow because the tolerance for the maximal slicing solve was
  unnecessarily low. 


One of the action items of Ed's mail was to establish contact between AEI
and Dan. 

Yo, Dan! 

I would be very happy to give any help necessary to get you going on
elliptic projects with cactus, just email me.  For starters, checkout
cactus, checkout thorn_BAM_Elliptic, email me :)  There is a parameter
file bam_perf.par that I made for the tests with Tom Clune. Let me
know what you are actually interested in!

Best wishes,
Bernd 

Created for the WUGRAV CoCoBoard Page Projects Page.

Created by The CoCoBoard.