Yes, I should do something like that. I was thinking about resetting
parameters in the parameter base, too, but this might be an invitation for
disaster. Imagine everyone resetting parameters at will so that his/her
thorn can run ...

On the other hand, what it comes down to is that the parser introduces a
new type of global variable. Global variables are good or bad depending on
how they are used. And in this case they come with a nice and controlled
interface.  Ok, I vote in favour of allowing parameter resetting. 

While I am at it, I think I am going to add parameters nxyz and dxyz. Then
do "if (nxyz) nx = ny = nz = nxyz;" after paramParse().  It is really
minor but annoying to have to change three identical numbers for every
other new parameter file. 

Bernd

PS: I already have absolution from PW, but does anybody else care to comment?





On Tue, 24 Feb 1998, Project ELLIPTIC/Paul Walker wrote:

>   
>  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 
>  _______________________________________________________________________ 
>   
>  CoCoBoard Information: 
>    From: Paul Walker  <pwalker@aei-potsdam.mpg.de> 
>    URL : http://wugrav.wustl.edu/Util/projects/ELLIPTIC/00011/ 
>   

Created for the WUGRAV CoCoBoard Page Projects Page.

Created by The CoCoBoard.