From: Paul Walker <pwalker@aei-potsdam.mpg.de>
Date: Tue, 24 Feb 1998 10:09:18 +0100 (MET)
To: Project ELLIPTIC/Bernd Bruegmann <proj_ELLIPTIC@wugrav.wustl.edu>
Subject: Re: Robin BC at Cactus thorn_BAM_Elliptic
Reply: to this message


Hey.

Just a thought:

>  Cactus combined with multigrid is quite user unfriendly when it comes to 
>  ghost zones for various boundaries.  

With the new parameter parser, this could be fixed quite easily. In main.c
put, right after "parseparam" an

#ifdef THORN_BAM_ELLIPTIC
	BAM_FixupGridSizes();
#endif

This could then do the tests you have below, and actually RESET the users
value of nx,ny,nz (while printing an enormous damn warning) to the
nearest value of the correct grid size. A heuristic would be don't ever
increase grid size by more than, say, 6 points in a direction, and
otherwise decrease. The routine could look like

	if (Contains("bound","BAMRobin") && Contains("grid","octant")) {
	  nx = Geti("nx");
          if (nx - 3 != small_number*2^n) {
	    nx_shouldbe = some_closeish_small_number*2^n + 3;
            print ("WARNING: BAM re-setting nx from %d to %d for BAM
Robin\n",
	        nx, nx_shouldbe);
            setIntVal("nx",nx_shouldbe);
          }
	}

Then all requests of geti("nx") thereafter (which are used to set up the
GH and so on) will get the shouldbe value. There is some pretty annoying
code swept under the rug here, but you get the idea.

This is possible now since we have one parser on all platforms, and a
fairly easy way to noodle the param database at runtime. This would make
it so users don't have to think about things, which in my experience is
the best approach. In fact, if users just put in a 2^n number you could
fix it up automatically, and otherwise stop, or any of a wide number of
varients on that theme.

Hope this helps!

	- Paul


Re: Robin BC at Cactus thorn_BAM_Elliptic / Paul Walker

Created for the WUGRAV CoCoBoard Page Projects Page.
Created by The CoCoBoard.