BUG: Set the display name for new fields

[chummels]

PR Summary

This PR addresses Issue #3269. If a new derived field has not defined a display_name (used for rendering in figures) at creation time, this generates it at the end of initialization. This probably has little impact on most fields being generated, but this will ensure that species fields (e.g., H_p0 = H I) are rendering correctly in both PhasePlots and ProfilePlots instead of just in ProjectionPlots and SlicePlots. Example (see z_label):

[chummels]

It looks like I broke a bunch of answer tests with this change. The main failing culprits are PhasePlot objects from grid-based datasets that have a mass weighting (now showing Cell Mass as z_label). I think what's happening is that when a new field is created, like ('Enzo', 'cell_mass'), it is now getting a display_name created for that field: Cell Mass. And then there is an alias field of ('gas', 'mass') that aliases back to ('Enzo', 'cell_mass'), it inherits its display_name. Which means that even when a PhasePlot uses ('gas', 'mass') as its weight field, it's displaying the display_name for the original field: Cell Mass. I'll have to rethink how to beat this problem.

[neutrinoceros]

think what's happening is that when a new field is created, like ('Enzo', 'cell_mass'), it is now getting a display_name created for that field: Cell Mass. And then there is an alias field of ('gas', 'mass') that aliases back to ('Enzo', 'cell_mass'), it inherits its display_name

sounds about right. I'd argue that inheriting the display name is actually what we want, and "Cell Mass" makes more sense than "Mass" as a label, in my opinion. Unless I'm missing an argument here, I think the answers should actually be updated.

[jzuhone]

I'd argue that inheriting the display name is actually what we want, and "Cell Mass" makes more sense than "Mass" as a label, in my opinion.

In general what we want to do is avoid referencing the underlying data structures (cell or particle) and focus on the physical quantities so as to make scripts as portable as possible across different frontends. In most use cases there's no reason why a user shouldn't be able to take a script written for Gadget and use it for Enzo, etc. or vice-versa.

[neutrinoceros]

Ah right, this is a good reason. I'm guessing we currently don't support aliases with alternate reprs (display names)?

[matthewturk]

I thought we did? In the field tuples there's the option for that.

…

On Thu, May 20, 2021 at 8:08 AM Clément Robert ***@***.***> wrote: Ah right, this is a good reason. I'm guessing we currently don't support aliases with alternate reprs (display names)? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[chummels]

I agree with @jzuhone that we don't want cell_mass in the PhasePlot zlabel when it comes from a ('gas', 'mass') field, even when that is aliased in some cases to ('FRONTEND', 'cell_mass').

Any ideas anyone has on where I could appropriately set the display_name to avoid this problem? The way it works with ProjectionPlot and SlicePlot is in FixedResolutionBuffer right when the plot is being generated. But I'm not sure where to make that happen for ProfilePlots and PhasePlots--I guess they don't rely on an FRB for those plots.

[matthewturk]

Kinda seems like this would be a pretty big change at this point in the game?

…

On Sat, May 22, 2021 at 7:25 PM Cameron Hummels ***@***.***> wrote: I agree with @jzuhone <https://github.com/jzuhone> that we don't want cell_mass in the PhasePlot zlabel when it comes from a ('gas', 'mass') field, even when that is aliased in some cases to ('FRONTEND', 'cell_mass'). Any ideas anyone has on where I could appropriately set the display_name to avoid this problem? The way it works with ProjectionPlot and SlicePlot is in FixedResolutionBuffer right when the plot is being generated. But I'm not sure where to make that happen for ProfilePlots and PhasePlots--I guess they don't rely on an FRB for those plots. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3282 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVXOYWMJK7HO3LOXHDV2LTPBDODANCNFSM45FZM75Q> .

[jzuhone]

@matthewturk can you elaborate a bit?

[matthewturk]

I guess just thinking about changing "Cell Mass" in the z label of plots to something different struck me as a big change.

…

On Sat, May 22, 2021 at 8:13 PM John ZuHone ***@***.***> wrote: @matthewturk can you elaborate a bit? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[jzuhone]

If you're plotting the cell_mass field from the frontend, it should say "Cell Mass", but otherwise it should just say "Mass", IMO.

[chummels]

I guess just thinking about changing "Cell Mass" in the z label of plots to something different struck me as a big change.

I think there's some confusion here, potentially because of the long string of comments, so I'll try to summarize. The existing behavior in yt for a PhasePlot weighted by the ('gas', 'mass') field is to (correctly) created a z_label of mass.
This PR is trying to correct a problem associated with species fields showing up as H p0 mass instead of H I mass as the z_label in PhasePlots. The solution that I submitted fixes the species problem, but breaks the current paradigm of displaying z_labels for a mass field that is aliased to a grid-based frontend: it should display mass, but it's displaying cell_mass instead because its inheriting the display_name when it aliases the field. I'm looking to change my current PR implementation to preserve the correct behavior of displaying mass as instead of cell_mass, which is how yt already does things. This can be seen in the failed answer tests.

So PhasePlot/ProfilePlot doesn't create an FRB. I guess I can just try to set the label in those functions directly.

[chummels]

So I rewrote this to set the display_field in ProfilePlot and PhasePlot directly, using the same machinery that is in the FRB class that works for ProjectionPlot and SlicePlot. As I was doing so, I realized that the parentheses around the label units in PhasePlots are wonky, so I fixed them. Those led to the failing answer tests. I would argue that these failures are all desired. Here is a representative image difference of one of the failures:

If people are OK with this solution, I will make some tests and update the answer tests.

[cphyc]

Same here

[chummels]

Good call, @cphyc . I think the code is now stable against any fields that might have frac in them.

So this should be ready to go, I think. In short, it corrects the problem described in Issue #3269. It also corrects some issues with parentheses in field units displayed in PhasePlot (the parentheses were too small to cover fractional units like g/cm**3). See the image above in the comments. I guess I need to generate new answer tests for this?

[neutrinoceros]

@chummels your latest change is causing image comparison tests to fail, but the change is actually desirable !
reference

your patch

so you actually fixed bad latex here, thank you !
Now you're going to need to open a PR on the answer store to bump these answers, but note that your change is impacting the same answers as the one bumped here yt-project/answer-store#23 , so I'd suggest we deal with that PR (and #3520) first and then come back to this PR to include your change. How does this sound ?

edit: neglected to read the conversation history before adding this comment. So of course your change is 100% intentional and that's great. Sorry for suggesting it was a happy incident.

[chummels]

Sure that sounds fine. We can get all these label issues fixed one at a time.

[neutrinoceros]

#3520 is in. Now we need to bump the answer store for this PR. Let's run the answer tests again to get an up to date result we can submit to the answer store

[neutrinoceros]

@chummels be aware that matplotlib 3.5 is around the corner (https://github.com/matplotlib/matplotlib/milestone/59) and may cause perturbations with the answer store, so I'd suggest to either expedite this PR (with a companion PR to the answer store) or hold it until after matplotlib 3.5 is released. Let me know if you need a hand, the process still takes a little amount of human overhead :)

[chummels]

I'm happy either way, whichever is easiest. I'm happy to make a companion PR to the answer store, but I'm not sure how to do this. I'd love your assistance with it since you offered.

[neutrinoceros]

Alright so here are the steps:

1. go the the relevant job's log (https://github.com/yt-project/yt/runs/3838740844?check_suite_focus=true)
2. at the bottom of the page, unroll the "report failed answers" section

3. at the bottom top that section, you'll find two links, the first own downloads a visual html report of your changes for reference, and the second one downloads a zip archive.

4. Get that zip
5. fork the answer store repo https://github.com/yt-project/answer-store
6. clone your fork locally (keeping a separate copy from your main yt clone will make things much easier in case anything breaks later)
7. checkout the yt-4.0 branch
8. create a new branch from there (for instance support_3282)
9. now unzip the archived from step 4 from the top level of the repo
10. commit
11. push your branch
12. open a PR

Admittedly this is hard to guess, but I think you have everything you need here. Don't hesitate to reach out in case something isn't clear.
After the companion PR is merged, we'll also need to update the submodule here.

[neutrinoceros]

Ah, answer tests failed again. Apparently we needed to rebase this branch ahead of regenerating images for it to take into account the changes from #3520 . I rebased the branch here and produced a new companion PR for the answer store yt-project/answer-store#25

[matthewturk]

@meeseeksdev backport to yt-4.0.x

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout yt-4.0.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 6a79163e9cffa73cd2c878f2d1ff9d8f3eb135f3

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #3282: BUG: Set the display name for new fields'

4. Push to a named branch :

git push YOURFORK yt-4.0.x:auto-backport-of-pr-3282-on-yt-4.0.x

5. Create a PR against branch yt-4.0.x, I would have named this PR:

"Backport PR #3282 on branch yt-4.0.x (BUG: Set the display name for new fields)"

And apply the correct labels and milestones.

Congratulation you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove Still Needs Manual Backport label once the PR gets merged.

If these instruction are inaccurate, feel free to suggest an improvement.

[neutrinoceros]

Let's try this one last time now that a lot of other PRs went in. If it fails we'll resort to manual backport
@meeseeksdev backport to yt-4.0.x