[FLASH-BUGS] more FLASH issues

[Sean Matt]

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?