Fwd: Supporting arbitrary grid schemes ?
Sorry I accidentally responded to Micheal only, here’s my response
Begin forwarded message:
From: Clément Robert <clement.robert@protonmail.com> Subject: Re: [yt-dev] Supporting arbitrary grid schemes ?
Date: 20 October 2021 at 17:04:12 CEST To: Michael Zingale <michael.zingale@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@stonybrook.edu> wrote:
here's an example of some simple mapped grids that are used in astro:
http://faculty.washington.edu/rjl/pubs/circles/SIR000723.pdf
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@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@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@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 !!)
Thanks Clément _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@stonybrook.edu
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu web: [https://zingale.github.io](https://zingale.github.io/) github: [https://github.com/zingale](http://github.com/zingale)
I don't think that's a mapped grid -- mapped grids are logically Cartesian, so you should be able to index any location with (i,j) -- this seems to have different connectivities. On Wed, Oct 20, 2021 at 11:06 AM Clément Robert via yt-dev < yt-dev@python.org> wrote:
Sorry I accidentally responded to Micheal only, here’s my response
Begin forwarded message:
*From: *Clément Robert <clement.robert@protonmail.com> *Subject: **Re: [yt-dev] Supporting arbitrary grid schemes ?* *Date: *20 October 2021 at 17:04:12 CEST *To: *Michael Zingale <michael.zingale@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@stonybrook.edu> wrote:
here's an example of some simple mapped grids that are used in astro:
http://faculty.washington.edu/rjl/pubs/circles/SIR000723.pdf
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@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@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@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 !!)
Thanks Clément _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@stonybrook.edu
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu *web*: https://zingale.github.io github: https://github.com/zingale <http://github.com/zingale>
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu *web*: https://zingale.github.io github: https://github.com/zingale <http://github.com/zingale>
You’re right. Then I suppose it’d be an additional effort to support non-orthogonal mapped grids, but adding support within the restricted case of orthogonal mapped grids is probably the first step in that direction anyway, and it seems like a good description of what I have in mind.
On 20 Oct 2021, at 17:23, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
I don't think that's a mapped grid -- mapped grids are logically Cartesian, so you should be able to index any location with (i,j) -- this seems to have different connectivities.
On Wed, Oct 20, 2021 at 11:06 AM Clément Robert via yt-dev <yt-dev@python.org> wrote:
Sorry I accidentally responded to Micheal only, here’s my response
Begin forwarded message:
From: Clément Robert <clement.robert@protonmail.com> Subject: Re: [yt-dev] Supporting arbitrary grid schemes ?
Date: 20 October 2021 at 17:04:12 CEST To: Michael Zingale <michael.zingale@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 ?
<Screenshot 2021-10-20 at 16.58.20.png>
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@stonybrook.edu> wrote:
here's an example of some simple mapped grids that are used in astro:
http://faculty.washington.edu/rjl/pubs/circles/SIR000723.pdf
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@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@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@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 !!) > > Thanks > Clément > _______________________________________________ > yt-dev mailing list -- yt-dev@python.org > To unsubscribe send an email to yt-dev-leave@python.org > https://mail.python.org/mailman3/lists/yt-dev.python.org/ > Member address: michael.zingale@stonybrook.edu
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu web: [https://zingale.github.io](https://zingale.github.io/) github: [https://github.com/zingale](http://github.com/zingale)
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu web: [https://zingale.github.io](https://zingale.github.io/) github: [https://github.com/zingale](http://github.com/zingale)
yes, agreed! On Wed, Oct 20, 2021 at 11:37 AM Clément Robert < clement.robert@protonmail.com> wrote:
You’re right. Then I suppose it’d be an additional effort to support non-orthogonal mapped grids, but adding support within the restricted case of orthogonal mapped grids is probably the first step in that direction anyway, and it seems like a good description of what I have in mind.
On 20 Oct 2021, at 17:23, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
I don't think that's a mapped grid -- mapped grids are logically Cartesian, so you should be able to index any location with (i,j) -- this seems to have different connectivities.
On Wed, Oct 20, 2021 at 11:06 AM Clément Robert via yt-dev < yt-dev@python.org> wrote:
Sorry I accidentally responded to Micheal only, here’s my response
Begin forwarded message:
*From: *Clément Robert <clement.robert@protonmail.com> *Subject: **Re: [yt-dev] Supporting arbitrary grid schemes ?* *Date: *20 October 2021 at 17:04:12 CEST *To: *Michael Zingale <michael.zingale@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 ?
<Screenshot 2021-10-20 at 16.58.20.png>
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@stonybrook.edu> wrote:
here's an example of some simple mapped grids that are used in astro:
http://faculty.washington.edu/rjl/pubs/circles/SIR000723.pdf
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@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@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@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 !!)
Thanks Clément _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@stonybrook.edu
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu *web*: https://zingale.github.io github: https://github.com/zingale <http://github.com/zingale>
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu *web*: https://zingale.github.io github: https://github.com/zingale <http://github.com/zingale>
-- 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@stonybrook.edu *web*: https://zingale.github.io github: https://github.com/zingale <http://github.com/zingale>
It sounds like an interesting idea, but I fear it may be a bunch of work to generalize the existing grid methods to work for stretched grids. But if there's a will, there's a way! I think the key point here is to be careful in not breaking existing functionality with respect to the existing grid-based frontends, so perhaps making sure all the tests are set on those before modifying anything? One small note is that I would recommend *against* making a github label of "arbitrary grids" for this, as we already have an arbitrary grid object that is different from what you're describing. See: https://yt-project.org/docs/dev/analyzing/objects.html#arbitrary-grid . Perhaps "stretched grids" is more appropriate? Non-powers-of-two grids? I dunno. Cameron On Wed, Oct 20, 2021 at 8:38 AM Michael Zingale < michael.zingale@stonybrook.edu> wrote:
yes, agreed!
On Wed, Oct 20, 2021 at 11:37 AM Clément Robert < clement.robert@protonmail.com> wrote:
You’re right. Then I suppose it’d be an additional effort to support non-orthogonal mapped grids, but adding support within the restricted case of orthogonal mapped grids is probably the first step in that direction anyway, and it seems like a good description of what I have in mind.
On 20 Oct 2021, at 17:23, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
I don't think that's a mapped grid -- mapped grids are logically Cartesian, so you should be able to index any location with (i,j) -- this seems to have different connectivities.
On Wed, Oct 20, 2021 at 11:06 AM Clément Robert via yt-dev < yt-dev@python.org> wrote:
Sorry I accidentally responded to Micheal only, here’s my response
Begin forwarded message:
*From: *Clément Robert <clement.robert@protonmail.com> *Subject: **Re: [yt-dev] Supporting arbitrary grid schemes ?* *Date: *20 October 2021 at 17:04:12 CEST *To: *Michael Zingale <michael.zingale@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 ?
<Screenshot 2021-10-20 at 16.58.20.png>
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@stonybrook.edu> wrote:
here's an example of some simple mapped grids that are used in astro:
http://faculty.washington.edu/rjl/pubs/circles/SIR000723.pdf
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@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@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@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 !!)
Thanks Clément _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@stonybrook.edu
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu *web*: https://zingale.github.io github: https://github.com/zingale <http://github.com/zingale>
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu *web*: https://zingale.github.io github: https://github.com/zingale <http://github.com/zingale>
-- 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@stonybrook.edu *web*: https://zingale.github.io github: https://github.com/zingale <http://github.com/zingale>
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: chummels@gmail.com
-- Cameron Hummels Computational Astrophysicist California Institute of Technology http://chummels.org
Good call ! “Strecthed grid” would work as a label, as far as I’m concerned. And yes, not breaking anything is an absolute priority here, and I would like to avoid having to modify existing frontends in any major way. That said, I -maybe naively- believe we have enough tests already that we would detect breaking changes. Perfomance regression are a possibility and it needs to be carefully addressed too.
On 20 Oct 2021, at 21:12, Cameron Hummels <chummels@gmail.com> wrote:
It sounds like an interesting idea, but I fear it may be a bunch of work to generalize the existing grid methods to work for stretched grids. But if there's a will, there's a way! I think the key point here is to be careful in not breaking existing functionality with respect to the existing grid-based frontends, so perhaps making sure all the tests are set on those before modifying anything?
One small note is that I would recommend *against* making a github label of "arbitrary grids" for this, as we already have an arbitrary grid object that is different from what you're describing. See: https://yt-project.org/docs/dev/analyzing/objects.html#arbitrary-grid . Perhaps "stretched grids" is more appropriate? Non-powers-of-two grids? I dunno.
Cameron
On Wed, Oct 20, 2021 at 8:38 AM Michael Zingale <michael.zingale@stonybrook.edu> wrote:
yes, agreed!
On Wed, Oct 20, 2021 at 11:37 AM Clément Robert <clement.robert@protonmail.com> wrote:
You’re right. Then I suppose it’d be an additional effort to support non-orthogonal mapped grids, but adding support within the restricted case of orthogonal mapped grids is probably the first step in that direction anyway, and it seems like a good description of what I have in mind.
On 20 Oct 2021, at 17:23, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
I don't think that's a mapped grid -- mapped grids are logically Cartesian, so you should be able to index any location with (i,j) -- this seems to have different connectivities.
On Wed, Oct 20, 2021 at 11:06 AM Clément Robert via yt-dev <yt-dev@python.org> wrote:
Sorry I accidentally responded to Micheal only, here’s my response
Begin forwarded message:
From: Clément Robert <clement.robert@protonmail.com> Subject: Re: [yt-dev] Supporting arbitrary grid schemes ?
Date: 20 October 2021 at 17:04:12 CEST To: Michael Zingale <michael.zingale@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 ?
<Screenshot 2021-10-20 at 16.58.20.png>
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@stonybrook.edu> wrote: > > here's an example of some simple mapped grids that are used in astro: > > http://faculty.washington.edu/rjl/pubs/circles/SIR000723.pdf > > 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@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@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@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 !!) >>>> >>>> Thanks >>>> Clément >>>> _______________________________________________ >>>> yt-dev mailing list -- yt-dev@python.org >>>> To unsubscribe send an email to yt-dev-leave@python.org >>>> https://mail.python.org/mailman3/lists/yt-dev.python.org/ >>>> Member address: michael.zingale@stonybrook.edu >> >> _______________________________________________ >> yt-dev mailing list -- yt-dev@python.org >> To unsubscribe send an email to yt-dev-leave@python.org >> https://mail.python.org/mailman3/lists/yt-dev.python.org/ >> Member address: michael.zingale@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@stonybrook.edu > web: [https://zingale.github.io](https://zingale.github.io/) > github: [https://github.com/zingale](http://github.com/zingale)
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu web: [https://zingale.github.io](https://zingale.github.io/) github: [https://github.com/zingale](http://github.com/zingale)
--
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@stonybrook.edu web: [https://zingale.github.io](https://zingale.github.io/) github: [https://github.com/zingale](http://github.com/zingale)
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: chummels@gmail.com
--
Cameron Hummels Computational Astrophysicist California Institute of Technology
I’ve created the “stretched grids” label, thanks for your feedback ! Have a nice day Clément
On 20 Oct 2021, at 23:52, Clément Robert <clement.robert@protonmail.com> wrote:
Good call ! “Strecthed grid” would work as a label, as far as I’m concerned. And yes, not breaking anything is an absolute priority here, and I would like to avoid having to modify existing frontends in any major way. That said, I -maybe naively- believe we have enough tests already that we would detect breaking changes. Perfomance regression are a possibility and it needs to be carefully addressed too.
On 20 Oct 2021, at 21:12, Cameron Hummels <chummels@gmail.com> wrote:
It sounds like an interesting idea, but I fear it may be a bunch of work to generalize the existing grid methods to work for stretched grids. But if there's a will, there's a way! I think the key point here is to be careful in not breaking existing functionality with respect to the existing grid-based frontends, so perhaps making sure all the tests are set on those before modifying anything?
One small note is that I would recommend *against* making a github label of "arbitrary grids" for this, as we already have an arbitrary grid object that is different from what you're describing. See: https://yt-project.org/docs/dev/analyzing/objects.html#arbitrary-grid . Perhaps "stretched grids" is more appropriate? Non-powers-of-two grids? I dunno.
Cameron
On Wed, Oct 20, 2021 at 8:38 AM Michael Zingale <michael.zingale@stonybrook.edu> wrote:
yes, agreed!
On Wed, Oct 20, 2021 at 11:37 AM Clément Robert <clement.robert@protonmail.com> wrote:
You’re right. Then I suppose it’d be an additional effort to support non-orthogonal mapped grids, but adding support within the restricted case of orthogonal mapped grids is probably the first step in that direction anyway, and it seems like a good description of what I have in mind.
On 20 Oct 2021, at 17:23, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
I don't think that's a mapped grid -- mapped grids are logically Cartesian, so you should be able to index any location with (i,j) -- this seems to have different connectivities.
On Wed, Oct 20, 2021 at 11:06 AM Clément Robert via yt-dev <yt-dev@python.org> wrote:
Sorry I accidentally responded to Micheal only, here’s my response
> Begin forwarded message: > > From: Clément Robert <clement.robert@protonmail.com> > Subject: Re: [yt-dev] Supporting arbitrary grid schemes ? > > Date: 20 October 2021 at 17:04:12 CEST > To: Michael Zingale <michael.zingale@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 ? > > <Screenshot 2021-10-20 at 16.58.20.png> > > 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@stonybrook.edu> wrote: >> >> here's an example of some simple mapped grids that are used in astro: >> >> http://faculty.washington.edu/rjl/pubs/circles/SIR000723.pdf >> >> 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@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@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@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 !!) >>>>> >>>>> Thanks >>>>> Clément >>>>> _______________________________________________ >>>>> yt-dev mailing list -- yt-dev@python.org >>>>> To unsubscribe send an email to yt-dev-leave@python.org >>>>> https://mail.python.org/mailman3/lists/yt-dev.python.org/ >>>>> Member address: michael.zingale@stonybrook.edu >>> >>> _______________________________________________ >>> yt-dev mailing list -- yt-dev@python.org >>> To unsubscribe send an email to yt-dev-leave@python.org >>> https://mail.python.org/mailman3/lists/yt-dev.python.org/ >>> Member address: michael.zingale@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@stonybrook.edu >> web: [https://zingale.github.io](https://zingale.github.io/) >> github: [https://github.com/zingale](http://github.com/zingale)
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu web: [https://zingale.github.io](https://zingale.github.io/) github: [https://github.com/zingale](http://github.com/zingale)
--
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@stonybrook.edu web: [https://zingale.github.io](https://zingale.github.io/) github: [https://github.com/zingale](http://github.com/zingale)
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: chummels@gmail.com
--
Cameron Hummels Computational Astrophysicist California Institute of Technology
Hi folks, I've been thinking about this a bit lately and I'm going to put them into multiple issues. Here's the first: https://github.com/yt-project/yt/issues/3694 I didn't see the label though... On Fri, Oct 22, 2021 at 3:28 AM Clément Robert via yt-dev <yt-dev@python.org> wrote:
I’ve created the “stretched grids” label, thanks for your feedback ! Have a nice day Clément
On 20 Oct 2021, at 23:52, Clément Robert <clement.robert@protonmail.com> wrote:
Good call ! “Strecthed grid” would work as a label, as far as I’m concerned. And yes, not breaking anything is an absolute priority here, and I would like to avoid having to modify existing frontends in any major way. That said, I -maybe naively- believe we have enough tests already that we would detect breaking changes. Perfomance regression are a possibility and it needs to be carefully addressed too.
On 20 Oct 2021, at 21:12, Cameron Hummels <chummels@gmail.com> wrote:
It sounds like an interesting idea, but I fear it may be a bunch of work to generalize the existing grid methods to work for stretched grids. But if there's a will, there's a way! I think the key point here is to be careful in not breaking existing functionality with respect to the existing grid-based frontends, so perhaps making sure all the tests are set on those before modifying anything?
One small note is that I would recommend *against* making a github label of "arbitrary grids" for this, as we already have an arbitrary grid object that is different from what you're describing. See: https://yt-project.org/docs/dev/analyzing/objects.html#arbitrary-grid . Perhaps "stretched grids" is more appropriate? Non-powers-of-two grids? I dunno.
Cameron
On Wed, Oct 20, 2021 at 8:38 AM Michael Zingale <michael.zingale@stonybrook.edu> wrote:
yes, agreed!
On Wed, Oct 20, 2021 at 11:37 AM Clément Robert <clement.robert@protonmail.com> wrote:
You’re right. Then I suppose it’d be an additional effort to support non-orthogonal mapped grids, but adding support within the restricted case of orthogonal mapped grids is probably the first step in that direction anyway, and it seems like a good description of what I have in mind.
On 20 Oct 2021, at 17:23, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
I don't think that's a mapped grid -- mapped grids are logically Cartesian, so you should be able to index any location with (i,j) -- this seems to have different connectivities.
On Wed, Oct 20, 2021 at 11:06 AM Clément Robert via yt-dev <yt-dev@python.org> wrote:
Sorry I accidentally responded to Micheal only, here’s my response
Begin forwarded message:
From: Clément Robert <clement.robert@protonmail.com> Subject: Re: [yt-dev] Supporting arbitrary grid schemes ? Date: 20 October 2021 at 17:04:12 CEST To: Michael Zingale <michael.zingale@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 ?
<Screenshot 2021-10-20 at 16.58.20.png>
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@stonybrook.edu> wrote:
here's an example of some simple mapped grids that are used in astro:
http://faculty.washington.edu/rjl/pubs/circles/SIR000723.pdf
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@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@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@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 !!)
Thanks Clément _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@stonybrook.edu
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu web: https://zingale.github.io github: https://github.com/zingale
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: michael.zingale@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@stonybrook.edu web: https://zingale.github.io github: https://github.com/zingale
-- 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@stonybrook.edu web: https://zingale.github.io github: https://github.com/zingale
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: chummels@gmail.com
-- Cameron Hummels Computational Astrophysicist California Institute of Technology http://chummels.org
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: matthewturk@gmail.com
participants (4)
-
Cameron Hummels -
Clément Robert -
Matthew Turk -
Michael Zingale