Redshift for Grackle UVB in non-cosmological simulations

#334 Merged at 8815c06
Repository
aemerick
Branch
week-of-code
Repository
enzo
Branch
week-of-code
Author
  1. Andrew Emerick
Reviewers
Description

enable user selection of redshift for computing UV background when using Grackle UVB in non-cosmological simulations. Makes use of already existing and documented parameter "RadiationFieldRedshift"

Includes ability to select negative redshift for both Grackle and normal Enzo UVB methods

Comments (9)

  1. Andrew Emerick author

    Hey everyone. I was trying to get another (separate) pull request going and screwed up the bookmarking again. It is now included here. I've fixed things on my local machine but I think in attempts to do this I've screwed up my repo which is why its still showing the changes here.

    I'm a little frustrated with bitbucket automatically applying new commits at the moment,. Unfortunately I won't be able to fix this until tomorrow.

    1. Nathan Goldbaum

      Try this:

      $ hg update 24783b0
      $ hg backout 24783b0
      $ hg push -r . https://bitbucket.org/aemerick/enzo-dev/
      

      To fix the other PR, do:

      $ hg update 7763cb3
      $ hg backout -r dec2bb9::7763cb3
      $ hg push -r . https://bitbucket.org/aemerick/enzo-dev/
      

      The output of "hg log -G" can be very helpful for resolving issues like this. Keep in mind that a pull request corresponds to a single head in the changeset graph.

      You might also want to turn on the pager extension if you don't have that turned on already, otherwise just pipe the output of log to less.

      You had trouble with these pull requests because you were updating to the "wrong" commit, and then commiting on top of that. In the output of "hg log -G", you can see which commit you are standing on by looking for the "@" symbol in the graph.

      1. Nathan Goldbaum

        Finally, if you want to use 24783b0, you should move it to a different place in the changeset graph by updating to wherever you want to apply the change and then using the "graft" command. See "hg help graft" for details.

        1. Andrew Emerick author

          Thanks Nathan that fixed everything on the pull request end.

          In the future, how should I go about making changes? Should I always make a new head (with a bookmark?), do my changes there and then submit the pull request on the new head? Would this avoid the crossovers I was having in trying to do multiple PR's?

          In doing this, is it possible to have a head that contains all of the distinct changes from the other bookmarked heads without having the same pull request issues I was having?

          (we can move this conversation somewhere else if that is more appropriate)

          1. Nathan Goldbaum

            In the future, how should I go about making changes? Should I always make a new head (with a bookmark?), do my changes there and then submit the pull request on the new head? Would this avoid the crossovers I was having in trying to do multiple PR's?

            Yes, that's right

            In doing this, is it possible to have a head that contains all of the distinct changes from the other bookmarked heads without having the same pull request issues I was having?

            Yes. There are a number of ways to do this. I usually use hg rebase to copy a changeset series from one place in history to another. That requires being careful, since it's possible to delete work this way. Unfortunately the simplest workflow - merging your bugfix changes to somewhere else in history where you are working on your "real" projects - won't work because as soon as you push your work to your fork, the pull request will be updated because your change is no longer a topological head.

            One way to handle that I'd recommend for you is to maintain two forks - one from which you make pull requests to the main enzo repository, and another that you push work-in-progress commits to.

            1. Andrew Emerick author

              Thanks. And just to make sure I've got it now, if (for example) I need to make changes to this PR I should switch to this head using

              $ hg update 6035
              $ hg commit -m 'some changes'
              $ hg push https//bitbucket.org/aemerick/enzo-dev
              

              And lastly, once these changes in the PR are accepted and I wanted to merge this head with the tip, would I do:

              $ hg update tip_changeset_number
              $ hg merge changeset_number_from_this_head
              
              1. Nathan Goldbaum

                I usually use the hashes rather than the local revision numbers since the hashes will be consistent across repositories.

                Once these changes are merged in, you don't need to keep track of which head has the changes, since they're merged into the "main" development head on the enzo-dev repo. Here's what I usually do:

                $ hg update my-main-project
                $ hg pull https://bitbucket.org/enzo/enzo-dev
                $ hg merge $(hg id -r week-of-code https://bitbucket.org/enzo/enzo-dev)
                

                The $(hg id -r week-of-code https://bitbucket.org/enzo/enzo-dev) bit uses a subshell to find the revision that is the head of the week-of-code branch on the main enzo repository.

  2. Brian O'Shea

    Hi @aemerick , I will test the updated PR today (as well as your other PR). Sorry for the delay - I've been at two back-to-back conferences.

    1. Brian O'Shea

      Followup: this passes the test suite at changeset 1045e2a . Three people have approved it; I will also approve and then merge.