CartGrid3D's dependency on Boundary

Create issue
Issue #931 wontfix
Jian Tao created an issue

CartGrid3D_ApplyBC in CartGrid3D is scheduled in BoundaryConditions, which is defined in the Boundary thorn.

I can see that this is related with the symmetric boundary conditions but could we handle it in boundary ?

It seems to me that it is not a good idea to have the grid thorn depend on the boundary thorn. While making boundary depending on grid is more reasonable if we have to introduce the dependency between these two thorns.


Comments (12)

  1. Erik Schnetter
    • removed comment

    Since CartGrid3D implements a boundary condition, it needs to depend on thorn Boundary. The issue is that CartGrid3D does two things, provide coordinates and provide symmetry conditions. We could, in the long term, remove or split out the symmetry conditions from thorn CartGrid3D, but this may require changes in many other thorns and parameter files.

  2. Roland Haas
    • removed comment

    The CartGrid3D boundaries are deprecated anyway aren't they? So once they eventually go away for good the problem should not occur anymore. So I would not worry about separating them out.

  3. Ian Hinder
    • removed comment

    What would be the consequences of this? We still want to support PUGH; can PUGH be used with the newer symmetry thorns? Maybe as an exercise, we should switch some of the test cases to using the new symmetry thorns instead of the CartGrid3D symmetries. We will have to do this anyway if we eventually remove the CartGrid3D symmetries.

  4. Erik Schnetter
    • removed comment

    Deprecating is an action to be taken right after a release, not right before. This gives developers and power users time to react.

  5. Frank Löffler
    • removed comment

    Deprecating wouldn't mean to change anything in the code. It just means to announce that it will probably be not supported for very long anymore. This is what gives developers and users the time to react. Not announcing it now and sticking to the plan to first have an announcement within a release before in the next release a feature is removed would mean to have the deprecation notice next year and the removal in 2014 (thinking in Cactus release cycles).

  6. Erik Schnetter
    • removed comment

    Deprecation means that we have documentation and examples for an alternative, and that we have tested that this works. I would argue that this implies that we converted our test cases.

    I don't think deprecating CartGrid3D symmetries is urgent, as they work just fine in the cases where they are used, and we don't spend time maintaining this code either.

    If there is only a single Cactus release per year, then a two-year time-span is not very long. 2014 is then practically already around the corner. With a slow-moving code base like this, waiting until 2014 isn't bad.

  7. Erik Schnetter
    • changed status to open
    • removed comment

    There is no patch to review here; this ticket only contains a discussion.

  8. Roland Haas

    I don’t think there is anything actually to do here. CartGrid3D scheduling its ApplyBCs routine in Boundary’s group becomes a no-op of thorn Boundary is not running (as intended). It does not introduce a dependency, between the two (at least for “old” uses of CartGrid3D that did not use Boundary before that thorn came into existence). The aliased function Boundary_SelectedGVs from thorn Boundary is used in only those scheduled functions which only run if Boundary is on. Similarly SymmetryRegister and SymmetryRegisterGrid are in group SymmetryRegister scheduled by SymBase (which also provides those functions).

    So, I do not actually see any dependency and would content that the thorn is fine as is.

  9. Log in to comment