This backports a number of bugfixes in preparation for yt 3.3.2.
I'm particularly appreciate it if @chummels or @brittonsmith could test this out on trident, since there are a number of absorption spectrum or light ray-specific bugfixes.
I just ran the Trident testing suite with this PR and, as far as I can tell, everything functions as intended.
It would be useful if either @chummels or @brittonsmith could also confirm this.
OK, I've looked at this and done a bunch of testing with the stable version of Trident to see if this backport breaks anything. It turns out that the tests run fine in trident, but that's because we don't have answer testing. When I try our "manual answer testing" and compare against the result from using the old stable before these backports, I get a slight difference (only really visible when you toggle back and forth between the images). I used hg bisect to narrow it down to a single changeset, but I'm not entirely sure if the difference I'm seeing is OK.
For reference, here are the steps I followed:
cd$YT_HGhgup-r8752de74f4e3# the old stable tippythonsetup.pydevelopcd$TRIDENThgupv0.5.1cdexamplespythonworking_script.pymvspec_raw.pngspec_raw_good.pngcd$YT_HGhgup784bb3c# the tip from this PRpythonsetup.pydevelopcd$TRIDENT/examplespythonworking_script.pyopenspec_raw.pngspec_raw_good.png
When I do this, you can see a slight difference in the two raw spectra. Basically, the new spectrum is slightly more stretched into the blue on the leftward side, indicating maybe a change in redshift? You can see the images here, but it shows up better if you blink them:
@brittonsmith What do you think? Does this make sense? Do we in fact want to be casting things to comoving coords and we were just doing it incorrectly in the old version?
For reference, the "working_script" we're using in Trident is as follows:
# Example of a currently working script using trident to generate a COS# spectrum from a non-cosmological datasetimportosimporttridentastri# Define the dataset and the coordinates of the start/end of the rayfn='enzo_cosmology_plus/RD0009/RD0009'ray_start=[0,0,0]ray_end=[1,1,1]# Make a LightRay object for the temperature, density, and metallicity# fields of our dataset at redshift_start = redshift_end = 0.0. Include# HI field calculated in simulation to override the Cloudy estimation of HI.# Save LightRay to ray.h5 and use it locally as ray object.ray=tri.make_simple_ray(fn,start_position=ray_start,end_position=ray_end,data_filename='ray.h5',fields=['density','temperature','metallicity','H_p0_number_density'])# Now use the ray object to actually generate an absorption spectrum# Use the settings (spectral range, LSF, and spectral resolution) for COS# And save it as an output hdf5 file and plot it to an image.sg=tri.SpectrumGenerator('COS')sg.make_spectrum(ray)sg.save_spectrum('spec_raw.h5')sg.plot_spectrum('spec_raw.png')# "Final" spectrum with added quasar, MW background, and gaussian noise# (SNR=30)sg.add_qso_spectrum()sg.add_milky_way_foreground()sg.apply_lsf()sg.add_gaussian_noise(30)sg.save_spectrum('spec_final.h5')sg.plot_spectrum('spec_final.png')
@chummels, yes, I believe the change is correct and the previous behavior was wrong. That changeset, which added the following line:
was fixing the bug reported in Issue #1258, wherein the distance calculation was using the wrong unit system. The meat of the fix is not conversion to "Mpccm/h", but using self.cosmology.quan to override the unit system to use the cosmology calculator's unit system.
You can see this by changing the above line in the yt tip to the following:
target_distance=target_distance.to("Mpccm / h")
and you will get the old behavior.
OK, this makes sense. Then I think this PR is good to go with Trident.
Ok, I'm going to backport a few more things, merge this, then make a source distribution.