[FLASH-USERS] restart PM run in UG mode

[Alexander Wagner]

Hi Tomek,

Yes I meant the relativistic solver. I haven't been in touch with Andrea 
Mignone, but you are right, that's perhaps something I should do. So far 
my experience with the RHD solver has been quite positive. I've added 
support for advected scalars and am thinking about what the best way to 
include gravity is (another good reason to contact Andrea). 
Occasionally, I get Vel > 1 in hy_rhd_conserveToPrimitive. Reducing the 
Courant number usually gets me out of this one, though it's not a good 
sign, i guess.

I'll also try your idea with setting the refinement thresholds. Thanks 
for that!

Best wishes,
Alex


Tomasz Plewa wrote:
> Alexander -
>
> By the way, by RHD you mean relativistic solver, correct? Have you 
> been in touch with Andrea Mignone? It is really his baby, but he left 
> Chicago and has only been incidentally involved (which is a shame). 
> One reason for my relative distrust in RHD capability is that it has 
> not been programmatically blessed area of the FLASH Center research. 
> So stitching has been done at times quite hastily and what works in 
> principle of pure hydro may not work for other solvers.
>
> In either case, let me know you are finding and perhaps I could offer 
> some advice. For example, if lrefine_min=lrefine_max approach does not 
> work, you may simply want to set thresholds for refinement to some 
> ridiculously small values forcing the full refinement. Then dump a 
> checkpoint and restart with nrefs=0. That may avoid the broken logic 
> part.
>
> Tomek
> -- 
> Alexander Wagner wrote:
>> Ok, thanks, I'll see if I can find anything.
>>
>> Cheers,
>> Alex
>>
>>
>> Tomasz Plewa wrote:
>>  
>>> Alexander -
>>>
>>> I see. I do not know of too many FLASH RHD unit applications. 
>>> Perhaps some real debugging is due.
>>>
>>> Again, since all the information is readily available, it seems like 
>>> the code restart logic is broken.
>>>
>>> Tomek
>>> -- 
>>> Alexander Wagner wrote:
>>>    
>>>> Hi Tomek,
>>>>
>>>> After setting convertToConsvdInMeshInterp = .false. I still get the 
>>>> error
>>>>
>>>> [Eos_wrapped] ERROR Density or Internal Energy are zero after a 
>>>> call to EOS!
>>>> [ 03-31-2010  18:34:31.188 ] [DRIVER_ABORT]: Driver_abort() called 
>>>> by PE
>>>>
>>>> Though not anymore the warning
>>>>
>>>> WARNING after gc filling: min. 
>>>> unk(DENS_VAR)=0.000000000000000000000  PE=219   block=83 type=2    
>>>> [...]
>>>>
>>>> I was able to dump a checkpoint file but when restarting with that 
>>>> checkpoint file (and nrefs=0), I get the same problems, that is, 
>>>> there are regions with 0 values in the mesh.
>>>>
>>>> I'm going to inspect the checkpointfile with VisIt, but it seems 
>>>> some debugging is necessary.
>>>>
>>>> It is perhaps also worth mentioning that I'm using the RHD unit. 
>>>> Can you think of a reason that this trick might not work with the 
>>>> RHD unit.
>>>>
>>>> Many thanks for your help so far!
>>>> Alex
>>>>
>>>>
>>>> Tomasz Plewa wrote:
>>>>  
>>>>      
>>>>> Erm... Your mesh contains enough information and so that should 
>>>>> never happen. It seems like a bug to me, possibly a broken code 
>>>>> logic.
>>>>>
>>>>> Try setting
>>>>>
>>>>> convertToConsvdInMeshInterp     = .false.
>>>>>
>>>>> If that does not help (perhaps to overcome broken logic), one 
>>>>> would need to debug the code.
>>>>>
>>>>> Tomek
>>>>> -- 
>>>>> Alexander Wagner wrote:
>>>>>           
>>>>>> Hi Tomek,
>>>>>>
>>>>>> I tried your suggested method but portions of the grid get filled 
>>>>>> with 0s when I restart with lrefine_min=lrefine_max.
>>>>>>
>>>>>>
>>>>>>  iteration, no. not moved =            0      191394
>>>>>>  iteration, no. not moved =            1       77989
>>>>>>  iteration, no. not moved =            2           0
>>>>>> ...skipping...
>>>>>> refined: total leaf blocks =       202952
>>>>>> refined: total blocks =       231945
>>>>>> INFO: Grid_fillGuardCells is ignoring masking.
>>>>>> WARNING after gc filling: min. 
>>>>>> unk(DENS_VAR)=0.000000000000000000000          PE=219   
>>>>>> block=83                               type=2    [...]
>>>>>>
>>>>>>
>>>>>> DRIVER_ABORT:
>>>>>> [Eos_wrapped] ERROR Density or Internal Energy are zero after a 
>>>>>> call to EOS!
>>>>>>
>>>>>> What am I doing wrong?
>>>>>> Cheers,
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>>
>>>>>> Tomasz Plewa wrote:
>>>>>>  
>>>>>>               
>>>>>>> The simplest way of eliminating most of the AMR overhead is to set
>>>>>>> lrefine_min=lrefine_max upon restart, dump a checkpoint after 
>>>>>>> the first
>>>>>>> mesh refinement, and restart again but now with nrefs=0.
>>>>>>>
>>>>>>> It will not be as fast as real UG, but estimating possible gains 
>>>>>>> is not
>>>>>>> straightforward. If I remember correctly and for simple hydro, 
>>>>>>> the above
>>>>>>> approach offers gains provided the filling factor exceeds about 
>>>>>>> 0.3.
>>>>>>>
>>>>>>> Tomek
>>>>>>> -- 
>>>>>>> On 3/29/2010 7:49 PM, Alexander Wagner wrote:
>>>>>>>                        
>>>>>>>> Dear FLASH developers/users,
>>>>>>>>
>>>>>>>> Just a quick question, as I can't find the answer in the manual or
>>>>>>>> mailing list archive;
>>>>>>>>
>>>>>>>> Is it possible to restart an AMR simulation in UG mode with a
>>>>>>>> checkpoint file created in PM mode? Or does it involve starting 
>>>>>>>> a new
>>>>>>>> run and reading in the initial conditions from the checkpoint file
>>>>>>>> manually.
>>>>>>>>
>>>>>>>> I can imagine this being a scenario commonly required when the 
>>>>>>>> flow in
>>>>>>>> a simulation (especially in 3D) becomes more complex and fills 
>>>>>>>> larger
>>>>>>>> portions of the domain; at some point most of the domain is 
>>>>>>>> maximally
>>>>>>>> refined and the overhead in AMR exceeds the advantages of using 
>>>>>>>> AMR.
>>>>>>>>
>>>>>>>> Many thanks,
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>
>>>>>>>>