Hello,
McLachlan has its own code to compute the violation of the constraints, but is thorn ADMConstraints also supposed to work with ML? I found that ML_ADMConstraints and ADMConstraints give results that differ of orders of magnitude.
Best, Luca
On 21 Mar 2012, at 06:00, Luca Baiotti wrote:
Hello,
McLachlan has its own code to compute the violation of the constraints, but is thorn ADMConstraints also supposed to work with ML? I found that ML_ADMConstraints and ADMConstraints give results that differ of orders of magnitude.
Luca has been discussing this with me. I believe the situation is that ML_BSSN and ML_ADMConstraints give consistent values for the constraints, but ADMConstraints gives results which differ by orders of magnitude. Note that this occurs where there is matter. Is it possible that ADMConstraints does not use the correct matter-coupling mechanism for the stress-energy tensor?
ADMConstraints does not know about TmunuBase. TmunuBase has a compatibility mechanism, but this may be disabled (either by default or by choice).
Also, ADMConstraints is only second order accurate by default (depending on ADMMacros).
-erik
On Wed, Mar 21, 2012 at 8:03 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 21 Mar 2012, at 06:00, Luca Baiotti wrote:
Hello,
McLachlan has its own code to compute the violation of the constraints, but is thorn ADMConstraints also supposed to work with ML? I found that ML_ADMConstraints and ADMConstraints give results that differ of orders of magnitude.
Luca has been discussing this with me. I believe the situation is that ML_BSSN and ML_ADMConstraints give consistent values for the constraints, but ADMConstraints gives results which differ by orders of magnitude. Note that this occurs where there is matter. Is it possible that ADMConstraints does not use the correct matter-coupling mechanism for the stress-energy tensor?
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
From this I understand that ADMConstraints should not be used with ML. In order to prevent accidental use, would it be possible to insert a parameter check in ML that warns against ADMConstraints? Or at least a note in the README file and documentation of ADMConstraints?
Luca
On 22/3/12 10:57 AM, Erik Schnetter wrote:
ADMConstraints does not know about TmunuBase. TmunuBase has a compatibility mechanism, but this may be disabled (either by default or by choice).
Also, ADMConstraints is only second order accurate by default (depending on ADMMacros).
-erik
On Wed, Mar 21, 2012 at 8:03 AM, Ian Hinderian.hinder@aei.mpg.de wrote:
On 21 Mar 2012, at 06:00, Luca Baiotti wrote:
Hello,
McLachlan has its own code to compute the violation of the constraints, but is thorn ADMConstraints also supposed to work with ML? I found that ML_ADMConstraints and ADMConstraints give results that differ of orders of magnitude.
Luca has been discussing this with me. I believe the situation is that ML_BSSN and ML_ADMConstraints give consistent values for the constraints, but ADMConstraints gives results which differ by orders of magnitude. Note that this occurs where there is matter. Is it possible that ADMConstraints does not use the correct matter-coupling mechanism for the stress-energy tensor?
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello Luca, all,
From this I understand that ADMConstraints should not be used with ML. In order to prevent accidental use, would it be possible to insert a parameter check in ML that warns against ADMConstraints? Or at least a note in the README file and documentation of ADMConstraints?
The default parameters of TmunuBase should work with ADMConstraints. The TmunuBase parameter Erik is referring to is TmunuBase::support_old_CalcTmunu_mechanism which is on by default (for backwards compatability, this might change in the future!). If support_old_CalcTmunu_mechanism==yes then ADMConstraints should pick up Tmunu from CalcTmunu.inc (as Ttt, Ttx etc, see ADMConstraints/src/ADMConstraints.F). Do you know if TmunuBase::support_old_CalcTmunu_mechanism is set in your parameter file?
Also note that the "old" mechanism is terribly slow since Cactus checks for each grid point whether TmunuBase is active before executing the its part of the include file (only for "USES INCLUDE" code include files, not for "USES INCLUDE HEADER" header include files). Since the checking involves walking a linked list and stricmp() calls, you can spend a good fraction of you computation time in it :-) .
A good way to prevent accidental use with wrong parameter settings might be add a warning (level 1 or 0) to the "else" branch of the "if (stress_energy_2_state .ne. 0) then" section in TmunuBase/TmunuBase_CalcTmunu.inc which would trigger when the mechanism is used (independent of which thorn tries to use it).
Yours, Roland
Hello Roland,
thanks for the explanation.
On 23/3/12 10:44 AM, Roland Haas wrote:
Hello Luca, all,
From this I understand that ADMConstraints should not be used with ML. In order to prevent accidental use, would it be possible to insert a parameter check in ML that warns against ADMConstraints? Or at least a note in the README file and documentation of ADMConstraints?
The default parameters of TmunuBase should work with ADMConstraints. The TmunuBase parameter Erik is referring to is TmunuBase::support_old_CalcTmunu_mechanism which is on by default (for backwards compatability, this might change in the future!). If support_old_CalcTmunu_mechanism==yes then ADMConstraints should pick up Tmunu from CalcTmunu.inc (as Ttt, Ttx etc, see ADMConstraints/src/ADMConstraints.F). Do you know if TmunuBase::support_old_CalcTmunu_mechanism is set in your parameter file?
I set that parameter to no. I tried to set it to yes and the values are correct indeed.
Also note that the "old" mechanism is terribly slow since Cactus checks for each grid point whether TmunuBase is active before executing the its part of the include file (only for "USES INCLUDE" code include files, not for "USES INCLUDE HEADER" header include files). Since the checking involves walking a linked list and stricmp() calls, you can spend a good fraction of you computation time in it :-) .
A good way to prevent accidental use with wrong parameter settings might be add a warning (level 1 or 0) to the "else" branch of the "if (stress_energy_2_state .ne. 0) then" section in TmunuBase/TmunuBase_CalcTmunu.inc which would trigger when the mechanism is used (independent of which thorn tries to use it).
All right.
Luca
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Ian Hinder -
Luca Baiotti -
Roland Haas