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

[gdf] dimensionality doesn't imply which dimension is reduced #3630

Merged
merged 1 commit into from
Oct 31, 2021

Conversation

Xarthisius
Copy link
Member

Root cause that I was hitting this is that b"piernik" != "piernik"... However, I came to a conclusion that this clause is wrong for any GDF output, not just that one particular flavor. GDF already implies that RE/LE is a 3-element array, so there's no point in making assumptions about 1) which dimension is reduced or 2) what the value of dds in that dimension should be.

Using script from #3629:

import yt

ds = yt.load("crwind_tst_0001.h5")
slc = yt.SlicePlot(ds, "x", "density")
slc.save("zy.png")

ds.coordinates.x_axis["x"] = 2
ds.coordinates.x_axis[0] = 2
ds.coordinates.y_axis["x"] = 1
ds.coordinates.y_axis[0] = 1
slc = yt.SlicePlot(ds, "x", "density")
slc.save("yz.png")

now I get:

yz
zy

@Xarthisius Xarthisius added bug code frontends Things related to specific frontends labels Oct 31, 2021
@neutrinoceros
Copy link
Member

neutrinoceros commented Oct 31, 2021

Well played !

Notes on the output graph:

  • the axis labels are not changed
  • the aspect of the figure varies widely, I suspect this is because the figure width is hardcoded (and the aspect ratio is always 1 by default)

These are points I'd like addressed along with the original issue you were pointing out: there's a demand for supporting this operation but the current solution is a little hacky as well as undocumented.

I'm writing this note on my phone mostly so I can open an issue from it later. I'm not asking for changes to the present PR.
I'll make an actual review in a couple hours.

Copy link
Member

@neutrinoceros neutrinoceros left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I did a little research on the data format and all I could find so far was a repo of yours
https://github.com/Xarthisius/fgdfio
which gives out a link to the format spec, which is unfortunately broken
https://bitbucket.org/yt_analysis/grid_data_format/

I confirm I can reproduce the error and that the patch fixes it, so I could just merge this, but out of curiosity, do you have any resource on this data format that I could refer to ?

@Xarthisius
Copy link
Member Author

I confirm I can reproduce the error and that the patch fixes it, so I could just merge this, but out of curiosity, do you have any resource on this data format that I could refer to ?

https://github.com/yt-project/grid_data_format

@neutrinoceros neutrinoceros merged commit 59892ab into yt-project:main Oct 31, 2021
@Xarthisius Xarthisius deleted the gdf_dimensionality branch October 31, 2021 14:21
@neutrinoceros
Copy link
Member

@meeseeksdev backport to yt-4.0.x

meeseeksmachine pushed a commit to meeseeksmachine/yt that referenced this pull request Nov 6, 2021
matthewturk added a commit that referenced this pull request Nov 10, 2021
…0-on-yt-4.0.x

Backport PR #3630 on branch yt-4.0.x ([gdf] dimensionality doesn't imply which dimension is reduced)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug code frontends Things related to specific frontends
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[GDF] Grids cell width is wrongly set to 1.0 for inappropriate dimension for 2D datasets.
2 participants