[FLASH-USERS] Negative/zero densities and internal energies after filling gc

[Seyit Hocuk]

Thanks to everybody who replied.


To James, my problem seems to be related to your AMR prolong problem.


Klaus. I am very supprised you couldn't reproduce the problem. I 
downloaded a clean version of Flash3.1.1a and only changed these runtime 
parameters, without any other modification. You do keep lrefine_min = 4 
I hope. Do you see any (partial) refinement happening, i.e. refined 
total blocks = 277? As I am writing this, I realise I forgot 1 more 
thing. I also reduced reference density to see partial refinement. So, 
reference_density = 1.4E7.

To sum it up:
Clean version 3.1.1a
Jeans setup, only changing runtime parameters like this.
 > lrefine_max =  5
 > reference_density =  1.4E7
 > refine_cutoff_1 = 1.0

My setup was like this: ./setup Jeans -auto -portable -maxblocks=2000 && 
cd object && make -j 8 && ./flash3

If you or anybody else can't reproduce this error, then the problem is 
possibly not in the code but in the environment.
Could anybody else try this out?

Thanks,
Seyit


Ross: I will try your modification as well. If I understand you 
correctly, I have to put a call to Grid_getlistofblocks in 
Driver_evolveFlash before source terms are called.





Klaus Weide wrote:
> On Wed, 8 Apr 2009, Seyit Hocuk wrote:
>
>> Hi community,
>>
>> I've switched to Flash3.1.1a (from version 2.5),
>
> Congratulations!
>
>> but when I try to run my setup, comparable to the Jeans setup, I 
>> encounter problems. If I am running without cooling and with a 
>> uniform grid (lref_max=lref_min), then everything seems ok. However, 
>> if I add the cooling module OR I have adaptive refinement, zero or 
>> negative densities/internal energies appear (or lower than the 
>> "small" values). These cause the refinement to be messed up and of 
>> course leads to crashes. The error outpusts are shown below. From 
>> there, I notice that the error might come from guard cell filling.
>>
>> I test the standard Jeans setup and the same problems occur.
>> Just changing and adding in flash.par:
>> lrefine_max = 5
>> refine_cutoff_1 = 1.0
>
> I have run the Jeans problem from FLASH 3.1.1 with your runtime 
> parameter modifications, but could not reproduce any failures.
>
> Perhaps you have made some other changes to the code?
>
> I was also using an Intel compiler on CentOS.
>
>
>> On several occasions I have checked the Eos_wrapped.F90 file and 
>> found the location where it might go wrong;
>> just before reading solnData eint/dens was ok, but after this the 
>> values are crazy. Btw., I don't use massFractions ad haven't 
>> implemented Multispecies and no species are initiated.
>>
>>       eosData(pres+1:pres+vecLen) = &
>>            solnData(PRES_VAR,range(LOW,IAXIS):range(HIGH,IAXIS),j,k)
>>       eosData(dens+1:dens+vecLen) = &
>>            solnData(DENS_VAR,range(LOW,IAXIS):range(HIGH,IAXIS),j,k)
>>       eosData(temp+1:temp+vecLen) = &
>>            solnData(TEMP_VAR,range(LOW,IAXIS):range(HIGH,IAXIS),j,k)
>>       eosData(gamc+1:gamc+vecLen) = &
>>            solnData(GAMC_VAR,range(LOW,IAXIS):range(HIGH,IAXIS),j,k)
>>       eosData(eint+1:eint+vecLen) = energyInternal(1:vecLen)
>>
>>
>>       call 
>> Eos(mode,vecLen,eosData)!,massFraction)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 
>>
>
>
> Make sure your code has
>
>     use Eos_interface, ONLY: Eos
>
> in any functions and subroutines that call Eos. This is particularly 
> necessary for the Eos subroutine because Eos has optional arguments.
>
>
>
> Klaus