njoy / acetk Goto Github PK
View Code? Open in Web Editor NEWToolkit for working with ACE-formatted data files
License: Other
Toolkit for working with ACE-formatted data files
License: Other
Verify if Kabach-Mann is ever used for photons. If not, the numberDiscretePhotonLines() function should not even be in the interface.
The interface for the NU block was designed for the total and prompt nubar for the NU block. The delayed nubar from the DNU block is the same but the interface feels inappropriate. This is not a blocking issue but we should look into it before the entire ContinuousEnergyTable gets deployed for general use.
I'm looking to zero out the inelastic collisions of U235. I've noticed that when changing MT=59 in the CrossSectionBlock, MT numbers will be altered in ways I don't believe it should.
I've uploaded an example as a gist here
You can see that 16 is removed, and 15 is added, in the reaction numbers, and additionally a duplicate 58 has been added.
In another script, when I go to read MT=59 in this resulting edited cross section file, I will get an error of "[error] The requested reaction number MT59 is not present" despite it appearing in the list of MT numbers.
This is using the ENDF data distributed with MCNP6.2, which I can attach or email privately if needed.
If I try to load this cross section in MCNP, I will get the following error,
Expire parameter is
error 2 in 92235.80c of cross-section file xdata/endf71x/u/92235.710nc
bad trouble in subroutine sread of xact
error 2 in 92235.80c of cross-section file xdata/endf71x/u/92235.710nc
Given a working Table, the following will not compile:
std::ostringstream oss;
Table.print( oss );
I only saw testing for table.header.print()
and it appears to work, but I am not certain that I am using table.print()
correctly. I discovered this when working on feature/el03-temporary. Test will be pushed up shortly
Would be nice to hide to following in the body of a factory method:
auto contents = njoy::utility::slurpFileToMemory( filename );
njoy::ACEtk::State< std::string::iterator > s{ 1, contents.begin(), contents.end() };
auto table = Table( s );
e.g.
auto table = njoy::ACEtk::make< Table >( aceFileContaingTable );
We need to have support for 2.0.0 header. I know the specification may not have been well written, but there are files in "the wild" that use this header and therefore needs to be implemented.
when calling find_package and pointing to a newly installed ACEtk, I get the following:
By not providing "FindACEtk.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "ACEtk", but
CMake did not find one.
Could not find a package configuration file provided by "ACEtk" with any of
the following names:
ACEtkConfig.cmake
acetk-config.cmake
Add the installation prefix of "ACEtk" to CMAKE_PREFIX_PATH or set
"ACEtk_DIR" to a directory containing one of the above files. If "ACEtk"
provides a separate development package or SDK, be sure it has been
installed.
Call Stack (
There is a nice constructor for the Table::Header, but no way to specify the (optional) MAT and Source.
Continuous integration using GitHub Actions has started to fail on MacOS 11 since last week, most likely following an update to the runners. That update seems to have installed Python 3.11 instead of a lower version.
As a result, all GitHub Actions on MacOS have started to fail automatically with errors like this:
Run make -j2
[ 2%] Building CXX object CMakeFiles/ACEtk.python.dir/python/src/ACEtk.python.cpp.o
[ 2%] Building CXX object src/ACEtk/ContinuousEnergyTable/test/CMakeFiles/ACEtk.ContinuousEnergyTable.test.dir/ContinuousEnergyTable.test.cpp.o
In file included from /Users/runner/work/ACEtk/ACEtk/python/src/ACEtk.python.cpp:2:
In file included from /Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/pybind11.h:45:
In file included from /Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/attr.h:13:
/Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/cast.h:446:36: error: member access into incomplete type 'PyFrameObject' (aka '_frame')
" " + handle(frame->f_code->co_filename).cast<std::string>() +
^
/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11/pytypedefs.h:22:16: note: forward declaration of '_frame'
typedef struct _frame PyFrameObject;
^
In file included from /Users/runner/work/ACEtk/ACEtk/python/src/ACEtk.python.cpp:2:
In file included from /Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/pybind11.h:45:
In file included from /Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/attr.h:13:
/Users/runner/work/ACEtk/ACEtk/bin/_deps/pybind11-src/include/pybind11/cast.h:448:29: error: member access into incomplete type 'PyFrameObject' (aka '_frame')
handle(frame->f_code->co_name).cast<std::string>() + "\n";
^
/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11/pytypedefs.h:22:16: note: forward declaration of '_frame'
typedef struct _frame PyFrameObject;
^
The following 16 isotopes in Lib80x (.00c) give the error "DLW multi-law - currently not implemented" when trying to load them with ACEtk.ContinuousEnergyTable.from_file()
:
B/5010.800nc
O/8017.800nc
F/9019.800nc
Na/11022.800nc
Na/11023.800nc
Ar/18036.800nc
Ar/18038.800nc
Co/1027058.800nc
Ba/56140.800nc
Ta/73182.800nc
Ra/88223.800nc
Ra/88224.800nc
Ra/88225.800nc
Ra/88226.800nc
Am/1095244.800nc
Am/95244.800nc
The remaining 540 isotopes in Lib80x load just fine.
These are energies, not cosines.
Originally posted by @cjosey in #46 (comment)
[design question, future]
Should these return enums or similar instead?
Originally posted by @cjosey in #49 (comment)
When attempting to read a valid MCNP6 xsdir file with ACEtk.Xsdir.from_file(...)
, ACEtk errors out with the error text:
[error] Expected 'datapath' but found '#-------'
No xsdir files distributed with MCNP6.2 or 6.3 contain the expected 'datapath' string, at least not in my data directories. ACEtk should probably not error out in these cases, but set an appropriate default value based on the data directory structure of MCNP (probably datapath = ".";
I guess?).
EDIT: Attempting to modify an MCNP6 xsdir file to be compatible with what ACEtk expects reveals some additional problems:
#
, and any comment line will cause an error: Something went wrong while reading an xsdir entry
Expected an additional line but found the end of stream
. This occurs even if there is no blank line at the end of the xsdir file; with two or more blank lines at the end the error reverts to Something went wrong...
. std::getline
and feeding the result into a ``std::stringstream` after validating; this seems convoluted but is more reliable) instead of trying to read XsdirEntry objects directly from the file stream. This allows trimming and checking for empty lines/EOF before attempting to build a XsdirEntry.Secondary particle blocks like SIGH, etc. do not perform an index range check in DEBUG mode contrary to what the doxygen documentation tells us. Probably an oversight on my part when I refactored that part of the code.
In addition, we should also provide access functions for each of the vectors with these blocks (this would make copying over the data easier - no need to put everything into a vector yourself).
Multiple "Readonly properties" of the DLW.energy_distribution_data() are not defined for the Lib80x Pu-239 ACE file. Despite multiple distributions being present, the number of interpolation regions, interpolation boundaries, and interpolation types are not defined.
Using the ACEtk features/photonuclear branch, secondary particle information for neutrons released from fission (MT=18) are not found for Am-241 (ZA=95241). From the ENDF file, it is expected that Am-241 would have both multiplicity (MT=452) and energy distribution (MF=5) for photofission neutrons.
Example script:
import ACEtk
tables = ACEtk.PhotonuclearTable.from_concatenated_file("xmc/endf7u")
for table in tables:
if table.reaction_number_block.has_MT(18):
print("{:} has MT=18".format(table.zaid))
rb = table.secondary_particle_reaction_number_block(1)
if rb.has_MT(18):
print(" fission neutrons present")
else:
print("WARNING: {:} does not have fission neutrons".format(table.zaid))
rb = table.secondary_particle_reaction_number_block(2)
if rb.has_MT(18):
print(" fission photons present")
else:
print("WARNING: {:} does not have fission photons".format(table.zaid))
Example output:
92235.70u has MT=18
fission neutrons present
WARNING: 92235.70u does not have fission photons
92238.70u has MT=18
fission neutrons present
WARNING: 92238.70u does not have fission photons
93237.70u has MT=18
fission neutrons present
WARNING: 93237.70u does not have fission photons
94239.70u has MT=18
fission neutrons present
WARNING: 94239.70u does not have fission photons
94240.70u has MT=18
fission neutrons present
WARNING: 94240.70u does not have fission photons
95241.70u has MT=18
WARNING: 95241.70u does not have fission neutrons
WARNING: 95241.70u does not have fission photons
The following error occurs:
error: call to member function 'floor' is ambiguous
With the following:
constexpr auto mev = mega(electronVolt);
auto myA = A{...}
auto result = myA.floor(12*mev)
where:
struct A{
constexpr auto mev = mega(electronVolt);
constexpr auto cm = centi(meter);
constexpr auto cc = cm*cm*cm;
using DenT = decltype(1.0/cc);
using TempT = decltype(1.0*mev);
auto floor(DenT density) const {/*details*/}
auto floor(TempT temperature) const {/*details*/}
};
Resolve error by explicitly passing a double:
auto result = myA.floor(12.0*mev) // 12 -> 12.0
[Future work - documentation]
It doesn't need to be here, but it may be worth documenting the historical convention on handling metastables, namely:
You can rightfully argue that the responsibility is on my team's side to document this. I intend to do so very soon. I just thought it would be easy for someone to have no idea about this weirdness if they're only working on this side.
Originally posted by @cjosey in #48 (comment)
I am trying to separate the elemental tables into individual files. I start with el03 and read each table one at a time and write them to a file labeled <z*1000>.el03
I can read and write all elements in el03 file with no problem when they have only a single isotope listed in IAZW section. For example, the 43000.el03 table looks like:
43097 96.073885 0 0.00000 0 0.00000 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000
However, starting with 44000.el03 something is amiss between reading from the el03 file and writing to the individual file 44000.el03. This is what you would see for 44000.el03 in the el03 file:
44000.03e 100.201894 .000000 06-06-98
44096 95.083699 44098 97.064229 44099 98.056283 44100 99.045987
44101 100.038748 44102 101.028935 44104 103.012819 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000
0 0.00000 0 0.00000 0 0.00000 0 0.00000
After writing to a separate 44000.el03 file you will find the following:
44000.03e 100.201894 0.0000E+00 06/06/98
4409695.08369900 4409897.06422900 4409998.05628300 4410099.04598700
44101*********** 44102*********** 44104*********** 0 0.00000000
0 0.00000000 0 0.00000000 0 0.00000000 0 0.00000000
0 0.00000000 0 0.00000000 0 0.00000000 0 0.00000000
I am trying to use ACEtk to perturb some ace files but can't seem to find input examples. The one here (https://mcnpx.lanl.gov/pdf_files/TechReport_2022_LANL_LA-UR-22-30716_KleedtkeHaeckEtAl.pdf) didn't work after some modifications.
Here is my input so far, please take a look.
import sys
sys.path.append(r"/mnt/c/Users/bamidele/Downloads/ACEtk/build")
import ACEtk
table = ACEtk.ContinuousEnergyTable.from_file( '/mnt/c/Users/bamidele/Downloads/endf_b80_ace/4009.800nc' )
mt_rxn_index = table.MTR.reaction_numbers.to_list()
mt_number = 16
index = table.MTR.index(mt_number)
mt_xs_data = table.SIG.cross_section_data(index)
mt_xs_data_values = mt_xs_data.cross_sections.to_list()
energy_grid = table.ESZ.energies.to_list()
disap_xs_data_values = table.ESZ.disappearance.to_list()
total_xs_data_values = table.ESZ.total.to_list()
perturbed_energy_indices = list(range(1,len(energy_grid)))
perturbation_fraction = 0.2
for k in perturbed_energy_indices:
a = mt_xs_data_values[k]
b = mt_xs_data_values[k] * perturbation_fraction
difference = b - a
mt_xs_data_values[k] = b
disap_xs_data_values[k + mt_xs_data.energy_index] = disap_xs_data_values[k + mt_xs_data.energy_index] + difference
total_xs_data_values[k + mt_xs_data.energy_index] = total_xs_data_values[k + mt_xs_data.energy_index] + difference
new_xs_data = ACEtk.CrossSectionData( mt_xs_data.energy_index, mt_xs_data_values )
old_SIG = [ table.SIG.cross_section_data(i) for i in range( 1, table.NTR + 1 ) ]
old_SIG[table.MTR.index( mt_number ) - 1] = new_xs_data
new_SIG = ACEtk.CrossSectionBlock( old_SIG )
new_ESZ = ACEtk.PrincipalCrossSectionBlock( energies = table.ESZ.energies.to_list(), total = total_xs_data_values, disappearance = disap_xs_data_values, elastic = table.ESZ.elastic.to_list(), heating = table.ESZ.heating.to_list() )
new_Table = ACEtk.ContinuousEnergyTable( z = table.Z, a = table.A, header = table.header, esz = new_ESZ, nu = table.Nu, dnu = table.DNU, mtr = table.MTR, lqr = table.LQR, sig = new_SIG, ang = table.AND, dlw = table.DLW, bdd = tableBDD, dned = table.DNED )
new_Table.to_file( "4009_plus.ace" )
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.