AtomDB as an external file

[marquezj]

In connection with #176, perhaps it would be useful to have the atomDB as an external file (could be a simple csv file). Then bound atom cross sections and abundances could be used to match existing high energy neutron libraries.

[tkittel]

If we do, I would like it to be reflected in the cfg-string. Otherwise, the lowE physics produced by NCrystal would be different with different frontends, despite using the same cfg-string So perhaps something like "mymat.ncmat;atomdb=atomdb_endf8.txt" where atomdb_endf8.txt would have been registered with NCrystal previously, or perhaps even shipped with NCrystal.

[xxcai1]

Very interesting! It is useful when coupling with ENDF data driven models in a Monte Carlo package. Except for the bound cross section and abundance data differences between ENDF and NCrystal, I think the physical pictures are also quite different. The bound cross section is the combination of coherent and incoherent scatterings, and the coherent scattering length is target spin independent. I guess the coherent scattering length is measurable by interferometry or gravity reflectometry, and the ENDF data are from neutron transmission (I'm less certain about the origin of ENDF data). So the cross section discrepancies between NCrystal and ENDF may be considered as the differences of the incoherent scattering cross section. It may not have any impact on the coherent scattering models.

[ramic-k]

Hi Thomas,

For SCALE integration of NCrystal this issue would be important because SCALE already has a standard composition library, so being able to use that through this feature would be awesome!

[tkittel]

@ramic-k When you say "composition library" are you referring to abundances, or a library of scattering lengths? The term "composition" sounds a bit like only the former.

[ramic-k]

I am not the biggest expert on SCALE ins and outs, and "Standard composition library" is quite convoluted thing that everyone hates, yet lives with, but I think it contains both sets of data in one way or another. Below is the example of what can be found in it, there are two sections:

' *********************************************************
' ************* Standard Composition Table *************
' *********************************************************
' SCID: composition name (max 12 characters)
' ROTH: theoretical density (gm/cm3)
' ICP: 0 (mixture) / 1 (compund)
' NCZA: element/nuclide ID
' ATPM: weight percent (mixture) / number of atoms per molecule (compound)
' *********************************************************
' SCID ROTH. ICP NCZA ATPM END
ac-205 1.0000 0 89205 100.00 end
ac-206 1.0000 0 89206 100.00 end
ac-207 1.0000 0 89207 100.00 end

' *********************************************************
' ************* Nuclide Table *************
' *********************************************************
' ID AWR SigmaS SigmaT nuSigmaF
900 0.60220 0.00000 0.00000 0.00000
999 0.60220 0.00000 0.06400 0.00000
1000 1.00794 20.45000 20.45000 0.00000
1001 1.00783 20.38087 20.38782 0.00000
1002 2.01410 3.39486 3.39487 0.00000
1003 3.01605 1.30000 1.30000 0.00000
1004 4.02781 0.00000 0.00000 0.00000
1005 5.03531 0.00000 0.00000 0.00000
1006 6.04494 0.00000 0.00000 0.00000
1007 7.05275 0.00000 0.00000 0.00000

[tkittel]

Ok, let me know if you figure out something more detailed and precise. Because if this ncrystal feature has to make sense, you will have to be able to convert that data into a .txt file with data for NCrystal. If you can not do that, there is really no reason for me to implement this new feature :-)

In terms of elements and isotopes, what NCrystal needs is (all of the) data entered in ATOMDB fields here: https://github.com/mctools/ncrystal/wiki/NCMAT-format#the-atomdb-section

The issue of natural abundancies is separate, but related.

[tkittel]

It would be great if @ramic-k and @marquezj would actually provide such sample data files, so that I will not have to develop such a new feature in a vacuum (which probably would mean that I would not implement it at all).