- changed status to new
No boundary conditions registered for variables in group LEANBSSNMOL
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
Comments (11)
-
-
-
assigned issue to
@helvi witek @Miguel Zilhão could you take a look, please? You are listed as LeanBSSNMoL maintainers (according to the README file).
-
assigned issue to
-
Can you check if this issue is also present in the current development branch of
LeanBSSNMoL
? -
I’ve never used this thorn, but I can hazard a guess. On the master branch, the function
LeanBSSN_Boundaries
doesn’t run untilschedule 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 changedschedule 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.
-
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.
-
I’ve now merged the master branch with development, so this change should now be present also in master.
-
- changed status to resolved
-
Thank you for the fix.
-
reporter @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.
-
reporter - changed status to open
From latest comment.
The issue is still present even with the suggested fixes, so I am reopening this ticket.
-
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 functionDriver_SelectGroupForBC
. At some point, I had suggested that this call be added to theBoundary_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).
- Log in to comment