Comments (4)
To implement this, we could have the Monitor find the "DC level" of a light curve (far from the SN brightening and fading) and subtract it from the light curve (propagating errors appropriately). We could avoid this if sncosmo perfomed fits that included a constant background level - does it?
It does not in the standard implementation
I was suggesting something different actually (simpler or more complicated).
- Do forced photometry at the location at all other times when the SN is not present, and average it to call the flux contribution of the galaxy, with errors.
- Subtract this number from what we are calling the light curve fluxes, as you would if you subtracted two estimators. This will lead to both smaller fluxes for the SN, and higher error bars.
- Do usual light curve fits
This is simpler because you directly estimate the galaxy flux without inferring it from measuring SN + galaxy flux and a model. It is more complicated in that you have to run the DM stack and find times where there are no SN (easy in reality, hard in that run).
As the seeing varies from visit to visit, the amount of galaxy flux brought into the flux measurements will change
Exactly. The flux contribution from the host depends somewhat on the observing conditions. This is why people want to try to model this using scene modeling for things like a final analysis. But this is completely lost in either the correction I suggested, or in the sncosmo fit method you proposed because it also assumes a constant background level.
As I was writing, I also think we can estimate the galaxy contribution (in a way not accessible to observers) by using the galaxy surface brightness and PSF in the relevant visit to calculate the galaxy contribution. (Is this already done in DM as model flux?) It would be a useful thing to have.
Also, I do think that the idea of implementing a fit for SN parameters and zero points simultaneously is u�seful and not too difficult (I even think this was done in some h�ack session but not taken to completion). Since you are in a astrohackweek next week, maybe this could be a project ? :)
from monitor.
Image subtraction or scene modeling are the only ways to do this right. I don't think it's worth spending much effort trying to do this "right" by doing forced photometry on unsubtracted images. In particular if the goal is to do light-curve fits to recover parameters to try to learn how we're doing, I don't think we can learn that much quantitatively useful until we do either scene modeling or image subtraction.
from monitor.
OK: that says that maybe a simple DC level correction like the one Rahul
suggested is all that is needed to make our current ForcedSource light
curves correspond to the current industry standard - or would you say that
the current industry standard is different?
I am all for pursuing image differencing, but we got talking in the meeting
about fallback options, and what DM Level 2 analysis to do. If image
differencing is not enabled until November, there could be something to be
said for trying to do our current DM pipeline processing before then, to
get it set up. What do you think?
On Thu, Aug 25, 2016 at 6:48 PM, Michael Wood-Vasey <
[email protected]> wrote:
Image subtraction or scene modeling are the only ways to do this right. I
don't think it's worth spending much effort trying to do this "right" by
doing forced photometry on unsubtracted images. In particular if the goal
is to do light-curve fits to recover parameters to try to learn how we're
doing, I don't think we can learn that much quantitatively useful until we
do either scene modeling or image subtraction.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#50 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AArY9_fBlFEoroWmWAAZyUoMDovJ40l5ks5qjkXmgaJpZM4JtpYz
.
from monitor.
AFAIK the industry standard for publishing SN photometry is doing SMP (SDSS/SNLS/DES) went that route .... so I agree with @wmwv that doing forced photometry and galaxy subtractions will not be doing it 'right'. At the same time, forced photometry based results have been used before such a finalized version just to get analyses going. I would be very interested in working on a problem like SMP, but I don't know what the word on that is, and one where access to real data at high z might be important.
At the end of the day, we will be using a method which is more 'right' than what I described. So there is a sense in which that work would go to waste. So, it might be better to have me (since I was assigned this) try to push on diff im which will be useful to get going on Twinkles (for example it would be useful to do detections using difference images and comparing with out cheat mode).
from monitor.
Related Issues (20)
- Build Depth and Seeing Curves from PServ data
- Pass Database Connection into lightcurve.build_lightcurve_from_db method
- Simplest Possible Error Model
- Develop monitor functionality to get true fluxes
- Match up an object's true fluxes to observed fluxes
- Develop 2-d bias map in depth, seeing space
- Develop 2-d variance map in depth, seeing space
- Make notebook to demonstrate simple error model
- Use ccdVisit table `skyNoise` to compute DM image depth HOT 1
- Have the Monitor pull out OpSim seeing and depth for each visit
- Figure out Database connections in Jupyter-dev setup HOT 2
- Add higher level info into jupyter-dev documentaion HOT 1
- Issues arising from community discussion of `jupyter-dev` HOT 1
- Remove code that gets lightcurves out of forced photometry folders directly HOT 1
- Science Analysis goals for 2017 SLAC Meeting HOT 2
- Monitor should require the setup of `pserv` and maybe `twinkles`
- Update Jupyter-Dev instructions HOT 3
- Document Use Cases for the Monitor
- Coping without warps HOT 4
- Username and Password for wadawson HOT 1
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 monitor.