[FLASH-BUGS] three bugs in FLASH V2.3

[Andreas Maier]

Hello all,

In course of my work with FLASH V2.3 and the Intel Fortran Compiler 8.0
on a Linux PC I believe I found three bugs in FLASH:

1. io/getPlotVars.F90
Everytime running FLASH I got the following error message during initialization:

"Error: variable 'x' not found."

with x=dens, pres... . I was able to fix this error by exchanging every call
"lowercase(trim(x))" to "trim(lowercase(x))"
in getPlotVars.F90. This is so, because for some strange reason, when
calling trim() inside of lowercase()  the result of this operation is not a valid string
(Maybe a compiler specific bug).

2. driver/time_dep/flash.F90
There is a bug described in io/Output.F90:

BUGS: Sometimes, a plotfile is skipped when using tplot to specify the interval between
sucessive plotfiles. It is unclear why this happens.

This Bug does not come from an error in Output.F90, but from the wrong call of output
in driver/time_dep/flash.F90. The lines
....
dt=dBasePropertyReal("Timestep")
call output(time,dt,nstep+1,nbegin)
...
should be exchanged, because to calculate the right time for the output we need the old
timestep, not the new one. So one should write:
....
call output(time,dt,nstep+1,nbegin)
dt=dBasePropertyReal("Timestep")
...

3. materials/eos.F90
The documentation for Flash 2.3 says, that for 

call eos(...,input)

the integer input specifies whether temperature (input=1) or internal energy(input=2)
are used together with the density and composition as input.
(Additionally in the source code one can find, that for input=3 pressure together with 
density and composition is used as input.)
But this statement is not exactly true. When using call eos(dens, temp, pres, ener, ... ,2),
the result does(!) depend on the value of the variable "temp" in contrast to the documentation.
Does one call eos(...,2) with the variable temp uninitialized or initialized e.g. with temp = 0.0,
the subroutine eos does give wrong results for the state variables. It seems to be, that the value of the 
variable "temp" is always read in as a starting value for the newton iteration that is done intenally
in the subroutine eos. If this value is not good, the iteration fails to converge to the right result and
the computation of the state variables with input=2 or 3 does give wrong results. 
The solution to this problem should be either in setting the temperature variable in the 
eos subroutine to intent(out) in case of input=2,3, so it is not used as an input value
or to correct the documentation.

I hope these bug descriptions are helpful for somebody. 

Andreas Maier
 




_______________________________________________________
WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern
Informationen unter: http://freemail.web.de/?mc=021199