[yt-dev] Re: Creating an Unstructured mesh for a new frontend

Others with more unstructured mesh experience may weigh in, but do the explanations and examples in load_unstructured_mesh’s docstrings help? https://yt-project.org/doc/reference/api/yt.frontends.stream.data_structures... I would also try looking through the instructured mesh literature for e.g. the term “element connectivity” On Thu, Jun 27, 2019 at 5:30 PM Ronan Hix wrote:

Hi all,

Thanks for the clarification. I took a look at the Exodus II frontend and got the Unstructured Mesh up and running (though I ended up having to define the fwidth selector before it would graph). However, given that Exodus II reads in the “connectivity” variable rather than calculating it, I’m at a bit of a loss how to incorporate it using Chimera data. To start, I used the method for calculating it I had previously drawn from the Athena++/SemiStructured Mesh frontend, which yielded the same issue as was present when using that mesh format. (That being that the data on the graph is bizarrely overlapped and quite striated). The fact that this issue persisted across the changing of the Mesh base class leads me to believe that the source is in the definition of the connectivity.

I looked through the documentation for any information regarding exactly what this variable does, but I was unable to find anything. My supposition based on the dimensions yt seems to expect (Number of grid cells, 8) and the general format, is that the integer values presented here represent mesh vertices, and each row represents which 8 vertices bound each grid cell. If this is indeed the case, I was hoping that someone might be familiar with the expected format, and might be able to clarify exactly how my connectivity variable ought to snake across the grid, etc. If my attempt to decipher the purpose of connectivity is flawed, hopefully someone could correct my understanding.

Thanks

-Ronan Hix

On Jun 26, 2019, at 4:37 PM, Nathan wrote:

I don't think those functions are actually used by anything? The Exodus-II frontend uses a trivial subclass of the UnstructuredMesh class and doesn't have implementations of those functions. It may just be those are stubs that the original author thought might be needed but it turned out they weren't actually necessary.

To answer your questions, fcoords and icoords means float coordinates and integer coordinates. For AMR codes it makes sense to go back and forth between floating point coordinates (e.g. between 0 and 1 scaled to the domain width) and integer coordinates (e.g. at level n, we are m zones at level n's resolution away from the edge of the domain). fwidth is the width of a zone in floating point coordinates. ires is the resolution in integer coordinates. The tcoords are another analogous coordinate system used specifically for the ray data object (t is scaled from 0 to 1 along the ray), for now you can probably ignore it.

The select_* functions are used by the Cython selection machinery to ask various questions about the coordinates or geometry of data. select_fcoords ultimately gets called when someone asks for the coordinates of mesh elements. select_fwidth when someone asks for cell widths, etc.

Those concepts aren't terribly useful for unstrucutered mesh data, which might explain why those functions are stubs - they don't actually get called for unstructured mesh data.

The best person to ask about this stuff is probably either Andrew Myers (at LBL) or Matt Turk (at UIUC). Both don't have a ton of time to work on yt stuff anymore and may not necessarily see this thread for a little while.

I would suggest testing using some of the Exodus II sample data, seeing how the Exodus II frontend works, and then making your frontend work similarly. If you see places where there should be refactorings then it might make sense to do that. Right now the Exodus II frontend is pretty much the only consumer of this machinery so there are probably places where things either need to be moved into or away from the base class.

On Wed, Jun 26, 2019 at 4:26 PM Ronan Hix wrote:

...

Hi all,

I spoke with some of the Chimera devs and as it turns out, the yin-yang ends up being written as a pair of grids which are both also logically cartesian, simplifying the task.

Furthermore, I’ve been moving further through the Unstructured Mesh writing, and have reached the point where several functions only raise “NotImplementedErrors.” I take it that these functions within the base class must be superseded within in the ChimeraMesh class; however, I was wondering what each of these actually define, as their respective entries within the documentation are blank. They are “select_fwidth”,” select_icoords”,”select_ires”, and ”select_tcoords”.

Thanks -Ronan Hix

On Jun 26, 2019, at 11:46 AM, Ronan Hix wrote:

Hey,

At the moment the objective is using yt with the C series of Chimera models, which are logically cartesian. Later runs use the yin-yang grid, but structuring the reader to use that date is a later endeavor.

-Ronan Hix

On Jun 26, 2019, at 11:25 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:

Ronan, is it still logically Cartesian? or is this with the yin yang mesh in Chimera?

On Wed, Jun 26, 2019 at 11:18 AM Ronan Hix wrote:

...

Hello all,

I’ve been in contact with Dr. ZuHone for the last few weeks about my efforts to create a new yt frontend for Chimera data, and he directed me here for further assistance.

Chimera is a unigrid dataset with spherical polar coordinates and a nonlinear r-axis scaling; as a result, it needs a custom mesh rather than the AMR grids or SemiStructured meshes present in some of the existing frontends. The Chimera datafiles all contain arrays which detail the edge positions of the gridblocks, so creating an array of grid-edge coordinates is fairly trivial. Theoretically, I would expect the transfer of this coordinate array into a yt mesh object would be fairly straightforward, but I don’t have enough familiarity with the functionality of the Unstructured Mesh class to do so without some guidance. I was hoping that someone here might be able to shed some light on what the contents of this class do and how it functions as a whole, such that I can create one for Chimera.

Many thanks, -Ronan Hix _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org

-- Michael Zingale Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale

_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org

_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org

_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org

_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org