[FLASH-USERS] Error in AMR Prolong Routine

[James Guillochon]

Problem solved! So it seems the problem was that the  
gr_updateRefinement routine does not sanitize the guard cells. So if  
you happen to derefine a block that has density values close to  
smlrho, it is possible that guard cells will end up with 0 density  
values and will never be sanitized. This is resolved by changing a  
line in gr_updateRefinement from this:

call gr_sanitizeDataAfterInterp(gr_blkList, numLeafBlocks, 'after  
amr_prolong', 0, 0, 0)

to this:
call gr_sanitizeDataAfterInterp(gr_blkList, numLeafBlocks, 'after  
amr_prolong', NGUARD, NGUARD, NGUARD)

This is probably a bug that should be fixed in the base version of  
FLASH.

Thanks again for everyone's suggestions!

-- 
James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org

On Apr 10, 2009, at 11:25 AM, James Guillochon wrote:

> Anshu,
>
> Thanks for the response. I am a bit skeptical that it is a memory  
> issue, because the simulation runs without issue for 5000 steps and  
> this crash recurs even after restarting from a checkpoint file only  
> 36 steps before the crash. Only a few blocks are refined and  
> derefined during this period, whereas thousands are refined and  
> derefined earlier in the simulation. So if this is a memory issue,  
> it is one that arises very quickly.
>
> Just to be clear, I do not have a modified Driver_sourceTerms.F90  
> file in this simulation, so I am never explicitly setting the  
> density values myself.
>
> -- 
> James Guillochon
> Department of Astronomy & Astrophysics
> University of California, Santa Cruz
> jfg at ucolick.org
>
> On Apr 10, 2009, at 10:45 AM, Anshu Dubey wrote:
>
>> James,
>>
>> There is no place where density gets set to 0 explicitly. Normally we
>> encounter density going 0 only when the memory is getting trampled
>> somewhere, and so there is some bug somewhere. If you are seeing this
>> in the recv array, then you might be skirting too close to using up
>> all the available memory on the system. One such situation we
>> encounterd once  had to do with there being not enough memory for an
>> allocate call, but instead of reporting error, the system returned  
>> the
>> call and memory trampled.
>>
>> Anshu
>>
>> On Thu, Apr 9, 2009 at 12:04 AM, James Guillochon <jfg at ucolick.org>  
>> wrote:
>>> Hi guys,
>>> I am running a simulation in FLASH 3.0 using multiple species, and  
>>> after
>>> about 5000 time steps, I run into the following error:
>>> [amr_prolong_gen_unk1_fun] PE=      7, ivar= 13, value= 24.0
>>>
>>> Trying to convert non-zero mass-specific variable to per-volume  
>>> form in
>>> monotonic mesh interpolation, but dens is zero!
>>> The ivar = 13 being referred to here is the first species in my  
>>> species list
>>> defined in Flash.h, which at the time of the abort is equal to  
>>> smallx
>>> everywhere. It appears from the code that the recv variable array  
>>> must have
>>> a zero value for density in at least one grid cell, but as far as  
>>> I'm aware
>>> the density variable should never drop below smallrho!
>>> Tracking the origin of this issue could take a very long time, so  
>>> I was
>>> hoping someone here has encountered this issue before and knows of  
>>> a remedy?
>>> Is there anywhere in FLASH where the density is set explicitly to  
>>> zero?
>>> Thanks!
>>> --
>>> James Guillochon
>>> Department of Astronomy & Astrophysics
>>> University of California, Santa Cruz
>>> jfg at ucolick.org
>>>
>>
>>
>
>
> !DSPAM:10135,49df8f1629174021468!
>