On Mon, 23 Feb 1998, Project ELLIPTIC/Hisaaki Shinkai wrote:

>   
>  Hi all, 
>   
>  Today's Bernd's update of his CACTUS thorn_BAM_Elliptic 
>  enables to treat Robin boundary condition  u=1+c/r in solving elliptic 
>  equations. I tried this with solving Poisson equation for LaneEmden 
>  stars, and find this option works almost properly. I only checked at 33*3 
>  at Indy. The solution seems to be similar with exact solution, but 
>  not fit as well as the fixing boudary with u=1+c/r. This might be 
>  from the resolution, but overshooting even at single star case, and 
>  more overshoot for binary. 

For spherical symmetry, the difference should converge away with
resolution. Fixing u=1+c/r imposes one constant c everywhere, while
c is not constant for Robin with u'=(1-u)/r.

>   
>  By the way, 
>  in the recent review by Oohara-Nakamura-Shibata [1], they describe 
>  how to fix boundaries to solve elliptic equations in their simulation 
>  in detail (appendix B and C in [1]).  They fix outer boundary for 
>  Poisson equations not at the order (1/r) but at (1/r^2) in order to 
>  solve the equation for time-derivative of potential in the same way 
>  with original Poisson. They say such a technique is crucial for 
>  solving conformal factor in evolution. 
>  They also solve momentum constraint at the order (1/r^3) in order 
>  to treat the interface of the solver same way regardress of the 
>  existence of the linear momentum. 

>   
>  I am not sure this is essential, but for our future, 
>  I request the followings: 
>   
>    Robin BC.. not only for 1+c/r, but also c0+c1/r, if possible. 
>   
>    Robin BC.. not only for c0+c1/r, but also c0+c2/r**2 and 
>               c0+c3/r**3, if possible. 

No problem, I'll add this soon.


>    bug? .... BAM_Elliptic with 
>              bound="flat bamrobin" 
>              grid ="BAM full" 
>              runs at 33^3 but complains and stops at 65^3 at Origin2000. 

Cactus combined with multigrid is quite user unfriendly when it comes to
ghost zones for various boundaries. Have a look at
************************
thorn_BAM_Elliptic/doc/gridsize.doc.
************************

The error message should tell you what you need:
- 2^n processors
- size should be something like (small number)*2^n plus "boundary points"
  +1 for full, Dirichlet
  +3 for full, Robin
  +2 for octant, Dirichlet
  +3 for octant, Robin
Both octant and Robin are implemented as von-Neumann conditions with 1
extra ghost.

So, if the number of processors is right, it should run for 67^3. 


 
>  [1] K. Oohara, T. Nakamura and M. Shibata 
>  "A way to 3D Numerical Relativity", in 
>  Progress of theoretical physics Supplement 128 (1997 Dec, p183), 
>  "Perturbative and Numerical approaches to Gravitational Waves" 
>  ed. by T. Nakamura. 

Too bad, we don't have this issue in our library yet, or did somebody take
it to his office?


Bernd

Created for the WUGRAV CoCoBoard Page Projects Page.

Created by The CoCoBoard.