Sorry I accidentally responded to Micheal only, here’s my response
> Begin forwarded message:
> From: Clément Robert <clement.robert(a)protonmail.com>
> Subject: Re: [yt-dev] Supporting arbitrary grid schemes ?
> Date: 20 October 2021 at 17:04:12 CEST
> To: Michael Zingale <michael.zingale(a)stonybrook.edu>
> Interesting. I think yt already has some support for these, though I admit I’ve never seen it used outside of (failed) image tests, so here’s one I was able to find on my computer.
> Does this fall into the “mapped grid” catagory ?
> Indeed what I want to support in the context of my current team is probably a subset of these “logically rectangular” grids. My teams uses rectilinear grids, but we stil have orthogonality everywhere.
>> On 20 Oct 2021, at 15:41, Michael Zingale <michael.zingale(a)stonybrook.edu> wrote:
>> here's an example of some simple mapped grids that are used in astro:
>> it sounds like what you are describing is a restricted version of a general mapped grid.
>> On Wed, Oct 20, 2021 at 9:31 AM Clément Robert via yt-dev <yt-dev(a)python.org> wrote:
>>> I don’t know ! Where can I find a definition for these ?
>>>> On 20 Oct 2021, at 13:52, Michael Zingale <michael.zingale(a)stonybrook.edu> wrote:
>>>> It's this similar to mapped grids?
>>>> On Wed, Oct 20, 2021, 5:33 AM Clément Robert via yt-dev <yt-dev(a)python.org> wrote:
>>>>> Hi folks
>>>>> As you may be aware, yt’s grid based index classes offer support for patched-based AMR as well octrees, but it’s currently lacking support for so called “stretched gridding scheme”. This is a known limitation in several existing frontends (AMRVAC, BoxLib, Chombo-Pluto are the ones I know of).
>>>>> For context, what I refer to as “stretched grids” are grids where cell sizes are not simple powers of 1/2 (with respect to a unitary reference) as in classic AMR and octrees, but may be specified by arbitrary rules (such as geometric series). Some hydro code support having parts of the grid following classic AMR scheme and other blocks to be “stretched” along one or several directions at once. This is the case of AMRVAC and Pluto, for instance. BoxLib also has support for complex refinement rules that are not covered by storing a single `refine_by` integer as we’re currently doing in Index classes (this is https://github.com/yt-project/yt/issues/3481).
>>>>> It seems to me that the “easy” way of supporting these data formats would be to generalise yt’s mechanisms for reconstructing cell position and size (currently it’s using cell index, domain edges, refinement level + a `refine_by` multiplier) so that cell edges can be stored as arrays that frontends would need to somehow retrieve from datafile or reconstruct from parameter files.
>>>>> There’s been some effort in the past to get over this limitation led by John and Matt, and we’ve been hitting this wall from time to time in discussions.
>>>>> Now, I understand that this would most likely not be a trivial change, especially because we don’t want to break existing frontends in the process (or performance !), and at the moment, I don’t have a very clear idea of what exact steps are needed to achieve this goal, and in particular I don’t have enough material to draft a YTEP on the topic.
>>>>> It seems clear we’d need *some* refactoring/generalisation of Index classes and friend classes and new pixelizer routines would likely be needed. Anything else ?
>>>>> I however have personal motivation to move forward here since my team is developing an hydro code and running simulations where grid streching is the rule rather than the exception.
>>>>> What I would like to do to get us rolling is simply collect the existing issues and PRs related to this goal. I know there are a couple, but it’s very easy to loose track of them, and it’s hard to see the big picture.
>>>>> Can I create a label (“arbitrary grids” ?) and apply it to existing material touching this topic ?
>>>>> Do you know of existing PRs and issues that are relevant to this topic ?
>>>>> Here are the ones I know:
>>>>> - https://github.com/yt-project/yt/issues/3481
>>>>> - https://github.com/yt-project/yt/pull/2998
>>>>> - https://github.com/yt-project/yt/issues/1880
>>>>> - https://github.com/yt-project/yt/issues/385 (from 2012 !!)
>>>>> yt-dev mailing list -- yt-dev(a)python.org
>>>>> To unsubscribe send an email to yt-dev-leave(a)python.org
>>>>> Member address: michael.zingale(a)stonybrook.edu
>>> yt-dev mailing list -- yt-dev(a)python.org
>>> To unsubscribe send an email to yt-dev-leave(a)python.org
>>> Member address: michael.zingale(a)stonybrook.edu
>> Michael Zingale
>> Professor of Physics and Astronomy
>> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800
>> phone: 631-632-8225
>> e-mail: michael.zingale(a)stonybrook.edu
>> web: [https://zingale.github.io](https://zingale.github.io/)
>> github: [https://github.com/zingale](http://github.com/zingale)
Hi yt community!
I just heard about this meeting being held this upcoming May 2022 at the
CCA about open source development practices. I think many of us might be
interested! If so you can sign up to get updates about the meeting.
We are planning a workshop focused on topics in open source software
development practices for astronomy, held in person at the Center for
Computational Astrophysics in New York City, May 16–20, 2022. The program
and scope are still in development, but we expect it to be of interest to
astronomers with a wide range of open source experience, and across all
career stages. The schedule will include a large fraction of unstructured
time for participant-driven discussion, collaboration, and co-working.
For more information about this workshop and to sign up to hear more
details as they become available, please check out our website at
Please share this email with your department lists and/or anyone else who
you think might be interested in participating in this event.
(on behalf of the organizing committee)
Associate Research Scientist, Flatiron Institute
I am self-nominating myself to temporarily move to the fallow fields
for my development and community work in the yt-project. I would like to be
doing more in the project but I am not able to commit to the level I'd like
to, and I'd like to notify the community of my absence. In the interim, I
have asked Kacper (@Xarthisius) to be release manager for the project and
he has agreed.
Happy development everybody. I look forward to positively contributing in
Hello yt-folks !
yt native colormaps now have their own package, already available on PyPI https://pypi.org/project/cmyt/
This has two important implications:
This message is addressed to anyone who installed yt from source and updates their install regularly. If that’s not your case you can jump to the second item
So I’m reaching out to raise awareness about an upcoming change to yt's main branch
You need to install it to keep your local install working after the PR above is merged
You can perform the installation right now if you wish to, you don’t need to wait on the PR to get merged.
python -m pip install cmyt
And you’re done ! Conda-distribution is planned to land soon after the pull request is merged.
you can now use yt’s colormaps with raw matplotlib and outside of yt if you want to. See cmyt’s documentation (one page).