[FLASH-USERS] restart PM run in UG mode
Tomasz Plewa
tplewa at fsu.edu
Wed Mar 31 08:35:00 EDT 2010
Conversion of variables is a nightmare in RHD and reducing the time
step, perhaps with some semi-automatic restart, might be the only
option. Contacting Andrea may help.
Since you did not mention any major problems with the RHD solver option,
especially mesh-related, I am optimistic the threshold-based refinement
works as expected.
Tomek
--
Alexander Wagner wrote:
> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
-------------- 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/20100331/a05dc85f/attachment.vcf>
More information about the flash-users
mailing list