[FLASH-USERS] Computing Radiation Timestep with Multitype Configuration

[Klaus Weide]

On Wed, 11 Dec 2019, Keith Galvin wrote:

> It's failing in the actual Eos routine.  I can trace the abort message that
> you see in the log below back to ../multiTemp/Multitype/Eos.F90.  It's
> being given input of mode MODE_DENS_ TEMP_ELE when it's called in
> rt_computeDt.F90.  The select case statement which starts on line 495

[ ^^^ Keith clarified in e-mail that he meant RadTrans_computeDt.F90 here.]

> doesn't have a case specification for that mode, so it goes to the default
> case which aborts.


(The primary SELECT CASE statement in .../multiTemp/Multitype/Eos.F90, the 
one that actually does most of the work, is the one that starts on line 
547 in the current release; the ones that precede this only set some 
variables in preparation.)

You are right that the CASE construct is missing a

  case (MODE_DENS_TEMP_ELE)

(as well as code for handling some other cases, like MODE_DENS_TEMP_ION).
Such code could be easily added, it essentially would just have to pass
the work to a call like

  call eos_multiTypeByTemp(MODE_DENS_TEMP_ELE,vecLen,eosData,ilo,ihi,massFrac,mask=maskPlus,componentMask=(/0,1,0/))

(as is done as part of the handling of MODE_DENS_TEMP_COMP and similar).

One may wonder why case MODE_DENS_TEMP_ELE is not being handled in this 
version of Eos.F90 .  My best answer to that is that code has been added 
for the most part just for cases that actually occurred in practice; and 
apparently there haven't been any calls of Eos (directly or indirectly) 
with MODE_DENS_TEMP_ELE in any of the setups or solver implementations 
that would typically be used together with this Eos implementation.

Keith, you have encountered such a call in RadTrans_computeDt.F90; but 
that code is normally not active in 3T simulations that would use the 
../multiTemp/Multitype/Eos.F90 implementations, since PARAMETER 
rt_computeDt defaults to FALSE. One reason for THAT is that the time step 
computation in RadTrans_computeDt.F90 is of questionable value, in my 
understanding. If you look at the code, you will find that the time step 
computation is based only on the energy coupling between electrons and 
energy groups, *not* on the actual spatial part of transport. (One way to 
tell is the observation that absorb_opac is being used, but trans_opac not 
at all.)

So the existing RadTrans_computeDt may or may not be useful for you.

And if you want to try using it without modifying code in Eos.F90,
it should be valid to just change the line

  mode = MODE_DENS_TEMP_ELE

in RadTrans_computeDt.F90 to something like

  mode = MODE_DENS_EI_ELE   ! or MODE_DENS_TEMP_COMP, or MODE_DENS_EI_GATHER

(which should all work since the only output from the Eos call that is 
wanted here is eos_arr(EOS_CVELE); there may just be some additional 
computational overhead, depending on the mode chosen.)


Klaus