issue_comments

Table actions

3 rows where issue = 1206634329 and user = 35968931 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

  • TomNicholas · 3 ✖

issue 1

  • boundary conditions for differentiate() · 3 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1102803306 https://github.com/pydata/xarray/issues/6493#issuecomment-1102803306 https://api.github.com/repos/pydata/xarray/issues/6493 IC_kwDOAMm_X85Bu3Fq TomNicholas 35968931 2022-04-19T15:39:07Z 2022-04-19T15:39:07Z MEMBER

On the xarray side, I think we should just recommend composing pad with diff or differentiate.

This is essentially just what we're doing in xGCM.

We'll need to add a "extrapolate" option for the padded coordinate variables for this to work.

We also ran into this, and would use it if there were an extrapolate option for xarray's pad.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   boundary conditions for differentiate() 1206634329
1102801329 https://github.com/pydata/xarray/issues/6493#issuecomment-1102801329 https://api.github.com/repos/pydata/xarray/issues/6493 IC_kwDOAMm_X85Bu2mx TomNicholas 35968931 2022-04-19T15:37:11Z 2022-04-19T15:37:11Z MEMBER

I am still worried about the metrics concept introduced by xgcm. I think this should be discussed over xgcm's repo.

Please do raise an issue there!

We don't need stagged grid point and metrics, as in xgcm, but centered difference (a[i+1]-a[i-1]) will be good enough for A grid.

The new "grid ufuncs" functionality in xGCM (hopefully being released this week) allows you to write grid-aware functions that can do centered operations exactly like this. e.g. see here

https://github.com/xgcm/xgcm/blob/cb7feccb9e4331e71da6f034cbee13f43c3de76d/xgcm/test/test_grid_ufunc.py#L614

This is simpler and do not make heavy dependence of the third-party package like xgcm.

I do sympathise with this though.

But some designs in xgcm also inspire me to make things much natural.

If you tell us exactly what it is you're trying to do then there might be a neat solution.

cc @jbusecke 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   boundary conditions for differentiate() 1206634329
1101480251 https://github.com/pydata/xarray/issues/6493#issuecomment-1101480251 https://api.github.com/repos/pydata/xarray/issues/6493 IC_kwDOAMm_X85Bp0E7 TomNicholas 35968931 2022-04-18T15:07:10Z 2022-04-18T15:07:10Z MEMBER

@miniufo have you seen xGCM? Your problem might be more easily solved using that library instead.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   boundary conditions for differentiate() 1206634329

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);