PunctureTracker should not depend on CarpetRegrid2

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.

   • 2011-12-05T14:24:59+00:00
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.

   • 2011-12-05T14:41:02+00:00
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.

   • 2011-12-11T18:57:19+00:00
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?

   • 2011-12-11T23:17:11+00:00
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.

   • 2011-12-12T08:23:36+00:00
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.

   • 2011-12-12T08:28:57+00:00
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.

   • 2011-12-12T08:32:20+00:00
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.

   • 2011-12-12T09:27:53+00:00
9. Log in to comment