Opened 7 years ago

Last modified 6 years ago

#931 reopened defect

CartGrid3D's dependency on Boundary

Reported by: Jian Tao Owned by:
Priority: minor Milestone:
Component: Cactus Version: Cactus_4.0.0
Keywords: Cc:


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.

Attachments (0)

Change History (10)

comment:1 Changed 7 years ago by Erik Schnetter

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.

comment:2 Changed 7 years ago by Roland Haas

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.

comment:3 Changed 6 years ago by Frank Löffler

Status: newreview

Should we mark them deprecated in the upcoming Cactus release?

comment:4 Changed 6 years ago by Ian Hinder

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.

comment:5 Changed 6 years ago by Erik Schnetter

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

comment:6 Changed 6 years ago by Frank Löffler

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).

comment:7 Changed 6 years ago by Erik Schnetter

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.

comment:8 Changed 6 years ago by Frank Löffler

Milestone: Cactus_4.1.0Cactus_4.2.0


comment:9 Changed 6 years ago by Erik Schnetter

Status: reviewreopened

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

comment:10 Changed 6 years ago by Frank Löffler

Milestone: Cactus_4.2.0

Modify Ticket

Change Properties
Set your email in Preferences
as reopened The ticket will remain with no owner.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from (none) to the specified user.
The owner will be changed from (none) to anonymous.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.