Incorrect vector components in curvilinear coordinate systems
Hi all, I'd like to point out a pull request I just made, which fixes a number of fields that have been returning incorrect data. In particular, the definitions of the fields `velocity_spherical_theta`, `velocity_spherical_phi`, and `velocity_cylindrical_theta` have not been correct for at least three years, possibly longer - I haven't checked to see if they were ever correct. Here's a pull request that implements a fix and adds some new tests: https://github.com/yt-project/yt/pull/1687 While it's nice that we know there's an issue now and that it's fixed, this means that if someone was making a profile of the tangential velocity around a star, or the poloidal magnetic field in a disk simulation, or a circular velocity in a galaxy simulation, yt may have silently returned incorrect results. I'm raising this issue here because it feels like it might be a big deal. Should this concern be raised more loudly to our users? I'm hesitant to do so, mostly out of sheepishness. Is this as big a deal as I'm making it out to be? Thanks, Nathan
I don't know how often these features get used, but I would vote to not make this a big deal. I would say include it in the list of bugfixes in the next point release, but it may not necessitate an email to the whole list about the issue. Notably, I ran into similar issue last week during some analysis with the cylindrical coordinate system, but I tested it first to see if it made sense. I anticipate that other users would do the same thing instead of just assuming its all correct, but maybe I'm wrong? I've been meaning to make a bug report on the cylindrical dataset, but maybe your PR has corrected the issues I encountered. Thanks for your and Philipp's work to correct these issues! Cameron On Thu, Feb 8, 2018 at 12:09 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
I suspect that any user who is doing analysis right now using these fields might want to know right now about this bug so that they can apply the fix immediately if they so desire before they publish something on them. In fact, my student is working on a project using these very fields and I just told him that we’ll need to do that very thing—apply this fix and he’ll have to re-run stuff (not a big deal). So for that reason we should email yt-users. It’s embarrassing but let’s be honest—we’re not perfect, and even if some people are cranky with us I think that it’s good practice to be very open about these things because I think our users would appreciate it.
Maybe the thing to do is merge my PR, backport it to stable, do a bugfix release, and make a big deal about this issue in the release notes. We're overdue for a bugfix release anyway and doing a release will make it easier for our users to get the fix, rather than applying it themselves or installing yt from source. -Nathan On Thu, Feb 8, 2018 at 2:25 PM, John Zuhone <jzuhone@gmail.com> wrote:
Agreed. Thanks, everyone! On Thu, Feb 8, 2018 at 1:01 PM, John Zuhone <jzuhone@gmail.com> wrote:
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
What do you think of addressing this problem together with the bulk field parameter issue (https://github.com/yt-project/yt/issues/1686)? Otherwise some fields (such as the velocity field) might yield inconsistent results (Cartesian magnitude != magnitude based on a spherical decomposition) for datasets with the bulk field parameter set. If it is decided not to be fixed and backported now, I would at least argue to update the documentation and add a line to the release notes about the (underlying/implicit) differences. Philipp On 02/08/2018 04:03 PM, Cameron Hummels wrote:
I've gone ahead and issued a PR for the field parameter issue: https://github.com/yt-project/yt/pull/1693 It ended up being a bit more complicated than I'm comfortable with including in a bugfix release, but once that PR is merged we can at least sort out issues on master before we do yt 3.5. Would you be OK with that Philipp? On Thu, Feb 8, 2018 at 3:49 PM, Philipp Grete <grete@pa.msu.edu> wrote:
I don't know how often these features get used, but I would vote to not make this a big deal. I would say include it in the list of bugfixes in the next point release, but it may not necessitate an email to the whole list about the issue. Notably, I ran into similar issue last week during some analysis with the cylindrical coordinate system, but I tested it first to see if it made sense. I anticipate that other users would do the same thing instead of just assuming its all correct, but maybe I'm wrong? I've been meaning to make a bug report on the cylindrical dataset, but maybe your PR has corrected the issues I encountered. Thanks for your and Philipp's work to correct these issues! Cameron On Thu, Feb 8, 2018 at 12:09 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
I suspect that any user who is doing analysis right now using these fields might want to know right now about this bug so that they can apply the fix immediately if they so desire before they publish something on them. In fact, my student is working on a project using these very fields and I just told him that we’ll need to do that very thing—apply this fix and he’ll have to re-run stuff (not a big deal). So for that reason we should email yt-users. It’s embarrassing but let’s be honest—we’re not perfect, and even if some people are cranky with us I think that it’s good practice to be very open about these things because I think our users would appreciate it.
Maybe the thing to do is merge my PR, backport it to stable, do a bugfix release, and make a big deal about this issue in the release notes. We're overdue for a bugfix release anyway and doing a release will make it easier for our users to get the fix, rather than applying it themselves or installing yt from source. -Nathan On Thu, Feb 8, 2018 at 2:25 PM, John Zuhone <jzuhone@gmail.com> wrote:
Agreed. Thanks, everyone! On Thu, Feb 8, 2018 at 1:01 PM, John Zuhone <jzuhone@gmail.com> wrote:
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
What do you think of addressing this problem together with the bulk field parameter issue (https://github.com/yt-project/yt/issues/1686)? Otherwise some fields (such as the velocity field) might yield inconsistent results (Cartesian magnitude != magnitude based on a spherical decomposition) for datasets with the bulk field parameter set. If it is decided not to be fixed and backported now, I would at least argue to update the documentation and add a line to the release notes about the (underlying/implicit) differences. Philipp On 02/08/2018 04:03 PM, Cameron Hummels wrote:
I've gone ahead and issued a PR for the field parameter issue: https://github.com/yt-project/yt/pull/1693 It ended up being a bit more complicated than I'm comfortable with including in a bugfix release, but once that PR is merged we can at least sort out issues on master before we do yt 3.5. Would you be OK with that Philipp? On Thu, Feb 8, 2018 at 3:49 PM, Philipp Grete <grete@pa.msu.edu> wrote:
participants (4)
-
Cameron Hummels -
John Zuhone -
Nathan Goldbaum -
Philipp Grete