McLachlan has incorrect READ declarations for presync.

Issue #2526 resolved
Peter Diener created an issue

The schedule.ccl file contains incorrect READ declarations for the stress-energy tensor from TmunuBase for the routines ML_BSSN_ADMBaseEverywhere and ML_BSSN_ADMBaseInterior.

The Read statements were present (but commented out) after commit 13f855e8262ca38063a4d0fff827562208c8c86e and then uncommented after commit 25db4e50dec6fb64b352d3092e9d4abd40aa3002.

If I’m not mistaken the schedule.cct is generated by Kranc, my suspicion is that they have been generated by Kranc for some time, commented out by hand until commit 13f855e8262ca38063a4d0fff827562208c8c86e and then not after that.

Comments (8)

  1. Roland Haas

    The READS generation is somewhat related to using Tmunu in expression as of commit hash e69182c "generate READS statement for stress_energy_state if needed" of Kranc which is in ET_2020_05_v0.

    While that commit does not produce READS: TmunuBase:eTxx it queries the RequireGroups variable for their presence and that variable is the one used to generate the READS and itself generates a READS: TmunuBase::stress_energy_state. Meaning: if there is a READS: TmunuBase::stress_energy_state then RequireGroups contained TmunuBase variables and READS for them will be generated. This seems to be what happens for ML_BSSN_ADMBaseEverywhere.

    That commit (once one ignores whitespace changes and putting code in a Module) adds:

    (* must match list in CodeGenCalculation.m *)
    ignoreGroups = {"TmunuBase::eTtt", "TmunuBase::eTxx", "TmunuBase::eTxy",
                    "TmunuBase::eTxz", "TmunuBase::eTyy", "TmunuBase::eTyz",
                    "TmunuBase::eTzz", "TmunuBase::eTtx", "TmunuBase::eTty",
                    "TmunuBase::eTtz"};
    If[ContainsAny[lookupDefault[spec, RequiredGroups, {}], ignoreGroups],
       "READS: " <> "TmunuBase::stress_energy_state" <> "\n",
       ""],
    

  2. Samuel Cupp

    Is there a plan to resolve this issue? I’m mainly commenting to make sure the ticket doesn’t get buried. I’ve been aware of this problem for a while and always just manually commented it out, but I don’t know if anyone has worked on this bug.

  3. Log in to comment