Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Firefly
-
Labels:
-
Story Points:4
-
Epic Link:
-
Sprint:SUIT Sprint 2018-10
-
Team:Science User Interface
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:
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:
Displaying the VOTable Meta Data.
Then click Search:
This takes us to:
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
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
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
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 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. 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.
It was fixed in IRSA ticket https://jira.ipac.caltech.edu/browse/IRSA-1940.
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.
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.