- removed comment
CartGrid3D's dependency on Boundary
Issue #931
wontfix
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.
Keyword:
Comments (12)
-
-
- 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.
-
- changed status to open
- removed comment
Should we mark them deprecated in the upcoming Cactus release?
-
- 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.
-
- 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.
-
- 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).
-
- 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.
-
- changed milestone to Cactus_4.2.0
- removed comment
Agreed.
-
- changed status to open
- removed comment
There is no patch to review here; this ticket only contains a discussion.
-
- removed milestone
- removed comment
-
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_SelectedGVsfrom thorn Boundary is used in only those scheduled functions which only run ifBoundaryis on. SimilarlySymmetryRegisterandSymmetryRegisterGridare in groupSymmetryRegisterscheduled 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.
-
- edited description
- changed status to wontfix
Works as intended.
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- wontfix
- Component
- Cactus
- Milestone
- –
- Version
- Cactus_4.0.0
- Votes
- 0
- Watchers
- 0
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.