[CLOSED] Add new properties in the sampledb Nsa ModelClasses

[albireox]

Issue by albireox Thursday Jul 07, 2016 at 06:46 GMT Originally opened as https://github.com/marvin-manga/marvin/issues/5

---

Brian:

We should add convenience properties into the Nsa ModelClasses?. For starters, a good list could include broadband colors between FNugriz, log of stellar mass and similar quantities, and magnitudes of all the fluxes.

Here are examples for how to define something on both the class and instance side, such that the new property can be returned as a parameter, and used in a query filter for the postgresql query. plate-ifu property in Cube modelclass

    @hybrid_property
    def plateifu(self):
        '''Returns parameter plate-ifu'''
        return '{0}-{1}'.format(self.plate, self.ifu.name)

    @plateifu.expression
    def plateifu(cls):
        return func.concat(Cube.plate, '-', IFUDesign.name)

old version of log stellar mass from the deprecated Sample modelclass. There might be a better way to do this to account for NULL and -9999.0 values of the stellar mass on the SQL side.

    @hybrid_property
    def nsa_logmstar(self):
        try:
            return math.log10(self.nsa_mstar)
        except ValueError:
            return -9999.0
        except TypeError:
            return None

    @nsa_logmstar.expression
    def nsa_logmstar(cls):
        return func.log(cls.nsa_mstar)

[albireox]

Comment by albireox Thursday Jul 07, 2016 at 06:47 GMT

---

José:

This is a good idea but I think we need to think about what properties/colours/magnitudes we want to use for querying. I don't think we want to put a lot of effort in creating hybrid properties for all combinations of parameters, when only a few will reasonably be use. This is something for which we can ask people to give their input.

I have created some hybrid properties for petroth50_el in SampleModelClasses. The properties, colours, and expressions are created dynamically, so it is relatively easy to expand them. Have a look at SampleModelClasses.py​

BTW, I have created a marvin branch for sdss_python_module. I think we want to use it for sdss_python_module-related development of Marvin, instead of directly using briandev. Each one of us can have his own branch to test things, but one we add some functionality to Marvin let's merge to sdss_python_module/marvin.

Also, for the ModelClasses for mangaSampleDB, I still want to keep the main repo in ​https://github.com/albireox/mangaSampleDB so, if the ModelClasses do need to live in sdss_python_module, let's make the changes in the Git repo and then copy the model classes to sdss_python_module when necessary.

[albireox]

Comment by albireox Thursday Jul 07, 2016 at 06:47 GMT

---

Brian:

Not all combinations of parameters but the common ones that we know people will query off it that aren't in the catalog already. Or common properties that are in form in the catalog than people normally search with, i.e.g log units for things. We do have lots of properties with many bands. Let's pick a few simple ones and as people request more, then we can add them in.

I like what you've done in SampleModelClasses?. It took me a bit to understand why you did what you did, but I think it makes sense.

I'm ok with switching to a marvin branch of spm. As long as merging goes smoothly. My track record ain't so good with that. I'm also fine keeping the main mangaSample in the git repo, although I like having all the ModelClasses? in the same place. For now I think let's keep things in spm. When we discuss moving all the database stuff outside of spm, and into marvin, then we can revisit this.

[albireox]

Comment by albireox Thursday Jul 07, 2016 at 06:47 GMT

---

José:

I agree. We can add a few more examples to the SampleModelClasses hybrid classes (and maybe some magnitudes) and then ask people what properties and combinations we should prioritise. This might be a good topic to get feedback in one of the telecons during the MarvinWeek.

There may be simpler ways to code what I have done in the SampleModelClasses, but I think we want to develop some kid of hybrid property factory, instead of hardcode all the possible combinations (unless we end up agreeing there is a small number of them).

Yes, let's keep the git repo for now. Maybe we can merge it with sdss_python_module at some point, but at least I want to keep the model classes and the scripts to populate the DB in the same place, and I'm not sure the latter fit in sdss_python_module very well. Let's discuss it in Pittsburgh.

[albireox]

Comment by albireox Thursday Jul 07, 2016 at 06:47 GMT

---

Brian:

From MarvinWeek? last week, it was decided that we would only start with colors and magnitudes used in the MaNGA target selection.

[albireox]

Comment by havok2063 Thursday Jul 07, 2016 at 13:35 GMT

---

Adding to this. I updated the SampleModelClasses with petro_logmass_el and sersic_logmass for the NSA class.

[albireox]

Comment by havok2063 Thursday Sep 22, 2016 at 14:19 GMT

---

@albireox Once we update the NSA color syntax inside the ModelClasses I think we can close this ticket for the time being.

[albireox]

Comment by havok2063 Monday Sep 26, 2016 at 17:42 GMT

---

I think we can close this now. And always reopen as needed.