https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/SURVEY-10 Survey operation on planning and tracking <p>Currently, there are placeholders for the output of 1D-DRP in the spt_operational_database, but the tables are not necessarily consistent with the actual outputs. So, revisit the tables of the spt_operational_database and add new tables/columns if necessary.</p> SURVEY-10

Add tables in the operational database for 1D-DRP

Task Normal Done Done Kiyoto Yabe Kiyoto Yabe opDB Mon, 4 Mar 2019 02:06:42 +0000 Wed, 19 Feb 2020 04:32:58 +0000 Wed, 19 Feb 2020 04:32:57 +0000 0 9 <p>As part of SciDB proto-type v2 effort, Takita-san discovered the same problem here.  Namely, not all the columns in the operational database can be populated by the 1d outputs.  I discussed with him today and here is a list of comments/problems/questions.  Please refer to the yellow boxes in <a href="https://github.com/Subaru-PFS/spt_operational_database/blob/master/pfs_schema.pdf" class="external-link" rel="nofollow">https://github.com/Subaru-PFS/spt_operational_database/blob/master/pfs_schema.pdf</a></p> <ul> <li>In the SpecLine table, there is 'chi2' column, but the LAM 1d does not output chi2 (it is not in the datamodel).  In addition, it seems the LAM 1d pipeline measures line properties only for a single line (not sure which line it is), but that will probably be a separate ticket and let us not care about that in this ticket.</li> <li>In the SpecParam table, 'redshift' should be 'z'.  The 1d pipeline does not compute z_mean, z_median, nor z_percentile (again, they are not in the datamodel).  It does generate P(z) and so we can compute them in theory, but I believe that should not be a database task.  Could you remind me why we need those columns?  If we need them, we should probably ask LAM 1d to compute them.</li> <li>We are not sure what 'starTypeId' means In the StarSpecParam table.  The GA 1d pipeline computes metallicity for various elements.  Do we want to store all of them?  The reason why we need metallicity for the on-site operation is because we may use it to define 'doneness', correct?</li> </ul> <p>I have some additional comments.</p> <p>For the metallicity column in the StarSpecParam table, I found <span class="error">&#91;M/H&#93;</span> column so I can use this.</p> <ul> <li>(both LAM and GA) pipeline version and process date columns on "SpecParam" and "StarSpecParam" table.<br/> I hope that these information are written in fits header or somewhere else.</li> </ul> <ul> <li>(GA) object ID.<br/> I need some information in the fits file (file name or fits header) to specify the object ID.</li> </ul> <p>When I have designed schema of operation database a few years ago, there is no datamodel for 1d spectra and I have just referenced SDSS database. So we need to update schema according to the current output of the pipeline. In addition, I have designed the schema can be used for science as well to some extent.</p> <p>&gt; We are not sure what 'starTypeId' means In the StarSpecParam table. </p> <p>starTypeId is simply an id number of "StarType" table defining star type like F0, G5 etc.</p> <p>I'm not sure how detailed classification will be made by 1d GA pipeline.</p> <p> </p> <p>I personally do not think it is necessary for PFS GA to include a spectral type for the star.  That information is not necessarily provided by PFS spectra.  The information that is provided (Teff, logg, etc.) is more informative than a spectral type.</p> <p>It's possible that we may want to include membership information.  For example, is the star a member of M31, or is it a foreground star in the Milky Way?  However, I do not think we should commit to providing that information in the data releases.  I would prefer to the data users to make their own membership determinations.</p> <p>I think we should ask if other users of the DB will want a spectral type. I defer to Evan's opinion for the GA folk, but I suspect that e.g. extra-galactic types will be more comfortable saying <tt>F6III</tt> than a query on T_fff and g.</p> <p>Even if we don't update the information, I suspect that we'll need to record why a star was targeted (e.g. as an M31 giant). This is a general requirement: that the users know why any object was targeted, and in general there may be multiple reasons. <br/> I'm not sure how we deal with this for open use; probably via a bit that says <tt>OpenUse</tt> and another table to join to with suitable details.</p> Development Rank 0|u000c0: