[FLASH-USERS] restart PM run in UG mode

[Tomasz Plewa]

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
>>>
>>>
>>>     
>>>       
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tplewa.vcf
Type: text/x-vcard
Size: 338 bytes
Desc: not available
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20100330/92c1fc4c/attachment.vcf>