As far as I understand ADMMass uses metric and lapse thought ADMMacros and it calculates derivatives of the metric inside. All those GF looks fine. The problem appears when I use mesh refinement.
On Thu, Oct 4, 2012 at 3:00 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 4 Oct 2012, at 10:02, Petr Tsatsin wrote:
Hello, I recently started using ADMMass thorn and I found out the following problem. If I use it on the unigrid set up everything works fine, however if i use mesh refinement it gives correct values at t=0 but then all the values become something like this -3.50039744772644e+244. I was wondering if anybody experience such a problem? I used standard static_tov.par for testing purposes. Thank you.
I haven't used this thorn, but this looks like poison. i.e. variables which are initialised to a fixed large number in order to catch bugs. This indicates that something is accessing data which has not been initialised properly. Can you output the grid functions that are being used in the ADMMass computation and see if they are reasonable? Alternatively, you could compute their norm, which should also be strongly affected by this.
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
On Thu, Oct 04, 2012 at 03:57:25PM -0400, Petr Tsatsin wrote:
As far as I understand ADMMass uses metric and lapse thought ADMMacros and it calculates derivatives of the metric inside. All those GF looks fine. The problem appears when I use mesh refinement.
Hi,
Do values 'look ok' every so and so iterations? If so, something is likely to be wrong with past time levels. ADMMass performs reductions, which use time interpolations in case refinement levels don't line up in time. If past timelevels are not populated correctly this would show as strange numbers. Every so many iterations (depending on your setup) however, all refinement levels are 'at the same time'. Then no time interpolations are done and values should be ok.
Another possibility is that because ADMMass uses ADMMacros and ADMMacros use the old Tmunu mechanism, this can go wrong when you do not use TmunuBase::support_old_CalcTmunu_mechanism = yes (not advised in general: slow!) However, I would not expect numbers _that_ wrong in this case. However, I would like to know if this should indeed be the problem.
Frank
Hello Peter, Frank,
However, I would not expect numbers _that_ wrong in this case. However, I would like to know if this should indeed be the problem.
Are you running with Carpet's poison parameters turned on (I always advertise to do so)? If so, then you are likely seeing poison. Most likely caused by bad data on past timelevels (caused by eg computing the to be integrated quantities only every so often and not on every iteration).
Yours, Roland
Values look ok only for initial data at t=0 and then they equal to this "poison number". I'll run it with TmunuBase::support_old_CalcTmunu_mechanism = yes and let you know the results.
On Thu, Oct 4, 2012 at 5:17 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, Oct 04, 2012 at 03:57:25PM -0400, Petr Tsatsin wrote:
As far as I understand ADMMass uses metric and lapse thought ADMMacros
and
it calculates derivatives of the metric inside. All those GF looks fine. The problem appears when I use mesh refinement.
Hi,
Do values 'look ok' every so and so iterations? If so, something is likely to be wrong with past time levels. ADMMass performs reductions, which use time interpolations in case refinement levels don't line up in time. If past timelevels are not populated correctly this would show as strange numbers. Every so many iterations (depending on your setup) however, all refinement levels are 'at the same time'. Then no time interpolations are done and values should be ok.
Another possibility is that because ADMMass uses ADMMacros and ADMMacros use the old Tmunu mechanism, this can go wrong when you do not use TmunuBase::support_old_CalcTmunu_mechanism = yes (not advised in general: slow!) However, I would not expect numbers _that_ wrong in this case. However, I would like to know if this should indeed be the problem.
Frank
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJQbf0DAAoJEOkzpip+I59kYgoP/0Rl0FGAmrYCNkha4gs70kab 7F9IC23N5zMoQ0QwbgN3h4UqBRNV1aXsI3RofAvj5h2rRzvIOGpK4fh2RvfYKAZa 4PcoEaYEM3ond/2uZlyGB5q1MO7D+2yC6sMIrEqrnC8D7SNWH28r46WwpfuFDPuW 3X6O47xydSG/DTS/eg9GBkr2dAroV0FChUEGi4k2SW4YKbrmTJPA+og4pULnvoOS CoiPKx6bVPTXQtlzu6mRBW3kDD92jhdUCvR2hIzwC6nZNqKm+95IWCgw0rES5TMv R/eTFxtvi4fwvVc693MfOOLNJk0MubFWIzsxcNQDT1Ioi13+3c0NKCUvGDROgEKG EOQ0vzWeKkjvisOm6/uAC0xPmTWNRl4pFbn7quGKz1APha4Pq+abYkSPPOGclWKP kghy4lqm2xtmfYfGl9OcKoBIHE2BVoab1jucsPHOKQVp/jU7OlbvawAJowzAYwTg 5EaPlxe8yGNUoMK96HjmJAJ6zZh5zT0KmoNzTKltS5S9UG2uDojB4ApxgqYdI6M3 P1l03yYSlOasrLldz9QvGQTCh0DaaohWu9vHrWjZyLaGV+R4O9yugu4iQS7QYV9y VR+jIUXWhMgmqxyaAdJwcTumjjhAHlbz9wo9dooST3k8f30EyrqcSRRzaCBK81d5 3uCRGxDC6wgvVNG2ZLWt =B8bd -----END PGP SIGNATURE-----
Hi, I did a run with TmunuBase::support_old_CalcTmunu_mechanism = yes and it works. However at the beginning several iterations i got 'poison values' after the values ok. Another thing is that Surface Integrals Values osculate from 0 to correct value for the ADM mass. Volume Integrated ADM Mass looks ok.
On Thu, Oct 4, 2012 at 5:17 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, Oct 04, 2012 at 03:57:25PM -0400, Petr Tsatsin wrote:
As far as I understand ADMMass uses metric and lapse thought ADMMacros
and
it calculates derivatives of the metric inside. All those GF looks fine. The problem appears when I use mesh refinement.
Hi,
Do values 'look ok' every so and so iterations? If so, something is likely to be wrong with past time levels. ADMMass performs reductions, which use time interpolations in case refinement levels don't line up in time. If past timelevels are not populated correctly this would show as strange numbers. Every so many iterations (depending on your setup) however, all refinement levels are 'at the same time'. Then no time interpolations are done and values should be ok.
Another possibility is that because ADMMass uses ADMMacros and ADMMacros use the old Tmunu mechanism, this can go wrong when you do not use TmunuBase::support_old_CalcTmunu_mechanism = yes (not advised in general: slow!) However, I would not expect numbers _that_ wrong in this case. However, I would like to know if this should indeed be the problem.
Frank
On Fri, Oct 05, 2012 at 05:30:18PM -0400, Petr Tsatsin wrote:
Hi, I did a run with TmunuBase::support_old_CalcTmunu_mechanism = yes and it works.
Hi Petr,
Can you please try the attached patch to ADMMacros with TmunuBase::support_old_CalcTmunu_mechanism = no and see if that still works and gives the same results? You will have to add inheritance of some thorns to TmunuBase though, or maybe add that to ADMMacros (which is not done by the patch).
However at the beginning several iterations i got 'poison values' after the values ok.
This probably means that past timelevels haven't been correctly initialized by the initial data routines.
Another thing is that Surface Integrals Values osculate from 0 to correct value for the ADM mass. Volume Integrated ADM Mass looks ok.
My best guess would again be that something isn't initializing past timelevels correctly. This would show in correct values whenever refinement levels 'exist' at the time of integration. '0' is however a pretty strange value. Something else must be wrong as well.
You could try to see whether you see something strange using the following parameter:
ADMMass_Debug = "yes"
Frank
users@lists.einsteintoolkit.org
-
Frank Loeffler -
Petr Tsatsin -
Petr Tsatsin -
Roland Haas