| Summary: | New neutron inelastic thermal scattering data for: h_water contains wrong cos value | ||
|---|---|---|---|
| Product: | Geant4 | Reporter: | Vasilis Vlachoudis <Vasilis.Vlachoudis> |
| Component: | processes/hadronic/models/neutron_hp | Assignee: | loic.thulliez |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | Alberto.Ribon, Vladimir.Ivantchenko |
| Priority: | P4 | ||
| Version: | 11.1 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Vasilis Vlachoudis
2023-07-13 14:23:37 CEST
*** Problem 2553 has been marked as a duplicate of this problem. *** Dear Vasilis, Thanks to get in touch with us. When I look at the file that I have processed, I don't see any problem in FS/Inelastic/h_water.z in using the following dataset " wget https://geant4-data.web.cern.ch/datasets/Thermal/ThermalScattering_XS_JEFF33_TSL_mix_JEFF33_ENDFB80_LowPrecision.1.0.tar.gz". For example when I look at the first example that you give "Inelastic: T=293.6 Ein=2.855 Eout=2.85501 j=7 x=0.999813 xprev=0.999828", I get: 2.854998e+00 1.551079e+01 6.196719e-01 7.250247e-01 7.936083e-01 8.490708e-01 8.969501e-01 9.397127e-01 9.785491e-01 9.988888e-01 2.855000e+00 1.556070e+01 6.198778e-01 7.254010e-01 7.940956e-01 8.496479e-01 8.976047e-01 9.404366e-01 9.792820e-01 9.989958e-01 2.855000e+00 1.556064e+01 6.198778e-01 7.254010e-01 7.940956e-01 8.496479e-01 8.976047e-01 9.404366e-01 9.792820e-01 9.989958e-01 2.855002e+00 1.550456e+01 6.196516e-01 7.249875e-01 7.935601e-01 8.490138e-01 8.968854e-01 9.396412e-01 9.784762e-01 9.988777e-01 So I don't see any problem on my side. To try to disentangle things: * could you look at the file directly with the command : /usr/bin/zlib-flate -uncompress < h_water.z >> h_water.txt and then copy/paste here the lines relevant to the following example that you mention and also give the line number at which you spot the problem: "Inelastic: T=293.6 Ein=2.855 Eout=2.85501 j=7 x=0.999813 xprev=0.999828" * could you send my the script that you have used to read the data? Cheers, Loïc Thanks Loic for looking at it, look for example at lines 137627 +3 2.855012e+00 1.610547e+00 9.375713e-01 9.806893e-01 9.899421e-01 9.948478e-01 9.975586e-01 9.990857e-01 9.998263e-01 9.998133e-01 2.855012e+00 1.608808e+00 9.375337e-01 9.806684e-01 9.899246e-01 9.948345e-01 9.975489e-01 9.990792e-01 9.998237e-01 9.998146e-01 2.855012e+00 1.605336e+00 9.374586e-01 9.806264e-01 9.898895e-01 9.948080e-01 9.975294e-01 9.990663e-01 9.998184e-01 9.998170e-01 and compare the last two columns: 9.998263e-01 9.998133e-01 9.998237e-01 9.998146e-01 9.998184e-01 9.998170e-01 BTW now that I am looking the file I see that many entries that could be removed or increase the floating point format precision. E.g. There are 5 consecutive lines corresponding to the "same" outgoing energy 2.855012e+00 probably due to lack of digits in the formatting, which increases unnecessary the file size. cheers vasilis Dear Vasilis, You are right when I processed the data I have made some round-off in the outgoing energy and if you take one more digit, the energies will be different. I will discuss with Alberto if reproducing the library for the next release could be doable. For the problem of cos(mu), now, I am agree with you. Just to be sure the last example if for light water at 473.6 K, is that it ? Apparently it is a problem coming from NJOY processing tool, so this may complicate its solving. So I have to inesgivate further the problem. I stay in touch with you. Cheers, Loic In my opinion, the energy grid resolution you have is enough (much finer than what the data can provide) so I would not see the reason to add one more digit, but rather remove the apparent duplicate entries. For the cos(mu) issue I have the impression that is due to some numerical precision hiccup in the processing program (NJOY?). If NJOY cannot fix it, and if it only concerns the last interval (as it seems), my suggestion would be to replace it with the previous value so as to avoid the sampling of the last interval In my opinion, the energy grid resolution you have is enough (much finer than what the data can provide) so I would not see the reason to add one more digit, but rather remove the apparent duplicate entries. For the cos(mu) issue I have the impression that is due to some numerical precision hiccup in the processing program (NJOY?). If NJOY cannot fix it, and if it only concerns the last interval (as it seems), my suggestion would be to replace it with the previous value so as to avoid the sampling of the last interval Dear Vasilis, With a colleague, we have contacted NJOY people and it really seems to be a NJOY problem. A fix has been attempted and now the linearization problem of cos(mu) is gone without be sure that the results are correct. So I think, for now, it is better to stay with what we have and correct the last cos(mu) having strange value in adding to the previous value a small additional epsilon equal to 0.0001, what do you think? If it is OK with you, I will reprocess the data and get in touch with Alberto to upload them. On the long term, I will pay attention to new NJOY version and update the database if any long term fix would be done to tackle this problem. I hope that this solution suits you. Cheers, Loïc Dear Loic, many thanks for contacting NJOY to fix it. For me the interim solution you proposed looks fine. I will wait for the new data set best vasilis Hello Vasilis, I have made the correction and uploaded the corrected dataset for h_water here: https://cernbox.cern.ch/s/TfRFMrasMGQgklY Let me know if everything is also fine for you. If yes, I will reprocess all the datasets. Best, Loïc |