[FLASH-BUGS] more FLASH issues

[Mike Zingale]

Sean, at present, I have no immediate plans to extend the block drawing or
1-d slicing to 3-d in fidlr.  The draw_blocks routine is not written for
3-d data, so what you see when you uncomment those lines is not
necessarily the block structure for that slice plane.  I am starting to
work on the next version of those routines, so it is possible that I will
add it to them, but I have no release date in mind with those.

The factor of two you note comes from the fact that the full dt is used
both for the xyz sweep and the zyx sweep, and the logfile is written at
the end of those two sweeps, one line for each cycle.

Mike


------------------------------------------------------------------------------
Michael Zingale
UCO/Lick Observatory
UCSC
Santa Cruz, CA 95064

phone:  (831) 459-5246 
fax:    (831) 459-5265
e-mail: zingale at ucolick.org
web:    http://www.ucolick.org/~zingale

On Mon, 27 Jan 2003, Sean Matt wrote:

> Hello again,
> 
> 	Since the release of FLASH2.2, we have noted a few relatively 
> minor issues.  I'm guessing that you are already aware of at least some of 
> them, but I'll list here the ones we've noticed.  Please let us know if we 
> can help in any way, or if you would like further information.
> 
> 		-Sean
> 
> 
> 1)  For 3D data (e.g., 3d briowu), the fidlr2 IDL routines (called by
> xflash) have a few problems:
> 
> 
>      a)	xflash doesn't show blocks properly for 3d data.  This would
> 	be useful, and we think it could be done using the existing tree
> 	informaion.  We've gotten a partial fix going:
> 
> 	In "xplot3d_amr_new.pro" (line 772) we've added:
> 
> 	    	if options.blocks then draw_blocks, color('ltblue'), $ 
> 			TREE = tree, PARAMETERS= params, $
> 			ORIENTATION = problem.orientation
> 
> 	instead of the originally commented out line (which crashes xflash
> 	if simply uncommented):
> 
> 		;    if options.blocks then draw_blocks, ltblue
> 
> 	our fix, at least, allows some blocks to be drawn on the 2d slice
> 	of 3d data in the xflash plot window.  But, it apparently draws 
> 	the maximum refinement level blocks, or something.  Whatever it is
> 	drawing is useful, but it doesn't change when a different 2d slice 
> 	is plotted or a slice in a different plane.
> 
> 	We assume that you are aware of this issue.  Is it being worked
> 	on?  Should we try to get it working ourselves?
> 
> 
> 
>      b) xflash also doesn't allow a "1-d slice" to be plotted. Again, his
> 	would be useful (as it is in 2d), and we think it could be done
> 	relatively easily.
> 
> 
> 
> 2)  The criterion for outputting plot files (and checkpoint files) works
> most of the time, but it can produce undesired (by us) effects in general.  
> 
> In source/io/output.F90 (around line 338), the output criterion is
> 
> 	if ((mod(time,tplot) < mod(time-2*dt,tplot)) .or. &
> 	    (redshift <= zpnext)) then
> 
> This doesn't work properly if the timestep (dt) is comparable to the
> output time interval (tplot).  In that case, plot file outputs can be
> skipped completely.  In our own source tree, we've replaced that criterion
> with
> 
> 	if ((time >= tplot*float(PTNumber)) .or. &
> 	    (redshift <= zpnext)) then
> 
> This way, even if dt >= tplot, a plot file will be written for each dt.  
> Assuming the dt later becomes less than tplot, the correct number of plot
> files will always be written.
> 
> A similar argument can be made for the checkpoint file output criterion 
> (near line 269).
> 
> 
> 
> 3)  In the logfile ("<problem>.log"), we noticed that, for each timestep,
> the total simulation time equals the time from the previous timestep plus
> TWO times the previous dt.  We are confused about this factor of TWO.
> 
> In the users guide (p. 48), it states that "the default time update method
> is to call each physics module's update routine for two equal
> timesteps..."  This (plus an inspection of
> /source/driver/time_dep/evolve.F90) explains the logfile output.  
> However, we don't understand the justification for this.  Why not compute
> the optimal dt for each timestep?  It seems that using the same dt twice
> each time could potentially result in numerical instabilities.  Are we 
> missing something?
>