[FLASH-USERS] possible bug in gr_sanitizeDataAfterInterp.F90

[Mateusz Ruszkowski]

   Hi,

I suspect there may be a minor bug in gr_sanitizeDataAfterInterp.F90 related to setting floor values.

The problem only occurs for gr_sanitizeDataMode = 3 but does not affect the solution when the default setting of 5 is used instead. The gr_sanitizeDataMode = 3 allows one to impose a floor on unk(EINT_VAR,il,jl,kl,block) = gr_smalle (which is equal to smalle set in flash.par which, per FLASH convention, is defined as erg/g). The problem stems from the fact that unk values for EINT_VAR accessed by this routine appear to be defined per volume for some calls and per mass for other calls. [this occurs when convertToConsvdInMeshInterp = .true.  and convertToConsvdForMeshCalls = .false. , i.e., when these parameters are set to their default values]. 

I verified the problem occurres only when unk(EINT_VAR) is defined as per volume during a call to gr_sanitizeDataAfterInterp.F90. So when this routine uses unk(EINT_VAR) in this mode, then this unk value can fall below gr_smalle (defined as per mass) and a floor is imposed when it should not. Consequently, code time step can become unphysical small the moment the code takes its first evolution step (switching back to the default gr_sanitizeDataMode = 5 "fixes" the time step problem, the code evolves as expected, but it never imposes floor values).

In order to fix this problem one would need to know whether unk accessed by gr_sanitizeDataAfterInterp.F90 is in the primitive or conservative form for every call. Am I correct that this behavior is not what is intended? Is there a quick fix to this? Apologies if I misunderstood how this is supposed to work in this non-default setting.

    Thanks,
      Mateusz