Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do intrinsic_vector and extrinsic_vector belong in Operators? #3718

Open
glwagner opened this issue Aug 19, 2024 · 8 comments
Open

Do intrinsic_vector and extrinsic_vector belong in Operators? #3718

glwagner opened this issue Aug 19, 2024 · 8 comments
Labels
cleanup 🧹 Paying off technical debt

Comments

@glwagner
Copy link
Member

Originally, "operators" were regarded as difference, derivative, and reconstruction operators (eg the atomic operators required for finite volume arithmetic and calculus). Here we also have vector rotations:

@inline intrinsic_vector(i, j, k, grid::AbstractGrid, uₑ, vₑ, wₑ) =

I had expected to find these in Grids. So just wanted to have this discussion.

@glwagner glwagner added the cleanup 🧹 Paying off technical debt label Aug 19, 2024
@navidcy
Copy link
Collaborator

navidcy commented Aug 24, 2024

I think you are right.

Perhaps the thinking was that these apply an "operation" to the vector quantities (rotating etc where appropriate). But even so, indeed I think it's a different sort of operation and they are grid-specific so probably fit in the Grids module better.

@glwagner
Copy link
Member Author

What do you think @simone-silvestri

@simone-silvestri
Copy link
Collaborator

Hmmm, as a first impression, to me, they belong in the operators module because they are operators that enact a pointwise operation (vector rotation) on fields (like the other operators). However, they are probably more entangled with the concept of domain and grid than the other operators, so they might be ok to be in the grid module also.

@glwagner
Copy link
Member Author

I think the question is not whether they are "an operator" (as in the dictionary definition of "operator") but rather whether they are similar to the other functions defined in that module

@simone-silvestri
Copy link
Collaborator

Having these functions in the operator module is what makes more sense to me. My logic for this opinion is that these functions are much more similar in structure and objective to the other operators rather than any function of the grid module which typically only require the grid itself as an input.
However, I am ok also to switch them in the grids module because I recognize that a rotation happens relative to a particular grid.

@glwagner
Copy link
Member Author

glwagner commented Aug 26, 2024

We do have to mention the notion of the extrinsic and intrinsic coordinate system in the grids module though yes?

My concern is that we don't want a lot of distance between the definition of the grid, and the definition of its extrinsic and intrinsic coordinate system. If the Operators module were deleted, the grids mostly still stand alone (you just can't use them as easily). I feel like if that happened I would still want to know what the coordinate system of the grid was, even if I couldn't do calculus on it.

@simone-silvestri
Copy link
Collaborator

Agreed, we definitely have to mention it in the grids module.
Maybe we can come up with some abstraction like ExtrinsicCoordinateSystem(grid) that is used in the operators module to rotate the vectors.

@glwagner
Copy link
Member Author

In the case that these operators serve to define the coordinate systems (which they do now), I think they have to belong in the Grids module because they are part of the definition of each grid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup 🧹 Paying off technical debt
Projects
None yet
Development

No branches or pull requests

3 participants