PunctureTracker should not depend on CarpetRegrid2

Create issue
Issue #692 new
Ian Hinder created an issue

The PunctureTracker thorn tracks the locations of punctures in BH simulations and puts them into spherical surfaces. It also seems to have logic which interacts with CarpetRegrid2 to control the mesh refinement. This degree of coupling is not good - what if you wanted to use a different regridding thorn, or a different driver? What if you wanted to do a unigrid simulation?

Keyword: PunctureTracker

Comments (8)

  1. Erik Schnetter
    • removed comment

    You can use CarpetTracker to read the location of a spherical surface and steer CarpetRegrid2 with this information.

  2. Ian Hinder reporter
    • removed comment

    That is what PunctureTracker does (after I modified it a while ago). But it also steers the number of levels directly, which is something that cannot be communicated in a spherical surface. This is an unusual usage pattern, but presumably someone used it at one point. I would prefer that this sort of thing was handled by something other than PunctureTracker - e.g. a thorn which noticed that two spherical surfaces were close to each other (for example) and changed the number of levels that way.

  3. Erik Schnetter
    • removed comment

    I suggest to move this code into CarpetTracker. CarpetTracker moves the regions; I don't see why it shouldn't also activate/deactivate/modify them.

  4. Frank Löffler
    • removed comment

    Then CarpetTracker would need to know how many levels to add to which of its centers when the distance between these two gets closer than a certain value. CarpetTracker can track more than two centers, and we should find a mechanism which is that general. We could define a set of new_levels for each tracked surface, and one parameter for a distance. If any combination of valid surfaces is closer than this distance, these centers would change the number of their levels. The algorithm for that is N^2, but for up to 10 levels that should be ok, especially given that we rarely use that many anyway.

    Btw: would it be better to specify the absolute number of levels here, or the relative number of levels to refine _in addition_ to what it would otherwise have?

  5. Erik Schnetter
    • removed comment

    I think we should stay as close as possible to what PunctureTracker does, unless we get input from PunctureTracker users.

  6. Ian Hinder reporter
    • removed comment

    Speaking for PunctureTracker users at the AEI, we do not use anything beyond the current interface between PT and CT. I suspect the only people who might use anything more would be Christian and Denis. It would be very nice to have a mechanism which triggered certain events when two spherical surfaces got close to each other. The immediate application for me would be to reduce the number of refinement levels as I think is possible with PT, and to set a flag which triggered run termination a certain coordinate time later. The former could be handled by CarpetTracker, but the latter would be handled by something else.

  7. Erik Schnetter
    • removed comment

    Since the current mechanism works fine, and since we are mostly discussing additional features here (and not just moving code to another thorn), I think this should be marked "enhancement", not "defect". It also seems this should be discussed on the mailing list to get more input.

  8. Ian Hinder reporter
    • removed comment

    I think of it as a defect that I cannot use PunctureTracker in a unigrid simulation without activating CarpetRegrid2 (which is what I was trying to do). We can leave it as it is until we "enhance" some other mechanism to provide the same functionality, but I would leave this defect ticket open until the underlying issue is fixed. Let's discuss on the mailing list as you say.

  9. Log in to comment