Comments (6)
It might be worth checking that we're using the ds.coordinates.axis_name
dict wherever we need to; that's a potential source of problems in the selection and pixelization routines. (i.e., assuming that 0 == r, 1 == theta, 2 == phi, rather than using the axis_names
to map)
from yt.
Hi @forrestglines, thank you for reporting. I think this is reasonably decoupled with #4790 so feel free to open a PR with your fix at any point !
from yt.
Hi @forrestglines, thank you for reporting. I think this is reasonably decoupled with #4790 so feel free to open a PR with your fix at any point !
Thanks for the input! This issue with coordinates is the same issue I encountered developing the Parthenon backend. The two data formats (and the AthenaPK code) are extremely similar so I'd like the frontends to behave similarly. I see two options preferable options to fix both:
-
We go with
Geometry.CYLINDRICAL
and changeaxis_order
for both Athena++, as I do in #4801, and for Parthenon as I originally did in #4323 -
We make both Athena++ and Parthenon use
Geometry.POLAR
and we fix #4790.
I'm a bit inclined to go with the first option to keep Athena++ as Geometry.CYLINDRICAL
and have Parthenon match that solution. I'll still help out to debug #4790.
from yt.
It might be worth checking that we're using the
ds.coordinates.axis_name
dict wherever we need to; that's a potential source of problems in the selection and pixelization routines. (i.e., assuming that 0 == r, 1 == theta, 2 == phi, rather than using theaxis_names
to map)
Thanks @matthewturk! This is a suggestion for implementation for the selection and pixelization routines and what's likely causing issues in #4790, right? In this issue I'm having the trouble that yt by default uses r == 0, z == 1, theta == 2 for cylindrical dataset when Athena++ cylindrical datasets are r == 0, theta == 1, z == 2.
Does the fix in #4801 look congruent with yt standards/expectations? It only changes the assumptions about Athena++ cylindrical dataset but hopefully no other assumptions in the code.
from yt.
I see two options to fix both:
I don't think those options should be mutually exclusive: if using Geometry.CYLINDRICAL
works for you and avoids the current bugs with Geometry.POLAR
, that's a reasonable thing to do as a workaround, and we can always switch both frontends to use the more correct solution (POLAR) once known issues are addressed. What do you think ?
from yt.
I don't think those options should be mutually exclusive: if using
Geometry.CYLINDRICAL
works for you and avoids the current bugs withGeometry.POLAR
, that's a reasonable thing to do as a workaround, and we can always switch both frontends to use the more correct solution (POLAR) once known issues are addressed. What do you think ?
I think this is the right solution, this is good enough for both frontends. When the issues with POLAR are addressed we can switch both frontends.
from yt.
Related Issues (20)
- How to change the particle size in function "ParticlePhasePlot" HOT 2
- BUG: Multiple fields break sanitization HOT 2
- BUG: segault on manylinux2014 image HOT 5
- Deprecation warning in GDF (and maybe more?) HOT 3
- Try to project gas particles (SPH) to a mesh with octree structure HOT 2
- ImportError when compiling with gcc 14.1.1 and conda HOT 6
- DOC: docs builds are failing HOT 7
- Incorrect parameter sanitation to np.logspace HOT 2
- CPython 3.13 support (tracker issue)
- Question: How the weight field operates to an yt.create_profile average? HOT 6
- BUG: segfault on macOS (amr64) HOT 11
- Nose testing image comparison: label which image is which? HOT 3
- Editable Installations may be broken in conda environment HOT 7
- BUG: Segfault in smoothing length calculation on Mac HOT 9
- Tipsy Frontend BUG?: oddities with smoothing lengths/positions and bounding box HOT 8
- failing enzo answer tests HOT 6
- CI: test_geo_projection failing on main
- BLD/TST: building fails on `windows-latest` HOT 3
- BLD: can we remove dev-only extra targets ? HOT 3
- DEP: can we drop support for Python 3.9 now ? HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yt.