[Users] McLachlan crash

Vassilios Mewes vassilios.mewes at uv.es
Wed Feb 27 10:30:07 CST 2013


hello Erik,

i set ML_BSSN::MinimumLapse  = 1e-8 in the par file...

i think the output of the minimum lapse is not correct (in the plot i sent
you i plotted admbase::lapse.minimum.asc), because the minimum lapse is
actually much smaller...

i have attached a plot of the lapse along x (admbase::lapse.x.asc) at the
final time step that was output..

best wishes,

Vassili


On Wed, Feb 27, 2013 at 5:11 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote:

> Vassilli
>
> This lapse minimum looks strange. During evolution, if there is a
> puncture, the lapse minimum should be much smaller than 0.4.
>
> Of course, in the end (when the lapse minimum becomes negative), things go
> wrong. You could set McLachlan's parameter to enforce a positive lapse,
> e.g. enforcing that the lapse does not go below 10^-10.
>
> -erik
>
>
> On Wed, Feb 27, 2013 at 11:01 AM, Vassilios Mewes <vassilios.mewes at uv.es>wrote:
>
>> hello Erik,
>>
>> i have attached a plot of the minimum value of the lapse vs time....
>>
>> here is the segment of the par file where i set the dissipation:
>>
>> Dissipation::order = 5
>> Dissipation::vars = "
>>         ML_BSSN::ML_log_confac
>>         ML_BSSN::ML_metric
>> ML_BSSN::ML_trace_curv
>>         ML_BSSN::ML_curv
>>         ML_BSSN::ML_Gamma
>>         ML_BSSN::ML_lapse
>>         ML_BSSN::ML_shift
>>   ML_BSSN::ML_dtlapse
>>         ML_BSSN::ML_dtshift
>> "
>>
>> best wishes,
>>
>> Vassili
>>
>>
>> On Wed, Feb 27, 2013 at 4:45 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote:
>>
>>> Vassili
>>>
>>> In my experience, one needs to "control" the puncture by ensuring that
>>> (a) things evolve only slowly there (keeping the lapse small) and (b)
>>> adding sufficient dissipation.
>>>
>>> What is the value of the lapse near the puncture?
>>> How much dissipation are you adding?
>>> To which variables are you adding dissipation?
>>>
>>> -erik
>>>
>>>
>>> On Wed, Feb 27, 2013 at 8:53 AM, Vassilios Mewes <vassilios.mewes at uv.es>wrote:
>>>
>>>> Hello all,
>>>>
>>>> still no success with the full evolution of BH+torus...
>>>>
>>>> i have attached the par file i have been using lately, in which i added
>>>> two more levels of mesh refinement, as Roland suggested, increased the
>>>> Dissipation order to 5th and removed the parameter
>>>> ML_BSSN::dt_lapse_shift_method = "noLapseShiftAdvection"..
>>>>
>>>> this has improved things a bit, but the L_inf norm of the hamiltonian
>>>> constraint still starts growing at around t=200 (after having decreased and
>>>> then having been rather constant up to that point) and then the simulation
>>>> will crash later (either due to the shift being nan at the puncture or by
>>>> detecting nans)
>>>>
>>>>
>>>> in the meantime, i have evolved a single puncture, the bondi accretion
>>>> onto a puncture and an "inverse cowling" (setting up the spacetime and
>>>> hydro variables of the BH+torus system but only evolving the spacetime),
>>>> all using the same parameters, and all of those work...its only the full
>>>> system of BH+torus when i run into problems...this is using the ET 2012.11.
>>>> release..
>>>>
>>>> do you have any ideas what might go wrong with the spacetime evolution
>>>> when evolving the full system?
>>>>
>>>> best wishes,
>>>>
>>>> Vassili
>>>>
>>>>
>>>> On Tue, Feb 12, 2013 at 2:07 AM, Roland Haas <
>>>> roland.haas at physics.gatech.edu> wrote:
>>>>
>>>>> Hello Vassilios,
>>>>>
>>>>> > as mentioned earlier in the ET phone call, i have attached the par
>>>>> file
>>>>> > used in the run...
>>>>> >
>>>>> > i tried checking for the nans in the output, but the last hdf5
>>>>> output was
>>>>> > too many iterations earlier and they aren't visible in 1D ascii
>>>>> output
>>>>> > either
>>>>> >
>>>>> > as said, the puncture tracker actually aborted the run, not the nan
>>>>> > checker...
>>>>> Thank you for the parameter file. As a unsubstantiated guess, I would
>>>>> try what happens if you move the outer boundary further out. Right now
>>>>> it sits at 50M which I would find uncomfortably close if there is any
>>>>> say "junk" radiation (eg from setting up a BH with spin in flat
>>>>> background) present. I'd move it to at least 200M (ie two more levels
>>>>> of
>>>>> mesh refinement). Not sure how likely this explanation is since your
>>>>> NaNs appear after many (9) light crossing times.
>>>>>
>>>>> Yours,
>>>>> Roland
>>>>>
>>>>> --
>>>>> My email is as private as my paper mail. I therefore support encrypting
>>>>> and signing email messages. Get my PGP key from http://keys.gnupg.net.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at einsteintoolkit.org
>>>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at einsteintoolkit.org
>>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>>>
>>>>
>>>
>>>
>>> --
>>> Erik Schnetter <schnetter at cct.lsu.edu>
>>> http://www.perimeterinstitute.ca/personal/eschnetter/
>>>
>>
>>
>
>
> --
> Erik Schnetter <schnetter at cct.lsu.edu>
> http://www.perimeterinstitute.ca/personal/eschnetter/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20130227/ee9e7bcf/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lapse_x_441.png
Type: image/png
Size: 24370 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20130227/ee9e7bcf/attachment-0001.png 


More information about the Users mailing list