Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-15765

Firefly displays the wrong value (exponent) for some fields in XML/VOTable

    XMLWordPrintable

Details

    • Bug
    • Status: Done
    • Resolution: Done
    • None
    • Firefly

    Description

      We see a problem with firefly not properly formatting some numeric values on the NED Test Interface.
      In order to illustrate we use only the IRSA Ops Firefly server, and supply a query to NED for a VOTable so that the input can be visually validated. The NED interface is not involved in this.

      When supplied with the value <TD>-0.000226 </TD> in XML, Firefly displays -2.26E+00
      This happens using the NED development FF server, AND the current IRSA Ops FF server.

      NED query to obtain the XML/VOTable:

      https://ned.ipac.caltech.edu/cgi-bin/objsearch?objname=SDSS+J225347.79%2B005401.4&radius=.1&hconst=73&omegam=0.27&omegav=0.73&corr_z=1&z_constraint=Unconstrained&z_value1=&z_value2=&z_unit=z&ot_include=ANY&nmp_op=ANY&out_csys=Equatorial&out_equinox=J2000.0&obj_sort=Distance+to+search+center&of=xml_main&zv_breaker=30000.0&list_limit=5&img_stamp=NO&search_type=Near+Name+Search

      returns (currently) 1 record. In field 7 called Redshift is the value -0.000226

      We attach the XML output from this query for reference.

      To verify we access the upload action for firefly (irsaviewer)
      https://irsa.ipac.caltech.edu/irsaviewer/?__action=layout.showDropDown&visible=true&view=FileUploadDropDownCmd

      and select "Upload from URL" then insert the NED query above, click Upload.

      This takes us to:

      https://ff1.ned.ipac.caltech.edu:8443/firefly/?__action=layout.showDropDown&visible=true&view=FileUploadDropDownCmd

      Displaying the VOTable Meta Data.

      Then click Search:
      This takes us to:

      https://irsa.ipac.caltech.edu/irsaviewer/?__action=table.search&request=%7B%22startIdx%22%3A0%2C%22pageSize%22%3A100%2C%22filePath%22%3A%22%24%7Btemp-files%7D%2Fupload_1888104677889564593.0%26list_limit%3D5%26img_stamp%3Dno%26search_type%3Dnear%2Bname%2Bsearch%22%2C%22META_INFO%22%3A%7B%22title%22%3A%22objsearch%3Fobjname%3DSDSS%2BJ225347.79%252B005401.4%26radius%3D.1%26hconst%3D73%26omegam%3D0.27%26omegav%3D0.73%26corr_z%3D1%26z_constraint%3DUnconstrained%26z_value1%3D%26z_value2%3D%26z_unit%3Dz%26ot_include%3DANY%26nmp_op%3DANY%26out_csys%3DEquatorial%26out_equinox%3DJ2000.0%26obj_sort%3DDistance%2Bto%2Bsearch%2Bcenter%26of%3Dxml_main%26zv_breaker%3D30000.0%26list_limit%3D5%26img_stamp%3DNO%26search_type%3DNear%2BName%2BSearch%22%2C%22tbl_id%22%3A%22tbl_id-c38390-10%22%7D%2C%22tbl_id%22%3A%22tbl_id-c38390-10%22%2C%22id%22%3A%22userCatalogFromFile%22%2C%22tbl_index%22%3A0%7D

      The Redshift field contains "-2.26E+00" (!= -0.000226 the value in the XML/VOTable)

      We have attempted in the NED user interface to supply Firefly with alternate formatting for the field, with no apparent effect.

      Other numeric fields (See RA and Dec) [^https_ned.ipac.caltech.edu_cgi-bin_objsearch.xml] in the same table/query do not seem to have this problem.

      Doing a Slightly larger NED Query

      https://ned.ipac.caltech.edu/cgi-bin/objsearch?objname=SDSS+J225347.79%2B005401.4&radius=.5&hconst=73&omegam=0.27&omegav=0.73&corr_z=1&z_constraint=Unconstrained&z_value1=&z_value2=&z_unit=z&ot_include=ANY&nmp_op=ANY&out_csys=Equatorial&out_equinox=J2000.0&obj_sort=Distance+to+search+center&of=xml_main&zv_breaker=30000.0&list_limit=5&img_stamp=NO&search_type=Near+Name+Search

      Returns another object with a Redshift (in the VOTable of 2.255000 -
      the above process displays as "2.26+E00" which is correct to the precision displayed.

      We'd appreciate immediate attention to this.

      Contact Jeff Jacobson after Oct 1, 2018.  NED ENG-1102

      Attachments

        Activity

          rick Rick Ebert added a comment -

          We have studied this a bit more and find the following:
              negative values  less than -0.001  are rendered incorrectly.
          Some further examples (with ned target names and Redshift values:

          These produce in correctly rendered values:
          2MASS J13102857+4949588 <TD>-0.000297 </TD>     Rendered as -2.97E+00
          SDSS J133046.29+461412.8 <TD>-0.000289 </TD>       Rendered as -2.89E+00

          These produce correctly rendered values:
          SDSS J121015.17+163442.5 <TD>-0.003117 </TD>
          SDSS J141930.18+140121.5 <TD> 0.000192 </TD>

          Note, we are checking this against the FF server that is in IRSA Ops, using tables returned from NED ops as in the description scenario - changing only the Target/Object-name.

          rick Rick Ebert added a comment - We have studied this a bit more and find the following:     negative values  less than -0.001  are rendered incorrectly. Some further examples (with ned target names and Redshift values: These produce in correctly rendered values: 2MASS J13102857+4949588 <TD>-0.000297 </TD>     Rendered as -2.97E+00 SDSS J133046.29+461412.8 <TD>-0.000289 </TD>       Rendered as -2.89E+00 These produce correctly rendered values: SDSS J121015.17+163442.5 <TD>-0.003117 </TD> SDSS J141930.18+140121.5 <TD> 0.000192 </TD> Note, we are checking this against the FF server that is in IRSA Ops, using tables returned from NED ops as in the description scenario - changing only the Target/Object-name.

          https://irsadev.ipac.caltech.edu/irsaviewer  DEV version displays the values correctly. 
          v3.1.0_Development Built On: 2018-09-19, Git Commit 54d55af, Git Commit (firefly) eb21466
           
          I can reproduce the error by using IRSA Viewer OPS version.  http://irsa.ipac.caltech.edu/irsaviewer/

          v3.1.0_Final-3099 Built On:Wed Aug 15 16:24:59 PDT 2018

          I can also reproduce the error in Test version. It is older than OPS. 

             http://irsatest.ipac.caltech.edu/irsaviewer  v2.0.0_Beta-2857 Built On:Thu Jun 28 15:18:46 PDT 2018  

          xiuqin Xiuqin Wu [X] (Inactive) added a comment - https://irsadev.ipac.caltech.edu/irsaviewer   DEV version displays the values correctly.  v3.1.0_Development Built On: 2018-09-19, Git Commit 54d55af, Git Commit (firefly) eb21466   I can reproduce the error by using IRSA Viewer OPS version.   http://irsa.ipac.caltech.edu/irsaviewer/ v3.1.0_Final-3099 Built On:Wed Aug 15 16:24:59 PDT 2018 I can also reproduce the error in Test version. It is older than OPS.      http://irsatest.ipac.caltech.edu/irsaviewer   v2.0.0_Beta-2857 Built On:Thu Jun 28 15:18:46 PDT 2018  
          rick Rick Ebert added a comment -

          I submitted our 2 test cases as file uploaded to irsadev instance.  They showed the correct value.  When Jeff is back we'll update the NED FF instance, and test more thoroughly.

          rick Rick Ebert added a comment - I submitted our 2 test cases as file uploaded to irsadev instance.  They showed the correct value.  When Jeff is back we'll update the NED FF instance, and test more thoroughly.
          loi Loi Ly added a comment -

          This particular piece of code is reading the VOTable then writing it back out into an IPAC table before storing the data in a database.

          In the process of converting the VOTable into IPAC table, it wrongly calculated the width of that column to be 8 instead of 10.  As a result, the value '-2.26E-04' is truncated to '-2.26E-0' and stored as is.   This is the reason why it's displayed as -2.26E-00.

          This is the behavior in OPS.  This problem was already fixed in DEV when I got assigned this ticket.  Also in DEV are many other changes including changes to the way we read in VOTable. 

          I suggest marking this ticket as fixed since it is now fixed in DEV.

          loi Loi Ly added a comment - This particular piece of code is reading the VOTable then writing it back out into an IPAC table before storing the data in a database. In the process of converting the VOTable into IPAC table, it wrongly calculated the width of that column to be 8 instead of 10.  As a result, the value '-2.26E-04' is truncated to '-2.26E-0' and stored as is.   This is the reason why it's displayed as -2.26E-00. This is the behavior in OPS.  This problem was already fixed in DEV when I got assigned this ticket.  Also in DEV are many other changes including changes to the way we read in VOTable.  I suggest marking this ticket as fixed since it is now fixed in DEV.
          xiuqin Xiuqin Wu [X] (Inactive) added a comment - It was fixed in IRSA ticket https://jira.ipac.caltech.edu/browse/IRSA-1940.  

          tested and it worked as expected. 

          xiuqin Xiuqin Wu [X] (Inactive) added a comment - tested and it worked as expected. 

          I tested this using a NED FF server instance "v1.0.0_Development Built On: 2018-10-10.   Works as expected.

          jdj Jeffery Jacobson added a comment - I tested this using a NED FF server instance "v1.0.0_Development Built On: 2018-10-10.   Works as expected.

          People

            loi Loi Ly
            rick Rick Ebert
            Jeffery Jacobson, Xiuqin Wu [X] (Inactive)
            Gregory Dubois-Felsmann, Jeffery Jacobson, Loi Ly, Rick Ebert, Xiuqin Wu [X] (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Jenkins

                No builds found.