Closed DocOtak closed 4 years ago
Organize the listed attributes in the box for each core by this order: Switch positions of "Type" and "Distance", then switch positions of "Signal" and "Type". When "Direction" is available, add beneath "Distance". This puts all the core attributes in the left column and all the geo-location attributes in the right column. Also, change the distance unit from "KM" to "km". Do these before limited release.
Implement Core listing sorts individually by "Signal" and "Distance". The closest and most intense cores are very important. Alphabetical listing can be retained as the initial (default) presentation. Do this before limited release.
It is nice to have color but it is not evident why the boxes for each core have different colors. The core dots on the map are colored to indicate type (red- PHWR, Blue- MOX, Gold- GCR, Green- PWR, BWR). However, it appears that the core box colors do not correlate with core type but may somehow relate to Load Factors. If so, Core Load Factor alone is not overly important at some given location if the core is very distant and contributing little signal. There needs to be a key to let users know what the colors indicate. Without a key for the colored core type on the map, the core boxes on the Core List could match the map to avoid confusion. It would be nice to discuss this with you but you seem to have pushed me into communicating by GitHub comments.
I'll remove the colors, the color options are limit and they cannot easily match the colors of the dots on the map.
Sorting by other attributes (especially numeric ones) should not be too hard.
The layout I went for on the initial layout of the columns is "things that change" on the left, and "constants" on the right. Is the following order what is desired?
Left Col | Right Col |
---|---|
Load Factor | Lat |
Operating Power | Lon |
Type | Elevation |
Signal | Distance |
Direction (when available) |
Yes. Core attributes in left column and geo-location attributes in the right column.
The sort on distance should be smallest to biggest and the sort on signal should be biggest to smallest.
-----------------------------------------From: "Andrew Barna"
To: "geoneutrinos/reactors" Cc: "Stephen Dye", "Comment" Sent: Monday April 27 2020 8:12:50AM Subject: Re: [geoneutrinos/reactors] Reactors tab TODOs (#9)
I'll remove the colors, the color options are limit and they cannot
easily match the colors of the dots on the map.
Sorting by other attributes (especially numeric ones) should not be
too hard.
The layout I went for on the initial layout of the columns is "things
that change" on the left, and "constants" on the right. Is the following order what is desired?
LEFT COL
RIGHT COL
Load Factor
Lat
Operating Power
Lon
Type
Elevation
Signal
Distance
Direction (when available)
—
You are receiving this because you commented. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].
[1] https://github.com/geoneutrinos/reactors/issues/9#issuecomment-620147398 [2] https://github.com/notifications/unsubscribe-auth/ALM4YQ26HNOUYFAA4H24M7LROXDKBANCNFSM4MQM73DQ
An initial attempt at alternate sortings of the cores should be on the staging site. Anything other than sorting by name is slow for the "follow cursor" on map function, but probably useful. Any filtering of the cores (so there are less to display) also speeds things up. There are fancy ways of dealing with this, but these are potentially time consuming to implement (since I've never used those tools before). A known issue is that it will not save the state of core list if you change tabs (will always return to defaults), I'm looking into how to make this better.
This is what was in an email from you about directionality:
(Xdet - Xcore)/R ; (Ydet - Ycore)/R ; (Zdet - Zcore)/R
where R = sqrt[ (Xdet - Xcore)^2 + (Ydet - Ycore)^2 + (Zdet - Zcore)^2) ]
So it seems directions have 3 terms. What would be the best way to display this next to the cores (i, j, k)? Would it be worth converting this into something more polar so there are only two additional terms?
"Operating Power" is not found in the PRIS Glossary at https://pris.iaea.org/PRIS/Glossary.aspx
I just realized, even after you wrote that you were putting values that change in one column, that what is currently labeled as "Operating Power" is the product of Thermal Capacity and Load Factor. Thermal Capacity is called "Design Power" in the reactor pop-up tabs on the map. We should avoid introducing new terminology. If we follow PRIS or the INFN site (https://www.fe.infn.it/radioactivity/antineutrino/index.html), then we would use Thermal Capacity or Thermal Power, respectively, instead of "Design Power". I suggest that the "left" column listing, top to bottom, is Type, Thermal Capacity, Load Factor, Signal. Type and Thermal Capacity (or Thermal Power) are constant attributes of the core, they do not change.
Should the number that is currently labeled "Operating Power" be removed entirely?
Yes.
Regarding direction- yes, we could calculate and display the cos(zenith angle) and azimuth angle for each core in local detector coordinates, as I have plotted the ensemble in the polar graphs. reactor_polargram_boulby.pdf reactor_polargram_surf.pdf
Add "Custom Core" controls for user specification of Power, Core Type, Latitude, Longitude, Elevation (WGS84), including "Place Custom Core Here" option as is now available for "Place Detector Here" except that the Lat/Lon/Elev controls should be active
The default plot is the signal (NIU) as a function of the energy of interacting antineutrinos. It would be very useful to highlight signal as a function of the direction of interacting antineutrinos. This could be done by adding a third plot dimension, signal, to the polar graphs. Note that in the polar graphs linked a few comments above core type is color coded to match the map and there is no signal information. A lego projection of signal as the third dimension would preserve this color coding. Lego obviously requires tilting the direction plane showing the cos(zenith) vs azimuthal so the viewer can see how high the lego stacks up. If the lego option is not available, then signal level could be color coded but, I think, this is less preferable.
With Firefox and Safari browsers (I did not try any others) and using a "command +" or a "command -" while on the Reactors page and then switching back to Detector page causes the polar plot to nearly disappear. It comes back to full size if either the "command +" or "command -" is executed while back on the Detector page
Hm... the polar plot resize thing is caused by the "resize handler" which tries to not let the plot go off the screen when you make the window smaller. However, when tab with the plot is not selected and a "resize" event occurs, it seems to think the width of the container of the plot is zero.
I'm not sure the best way to add signal as information on the plot. Plotly does not seem to support cylindrical coordinates out of the box. Perhaps a wind rose or radar chart? Plotly can do 3d surface plots, but we would get to do calculation of the surface ourselves (cylindrical coordinates -> some 2d grid with z values that make sense). Not saying we cannot do any of this, but we got the basic polar plot for free in that I was able to plot the data as soon as I had finished implementing the coordinate transforms.
Adding Custom Core sends back blank page- all white screen.
Fission fraction suggestions are a very good addition.
Oooh good catch, I pushed a quick fix to the staging site for the blank page thing. That is the equivalent of a "crash" for the web app.
As discussed default order in core list should be either distance or signal rather than alphabetical. Close to closing this one!
1) Add 'Sort By: Type' to 'Core List Display Options'. Note- I tried to do this with 'Filter Core List' but it seems this filter only samples the core name (e.g. Hartlepool A2), which is totally fine. 2) Add 'Sort By: Thermal Capacity' to Core List Display Options. 3) Change 'corespec' in download filename to 'Enu_spec10keV' 4) Close Issue :)
CRASH Report- Select "Turn off all cores" and screen has white out- at least with Firefox browser (78.0.2)
Potential Added feature in anticipation of collaborator requests-
Pasted below is the listing of Great Britain cores from DB2018. Note the instances of average monthly loads >100%. Reactor operators have permission to operate cores at loads > 100% (I have seen up to 104%- indeed the wiki page on Hartlepool specifies two 1575 MWt cores, which is 5% > than the 1500 MW thermal capacity.
The web application has a control "Set to 100% Load". We may well be asked to allow users to exceed this limit. I quickly looked on PRIS but found nothing about exceeding the thermal capacity.
GB DUNGENESS B-2 50.912 0.962 GCR 0 1500 100.50 100.46 64.82 100.54 100.13 77.37 99.28 77.63 -1.41 -1.51 -1.67 -1.70 0.5937 GB HARTLEPOOL A-1 54.634 -1.180 GCR 0 1500 61.75 0.00 -2.47 -2.13 94.25 100.35 99.61 61.97 100.35 100.28 100.68 101.08 0.6846 GB HARTLEPOOL A-2 54.634 -1.180 GCR 0 1500 71.55 82.92 93.27 99.81 55.93 98.81 97.68 98.51 98.92 56.63 99.16 99.97 0.8768 GB HEYSHAM A-1 54.029 -2.912 GCR 0 1500 102.03 102.06 101.57 41.97 101.65 99.46 85.07 96.03 100.72 83.84 74.22 100.53 0.9080 GB HEYSHAM A-2 54.028 -2.912 GCR 0 1500 89.94 89.52 79.42 89.32 87.64 45.23 -0.01 4.14 86.98 88.95 87.90 86.13 0.6935 GB HEYSHAM B-1 54.028 -2.912 GCR 0 1550 91.53 99.52 91.97 97.84 9.78 -0.84 14.11 97.33 97.65 77.49 75.88 91.03 0.7006 GB HEYSHAM B-2 54.027 -2.912 GCR 0 1550 95.25 100.07 80.57 90.55 98.94 89.56 97.69 89.46 98.37 91.04 99.83 99.66 0.9420 GB HINKLEY POINT B-1 51.208 -3.131 GCR 0 1494 94.44 37.02 98.37 100.83 100.50 79.84 94.82 91.89 98.94 94.39 100.20 95.34 0.9094 GB HINKLEY POINT B-2 51.208 -3.131 GCR 0 1494 97.11 99.49 84.19 -0.27 0.63 99.88 92.96 98.44 95.86 99.73 100.65 96.93 0.8038 GB HUNTERSTON B-1 55.721 -4.893 GCR 0 1496 74.44 97.34 24.20 -3.65 -2.73 -1.44 -0.86 -0.54 -0.53 -0.92 -1.25 -1.65 0.1471 GB HUNTERSTON B-2 55.721 -4.893 GCR 0 1496 98.02 95.82 100.13 95.21 100.14 93.56 99.24 94.13 99.45 2.99 -4.84 -2.14 0.7247 GB SIZEWELL B 52.215 1.623 PWR 0 3425 1.02 82.96 92.99 100.54 100.26 99.83 99.39 96.78 99.70 100.04 100.35 100.37 0.8946 GB TORNESS-1 55.966 -2.399 GCR 0 1623 93.88 101.92 71.61 101.33 82.25 101.51 97.27 96.88 93.79 95.89 101.73 93.42 0.9417 GB TORNESS-2 55.966 -2.399 GCR 0 1623 87.03 89.21 78.62 100.58 92.38 101.10 81.53 102.77 22.41 -0.75 13.76 65.56 0.6946
Output filename is getting to be too many characters. Nonetheless, we might anticipate a request for information on the state of the reactor load factors used to make the spectrum. Ideas?
Change default Core List sort from "Signal" to "Distance" (Apologies!)
One of the primary WATCHMAN analyses is seeing the difference between spectra with certain cores on or off. With the default sort on "Signal" turning off a core sends it to the bottom of the list some 450 cores deep.
Add a pane called "Fission Isotope Emission Spectra" to the Reactors tab. A drop down menu similar to the Neutrino Cross Section pane on the Physics tab would be good for now even if only containing the Huber (235U, 239Pu, 241Pu) and Mueller (238U) emission spectra. A note giving the reference publications is needed too. There is a strong possibility of adding versions of the emission spectra from authors other than Huber and Mueller. I can explain more about these other spectra and their motivation on a zoom call
Add a pane called "Fission Fractions" to the Reactors tab (getting to be too much stuff on this tab but ...). Maybe a pull down menu for each core type that pops up the cycle averaged fission fractions for 235U, 238U, 239Pu, 241Pu we are using. However, works best without overly cluttering the already full tab.
Improvements to the core list: