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

Implement UGRID default start_index #4214

Open
pp-mo opened this issue Jun 30, 2021 · 4 comments
Open

Implement UGRID default start_index #4214

pp-mo opened this issue Jun 30, 2021 · 4 comments

Comments

@pp-mo
Copy link
Member

pp-mo commented Jun 30, 2021

✨ Feature Request

In the UGRID conventions, the 'start_index' property is never actually required,
e.g. in this section

For the indexing one may use either 0- or 1-based indexing; the convention used should be specified using a start_index attribute to the index variable (i.e. Mesh2_face_nodes in the example below). Consistent with the CF-conventions compression option, the connectivity indices are 0-based by default. See this section on zero or one-based indexing for more details.

But in our current code, we have assumed it is always there

Notable specifically for connectivities,
might possibly apply elsewhere, but at present I think not : probably just in this one place ?

@trexfeathers
Copy link
Contributor

This should I think be fine to implement - the Connectivity class always has a start_index attribute, but defaults to =0 in line with the UGRID conventions.

@pp-mo
Copy link
Member Author

pp-mo commented Jul 5, 2021

fine to implement

Absolutely, logically it is all fine, we must just stop assuming that a file variable always has a start_index attribute.

So, I think this PR should be all that's needed

@github-actions
Copy link
Contributor

In order to maintain a backlog of relevant issues, we automatically label them as stale after 500 days of inactivity.

If this issue is still important to you, then please comment on this issue and the stale label will be removed.

Otherwise this issue will be automatically closed in 28 days time.

@github-actions github-actions bot added the Stale A stale issue/pull-request label Oct 29, 2023
Copy link
Contributor

This stale issue has been automatically closed due to a lack of community activity.

If you still care about this issue, then please either:

  • Re-open this issue, if you have sufficient permissions, or
  • Add a comment stating that this is still relevant and someone will re-open it on your behalf.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 26, 2023
@bjlittle bjlittle added Feature: UGRID and removed Stale A stale issue/pull-request labels Nov 29, 2023
@bjlittle bjlittle reopened this Nov 29, 2023
@scitools-ci scitools-ci bot removed this from 🚴 Peloton Dec 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants