The dgfe branch for McLachlan generates NaNs

Issue #1631 wontfix
Jonah Miller created an issue

When one uses the gamma driver formulation in the dgfe branch of McLachlan and sets the shiftGammaCoefficient to zero, the runtime output has NaNs because the code divides by zero.

A bit of flow control fixes this. Attached is a patch for the branch.

Keyword: dgfe,mclachlan,gamma
Keyword: driver

Comments (14)

  1. Erik Schnetter
    • removed comment

    The same problem also exists on the rewrite branch, and the same solution should be applied there.

  2. Jonah Miller reporter
    • removed comment

    If no one else has started working on this, I can go through the rewrite branch and generate another patch. Just let me know.

  3. Peter Diener
    • removed comment

    I'm currently working on the compatibility of the rewrite branch with the main branch. In order to reduce the risk of conflicts, please hold off until that is completed.

  4. Jonah Miller reporter
    • removed comment

    Okay, thanks. I'll keep an eye out for the commit to the main branch.

  5. Peter Diener
    • removed comment

    This patch doesn't work when applied to the rewrite branch. This is due to vector instructions being used and so the variable shiftGammaCoeffValue is declared as a CCTK_REAL_VEC. Comparing this to a scalar value does not work. The easy fix is to replace shiftGammaCoeffValue with the scalar parameter shiftGammaCoeff. The expression for shiftGammaCoeffValue guarantees that it is zero if shiftGammaCoeff is.

  6. Roland Haas
    • removed comment

    Has there been progress on this? It is still set to "reviewed" and unless the patch actually applies I believe it should be reset to "confirmed" until a new patch is provided.

  7. Roland Haas

    Looking at the patch, I do not think this ought to be applied. The issue only happens if one sets evolveB=1 ie when one has chosen to define:

    \dot \beta^i = shiftGammaCoeff \alpha^shiftAlphaPower B^i

    so setting shiftGammaCoeff = 0 is setting \dot \beta^i to 0 which really should not be done this way. Instead shiftGammaCoeff should only be allowed strictly positive values (unless there is some use for negative ones).

    Unfortunately, the current default value for shiftGammaCoeff is 0.

  8. Log in to comment