How to compute quantities along a fieldline #719
Assignees
Labels
hackathon
Stuff to work on during hackathon
Comments
|
Source grid, eval grid, single one for each computeable, by default are the same (so i.e call compute twice if want things on same src but different eval grids, one in normal coords other in SFL along field line) |
|
utilities covering common cases i.e. rtz -> raz and having routine to map back on field period etc. |
|
also related: #1006 (comment) |
rahulgaur104
added a commit
that referenced
this issue
Jul 20, 2024
Resolves #719, resolves #692, resolves #664, resolves #904, resolves #1077. Needed to compute neoclassical stuff. Ready for review Can look at the Gamma_c branch to see how these changes are used. - According to jax, `jnp.take(x, idx, unique_indices=True)` is more efficient than `x[idx]`, so this PR makes this change in the `grid.compress()` method. (The `bounce` branch needs `jnp.take` for different reasons, which is the actual motivation for adding `jnp.take` and its numpy equivalent to `desc.backend`. ) - Adds an optional resolution requirement string to the register compute function decorator to resolve 664. - Adds stuff to use `eq.compute` method for things whose compute functions assume the input data is evaluated along a field line. - Changes some grid attributes (backwards-compatible) for the grids to work better in different coordinate systems. - Fixes a bug on `LinearGrid` with `grid.num_zeta = 1` and `grid.NFP!=1` if used for a surface integral (surface averages or others such as surface_integral(x) / surface_integral(y) were unaffected since the bug would net a constant factor difference).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There have been several applications recently that need data from the equilibrium evaluated along a fieldline (stability stuff from @rahulgaur104 , GX stuff from @pkim1818, gamma_c from @JaxCrocker)
Right now this isn't super easy to do so we have some hacky stuff for it, but it would be good to decide on a common API for this.
One possibility:
Gridlabelling what coordinates its using,rtzfor regular DESC computational coordinates,razfor rho, alpha, zeta etc.desc.compute.computewe check the grid type and do any coordinate mapping to computational coordinates there.Issues:
desc.compute.computecurrently expects pre-built transforms and profiles. If we're doing grid mapping inside that function we would need to add an option to just pass in the grid and build transforms from that and the equilibriumAny other thoughts? @ddudt @dpanici @unalmis
The text was updated successfully, but these errors were encountered: