No boundary conditions registered for variables in group LEANBSSNMOL

[[e-mail]]

I am running the latest version of ET, using the parameter file Lean_inspiral_d06_mres.par in the lean_public par folder, I added this line:

Cactus::presync_mode = "mixed-warn"

Now, I am getting these warnings (one example of hundreds in the .out file):

-> No boundary conditions registered for variables in group LEANBSSNMOL::GAMMAT. The unregistered variable(s) is(are) LEANBSSNMOL::gammatx, LEANBSSNMOL::gammaty, LEANBSSNMOL::gammatz.

This is related to Issue #2651.

Is this a concern?

Thanks! Vikram

[Roland Haas]

@helvi witek @Miguel Zilhão could you take a look, please? You are listed as LeanBSSNMoL maintainers (according to the README file).

[Miguel Zilhão]

Can you check if this issue is also present in the current development branch of LeanBSSNMoL?

[Samuel Cupp]

I’ve never used this thorn, but I can hazard a guess. On the master branch, the function LeanBSSN_Boundaries doesn’t run until

schedule LeanBSSN_Boundaries in MoL_PostStep
{
  LANG: Fortran
  OPTIONS: LEVEL
  SYNC: ADMBase::lapse
  SYNC: ADMBase::shift
  SYNC: LeanBSSNMoL::conf_fac
  SYNC: LeanBSSNMoL::hmetric
  SYNC: LeanBSSNMoL::hcurv
  SYNC: LeanBSSNMoL::trk
  SYNC: LeanBSSNMoL::gammat
} "MoL boundary enforcement"

In the old approach, boundary conditions and ghost zone synchronization were completely independent. Now, we simply do both at the same time. Hence, scheduling like

schedule LeanBSSN_adm2bssn at CCTK_INITIAL after ADMBase_PostInitial
{
  LANG: Fortran
  OPTIONS: Local
  SYNC: gammat
} "Convert initial data into BSSN variables"

will naturally trigger warnings if there are no BCs yet. Additionally, the old method didn’t make it clear that the ApplyBCs scheduled at CCTK_INITIAL was an empty call that did nothing. Since the registered BCs look to be none, it doesn't actually matter. I thought this was resolved in Issue #2648. However, the changes aren’t in master. This ticket changed

schedule LeanBSSN_adm2bssn at CCTK_INITIAL after ADMBase_PostInitial
{
  LANG: Fortran
  OPTIONS: Local
  SYNC: gammat
} "Convert initial data into BSSN variables"

schedule GROUP ApplyBCs as LeanBSSN_ApplyBCs at CCTK_INITIAL after LeanBSSN_adm2bssn
{
} "Apply boundary conditions"

to

schedule LeanBSSN_adm2bssn at CCTK_INITIAL after ADMBase_PostInitial
{
  LANG: Fortran
  OPTIONS: Local
} "Convert initial data into BSSN variables"

schedule LeanBSSN_Boundaries at CCTK_INITIAL after LeanBSSN_adm2bssn
{
  LANG: Fortran
  OPTIONS: LEVEL
  SYNC: LeanBSSNMoL::gammat
} "Boundary enforcement"

schedule GROUP ApplyBCs as LeanBSSN_ApplyBCs at CCTK_INITIAL after LeanBSSN_adm2bssn
{
} "Apply boundary conditions"

It looks like this change is in the development branch.

[Samuel Cupp]

So, in answer to the original question, you can try changing the schedule.ccl to what I posted above and see if that resolves the errors or not. I haven’t run with mixed-warning much, so there might be some other cases that could trigger it that I haven’t thought of.

[Miguel Zilhão]

I’ve now merged the master branch with development, so this change should now be present also in master.

[Roland Haas]

Thank you for the fix.

[[e-mail]]

@Miguel Zilhão @Samuel Cupp Thanks for your replies.

Even after using the updated master branch, the issue is still persistent. I even double checked that the changes in schedule.ccl have been made. Is this issue a concern?

I am reopening this ticket.

[[e-mail]]

From latest comment.

The issue is still present even with the suggested fixes, so I am reopening this ticket.

[Samuel Cupp]

Looking more closely at the thorn, I feel its important to point out that it doesn’t have any READ or WRITE declarations. This means that no one has updated it to use the PreSync features. So even if you resolve the boundary warnings, it won’t really benefit you because the READ/WRITE declarations aren’t there yet. I’m sure the maintainers of Lean would be appreciative if you added them. However, if you don’t have the time to add those to the schedule.ccl, then none of the presync_mode settings can actually be used.

I do think I have found the source of the issue, though. The issue is that the PreSync feature isn’t being informed of what the BCs are. The old boundary thorn uses Boundary_SelectGroupForBC to control how BCs are applied, while PreSync depends on the driver function Driver_SelectGroupForBC. At some point, I had suggested that this call be added to the Boundary_SelectGroupForBC as well for the sake of old thorns, but that doesn’t seem to have happened.

I did a pretty ugly edit real quick by duplicating the boundary function calls with driver calls. This runs until it hits an error because PreSync tries to apply boundary conditions on something that isn’t valid in the interior (and nothing is valid anywhere because of paragraph 1).