Hello all,
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...
the last lines of the simulation log look like this:
INFO (AHFinderDirect): proc 0: searching for horizon 1/1 INFO (AHFinderDirect): AH 1/1: r=0.888981 at (-0.010571,0.042863,0.000000) INFO (AHFinderDirect): AH 1/1: area=37.24715073 m_irreducible=0.8608185171 71872 449.200 | 0.3696424 0.9877759 | 8.7614309 | 1.847988e+05 | 1.489620e-12 0.0001394 | 7.655611e-18 0.0000003 71876 449.225 | 0.3696349 1.0105778 | 8.7608144 | 1.848221e+05 | -0.0000005 0.0001395 | -1.183581e-09 0.0000003 INFO (Refluxing): Refluxing at iteration 71880 on level 3 of 5 INFO (Refluxing): Refluxing on level 3: INFO (Refluxing): Refluxing at iteration 71880 on level 4 of 5 71880 449.250 | 0.3696287 1.9741189 | 8.7609976 | 1.848285e+05 | -0.0000006 0.0001395 | -2.225731e-09 0.0000003 71884 449.275 | 0.3366873 4.239172e+39 | 8.7611688 | 1.848352e+05 | -0.0000003 0.0001395 | -8.130017e-10 0.0000003 INFO (Refluxing): Refluxing at iteration 71888 on level 2 of 5 INFO (Refluxing): Refluxing on level 2: INFO (Refluxing): Refluxing at iteration 71888 on level 3 of 5 INFO (Refluxing): Refluxing on level 3: INFO (Refluxing): Refluxing at iteration 71888 on level 4 of 5 71888 449.300 | 0.0000000 1.130446e+40 | 8.7613044 | 1.848426e+05 | 1.457866e-12 0.0001395 | 7.432056e-18 0.0000003 71892 449.325 | -0.2467648 8.478344e+39 | 8.7609892 | 1.848595e+05 | -0.0000030 0.0001395 | -4.615484e-09 0.0000003 INFO (Refluxing): Refluxing at iteration 71896 on level 3 of 5 INFO (Refluxing): Refluxing on level 3: INFO (Refluxing): Refluxing at iteration 71896 on level 4 of 5 71896 449.350 | 0.0000000 1.599816e+26 | 8.7611584 | 1.848662e+05 | -0.0000037 0.0001395 | -6.024551e-09 0.0000003 71900 449.375 | -1.413057e+39 1.199862e+26 | 8.7613031 | 1.848734e+05 | -0.0000022 0.0001395 | -4.227202e-09 0.0000003 INFO (Refluxing): Refluxing at iteration 71904 on level 1 of 5 INFO (Refluxing): Refluxing on level 1: INFO (Refluxing): Refluxing on level 1 map 0 component 0 direction 0 face 0: [31,31,3]:[31,32,30] INFO (Refluxing): Refluxing on level 1 map 0 component 0 direction 1 face 0: [31,31,3]:[33,31,30] INFO (Refluxing): Refluxing on level 1 map 0 component 0 direction 2 face 0: [31,31,3]:[33,32,3] INFO (Refluxing): Refluxing at iteration 71904 on level 2 of 5 INFO (Refluxing): Refluxing on level 2: INFO (Refluxing): Refluxing at iteration 71904 on level 3 of 5 INFO (Refluxing): Refluxing on level 3: INFO (Refluxing): Refluxing at iteration 71904 on level 4 of 5 71904 449.400 | 0.0000000 0.9877757 | 8.7613184 | 1.848834e+05 | 1.468319e-12 0.0001395 | 7.506929e-18 0.0000003 71908 449.425 | -1.999770e+25 0.9877756 | 8.7605818 | 1.849092e+05 | -0.0000001 0.0001395 | -7.816558e-11 0.0000003 INFO (Refluxing): Refluxing at iteration 71912 on level 3 of 5 INFO (Refluxing): Refluxing on level 3: INFO (Refluxing): Refluxing at iteration 71912 on level 4 of 5 71912 449.450 | -0.1092106 0.9877756 | 8.7604068 | 1.849231e+05 | -0.0000001 0.0001395 | -9.198894e-11 0.0000003 71916 449.475 | -0.1107971 0.9877756 | 8.7603118 | 1.849354e+05 | -0.0000000 0.0001396 | -4.147005e-11 0.0000003 WARNING level 0 in thorn PunctureTracker processor 0 host vives.uv.es (line 224 of /usus/va/vasme/cactus/ET_2012_11/Cactus/configs/ET_TORI_opt/build/PunctureTracker/puncture_tracker.c): -> Shift at puncture #0 is (-nan,-nan,-nan). This likely indicates an error in the simulation.
the infos are lapse min/max physical time/hour total time rho min/max press min/max
thanks a lot in advance,
best wishes,
Vassili
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
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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
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@uv.eswrote:
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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
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@cct.lsu.eduwrote:
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@uv.eswrote:
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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
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@uv.eswrote:
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@cct.lsu.eduwrote:
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@uv.eswrote:
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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
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@cct.lsu.eduwrote:
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@uv.eswrote:
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@cct.lsu.eduwrote:
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@uv.eswrote:
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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Vassili
Yes, this plot looks good.
Do you expect the black hole to be stationary? If so, you could look at the spacetime quantities near the puncture (the McLachlan variables, not the ADMBase variables) and see which begins to vary or to drift, causing the trouble in the end.
-erik
On Wed, Feb 27, 2013 at 11:30 AM, Vassilios Mewes vassilios.mewes@uv.eswrote:
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@cct.lsu.eduwrote:
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@uv.eswrote:
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@cct.lsu.eduwrote:
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@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@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@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Roland Haas -
Vassilios Mewes