[FLASH-USERS] possible bug in gr_sanitizeDataAfterInterp.F90

[Klaus Weide]

On Fri, 27 Mar 2015, Mateusz Ruszkowski wrote:

> 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.

Mateusz,

It is true that gr_sanitizeDataAfterInterp should only be called while the 
solution in UNK is in the normal (mass-specific) form (called "primitive" 
in some context) for energies. More precisely, this should be true at 
least for the cells that are covered by the call, i.e. including some 
guard cells depending on the "layers" argument.

As far as I know, this is normally true. If you find that the 
FLASH code calls gr_sanitizeDataAfterInterp when it shouldn't - maybe 
because UNK(eint,...) has been temporarily multiplied by density -
that is a bug which should be fixed.

Does this occur in the latest release (4.2.2) or are you using some 
previous version?

Please send me some sample output, including at least several block's
worth of diagnosic output, since that can reveal a lot about the context
of the call.

Thanks,

Klaus