{"action":"created","issue":{"url":"https://api.github.com/repos/GalSim-developers/GalSim/issues/798","repository_url":"https://api.github.com/repos/GalSim-developers/GalSim","labels_url":"https://api.github.com/repos/GalSim-developers/GalSim/issues/798/labels{/name}","comments_url":"https://api.github.com/repos/GalSim-developers/GalSim/issues/798/comments","events_url":"https://api.github.com/repos/GalSim-developers/GalSim/issues/798/events","html_url":"https://github.com/GalSim-developers/GalSim/pull/798","id":175898380,"number":798,"title":"#789 Chromatic Normalization","user":{"login":"jmeyers314","id":3650485,"avatar_url":"https://avatars.githubusercontent.com/u/3650485?v=3","gravatar_id":"","url":"https://api.github.com/users/jmeyers314","html_url":"https://github.com/jmeyers314","followers_url":"https://api.github.com/users/jmeyers314/followers","following_url":"https://api.github.com/users/jmeyers314/following{/other_user}","gists_url":"https://api.github.com/users/jmeyers314/gists{/gist_id}","starred_url":"https://api.github.com/users/jmeyers314/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jmeyers314/subscriptions","organizations_url":"https://api.github.com/users/jmeyers314/orgs","repos_url":"https://api.github.com/users/jmeyers314/repos","events_url":"https://api.github.com/users/jmeyers314/events{/privacy}","received_events_url":"https://api.github.com/users/jmeyers314/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2016-09-09T00:30:45Z","updated_at":"2016-09-10T00:18:40Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/GalSim-developers/GalSim/pulls/798","html_url":"https://github.com/GalSim-developers/GalSim/pull/798","diff_url":"https://github.com/GalSim-developers/GalSim/pull/798.diff","patch_url":"https://github.com/GalSim-developers/GalSim/pull/798.patch"},"body":"This PR implements a number of changes in the way that chromatic objects and SEDs are used, especially the way they’re normalized.  Previously, SEDs had dimensions of [photons / wavelength-interval], which is a joint property of the astronomical object of interest, the projected telescope collecting area, and the exposure time used to generate an image.  This made it particularly cumbersome to investigate what a particular object might look like through two different telescopes, or with two different exposure times.  The new SED dimensions are [photons / wavelength-interval / area / time], which is independent of the telescope and exposure time.  \r\n\r\nTo set the area and exposure time, new keyword arguments have been added to drawImage: `area=1., exptime=1.`.  The default values of 1 cm^2 and 1 sec ensure that the change in SED normalization is mostly transparent to users who were not attempting to draw chromatic (or achromatic) objects with particular telescopes or exposure times.  \r\n\r\nAdding the exptime and area to drawImage also implies that these be removed from the bandpass zeropoint, where they previously lived.  The new bandpass zeropoint is equal to the magnitude at which the flux of a standard spectrum (could be Vega, AB, or something else) through the bandpass is 1 photon / cm^2 / sec.  (Note that this is a bit different than, say, [HST zeropoints](http://www.stsci.edu/hst/acs/analysis/zeropoints) which I believe are at least approximately the magnitude at which the flux through the bandpass and with collecting area equal to the HST primary mirror area is 1 photon / sec).\r\n\r\nWhile changing the dimensionality of SEDs and associated ChromaticObjects, I noticed a few things that didn’t make sense dimensionally, such as the product of two SED objects was another SED object.  These kinds of dimensional issues are now tracked and exceptions generated when appropriate.\r\n\r\nThe trickiest new development is that there are effectively now two types of ChromaticObjects: those that are associated with an SED (and hence represent an object with dimensions of [photons / wavelength-interval / area / time / solid-angle]) and those that still have a normalization, but aren’t associated with an SED (i.e., dimensions are just [1 / solid-angle])  Generally speaking, the former correspond to stars or galaxies, and the latter to PSFs.  Along with this distinction are a new set of rules for what types of manipulations between SED’d and non-SED’d ChromaticObjects are possible.  For instance:\r\n- only SED’d chromatic objects can be drawn.  Calling .drawImage(bandpass) on a non-SED’d ChromaticObject will raise an exception.\r\n- at most one SED’d chromatic object can be part of a ChromaticConvolution.\r\n- SED’d ChromaticObjects can be added together, as well as non-SED’d ChromaticObjects, but you can’t add an SED’d ChromaticObject to a non-SED’d ChromaticObject.\r\n- multiplying a non-SED’d ChromaticObject by an SED results in an SED’d ChromaticObject (as a consequence of this, you no longer need to create a delta-fn GSObject to make a chromatic image of a star.  You can simply multiply the chromatic PSF by the SED of the star and draw that.)\r\n\r\nThis refactor let me deprecate one method and one class: \r\n- `ChromaticObject.__init__()`, which was only useful before as an intermediate step when applying a chromatic transformation to a GSObject: `chrom_obj = galsim.ChromaticObject(gs_obj).dilate(lambda w:w)`.  Now you can just directly apply the chromatic transformation to the GSObject: `chrom_obj = gs_obj.dilate(lambda w:w)`.  The `ChromaticObject` class still exists though as an abstract base class.\r\n- `galsim.Chromatic`.  Multiplying a GSObject by an SED now just creates a `ChromaticTransformation` that’s functionally equivalent to the old `Chromatic` class.\r\n\r\nFinally, the normalization of ChromaticObjects that aren't attached to an SED is done via lambdas, which means that fewer things are pickable than previously.  I'm not sure if this merits more attention or not.\r\n\r\nOverall, I'm pretty happy with the end results of this refactor, though I'm not sure that the implementation is as clean as it could be.  Comments appreciated."},"comment":{"url":"https://api.github.com/repos/GalSim-developers/GalSim/issues/comments/246073659","html_url":"https://github.com/GalSim-developers/GalSim/pull/798#issuecomment-246073659","issue_url":"https://api.github.com/repos/GalSim-developers/GalSim/issues/798","id":246073659,"user":{"login":"rmjarvis","id":623887,"avatar_url":"https://avatars.githubusercontent.com/u/623887?v=3","gravatar_id":"","url":"https://api.github.com/users/rmjarvis","html_url":"https://github.com/rmjarvis","followers_url":"https://api.github.com/users/rmjarvis/followers","following_url":"https://api.github.com/users/rmjarvis/following{/other_user}","gists_url":"https://api.github.com/users/rmjarvis/gists{/gist_id}","starred_url":"https://api.github.com/users/rmjarvis/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rmjarvis/subscriptions","organizations_url":"https://api.github.com/users/rmjarvis/orgs","repos_url":"https://api.github.com/users/rmjarvis/repos","events_url":"https://api.github.com/users/rmjarvis/events{/privacy}","received_events_url":"https://api.github.com/users/rmjarvis/received_events","type":"User","site_admin":false},"created_at":"2016-09-10T00:18:40Z","updated_at":"2016-09-10T00:18:40Z","body":"> What's a FluxDensityObject?\r\n\r\nThat was my joking reference to the hard-to-name base class for a chromatic object with an SED.  I don't have a particularly good idea for a name for it."}}
{"actor":{"display_login":"rmjarvis"}}