Comments (6)
@sbailey In get_targets() you build the wavelength vector thusly:
wavemin = desimodel.io.load_throughput('b').wavemin
wavemax = desimodel.io.load_throughput('z').wavemax
dw = 0.2
wave = np.arange(round(wavemin, 1), wavemax, dw)
I'm unclear about the call to "round()". Don't we either want to use the exact value or, at the very least, make this a floor?
In desisim.templates I do
npix = (maxwave-minwave)/cdelt+1
wave = np.linspace(minwave,maxwave,npix)
which gives a close but not an identical output wavelength array (with maxwave=wavemax, minwave=wavemin, and cdelt=dw, obviously).
Thoughts?
from desisim.
I think my reasoning was that I wanted a 0.2 Angstrom grid aligned to an even tenth of an Angstrom starting point. The exact phase of the grid isn't critical, and I didn't care if I was a fraction of an Angstrom on or off the CCD at the very edge. Your method guarantees that minwave and maxwave are exactly included, but only gives a spacing of cdelt if (maxwave-minwave)/cdelt is an integer (within floating point rounding, which it may not be). I prioritized having a spacing of cdelt, at the expense of missing maxwave by a fraction of a cdelt if (maxwave-minwave)/cdelt isn't an integer. It probably doesn't matter in any practical way for a cdelt of 0.2 over thousands of Angstroms, but I just like to see wavelength grids with human readable number of digits when I'm looking at spectra unless there is a particularly good reason not to.
Note: the wavelength grid of these files is the grid for projecting photons onto the CCD, so it is important for it to be less than a pixel size, and linear rather than log spacing.
from desisim.
In bin/newexp-desi (actually desisim.targets.get_targets) what default redshift and magnitude priors do we want for each object type? This is what I have so far:
QSO: g=[21,23], redshift=[0.5,4]
ELG: r=[21,23.5], redshift=[0.6,1.6]
LRG: z=[19,20.5], redshift=[0.5,1.1]
STAR: r=[18,23.5] (0+/-200 km/s Gaussian radial velocity jitter included by default)
STD: r=[16,19] (0+/-200 km/s Gaussian radial velocity jitter included by default)
These are pretty faint magnitude limits, so the spectra are going to be pretty noisy for many objects. This is a choice, but should I make the defaults go a bit brighter while we're in testing mode so we can get see some glorious successes when we take the simulations through redshift-fitting? These priors are obviously fully customizable.
from desisim.
These are pretty close to the baseline target selection cuts, so let's keep ourselves honest with faint sources. If we really have trouble with them, we'll have to make adjustments to TS and/or exposure times and we might as well learn that now.
Small differences with baseline TS cuts:
LRG z < 20.56 vs. 20.5
ELG r < 23.4 vs. 23.5
QSO cut on r<23 vs. 21 < g < 23
from desisim.
OK, honesty = good. I'm going to keep the default (round) values because when we actually sit down to quantify the redshift success we're going to want push (a bit) fainter than the nominal limits.
I've also added D4000 as a "truth table" output to the ELG and LRG spectral classes, as redshift success will/should correlate with these quantities, especially for LRGs.
from desisim.
Fixed in PR #34, which was merged to master. Closing
from desisim.
Related Issues (20)
- Change default pixel width of DESI mocks to 0.8A HOT 8
- desisim sky level test failure HOT 16
- new problem with how the spectral templates are being normalized HOT 3
- desisim.templates should fail if a template that satisfies the colorcuts cannot be generated HOT 1
- quicktransients should catch failed template generation HOT 1
- Save true continuum in quickquasars
- TestPixsim negative flux failure
- desisim.templates failing with new version of desitarget HOT 2
- Formalize basis_templates tagging procedure HOT 3
- Modify specsim / quickquasars to mimic how the real pipeline estimates the noise variance HOT 1
- "Refraction model is inaccurate for altitudes below 5.0 deg" warning in test_quickquasars unit test HOT 6
- several quickgen unit tests are failing HOT 1
- RuntimeWarning: numpy.ndarray size changed, may indicate binary incompatibility. Expected 80 from C header, got 88 from PyObject
- Test failure at NERSC due to basis template configuration HOT 3
- argument type error in pixsim HOT 2
- desisim.simexp.simulate_spectra not varying exposure time HOT 9
- problem interpolating atmosphere in desisim.specsim.get_simulator HOT 1
- Error while running redrock in mock spectra HOT 1
- Failure on jupyter at nersc trying to run redrock on desisim outputs HOT 2
- io.py find_basis_template does not select most recent template file
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from desisim.