In the following it is assumed that the r2smesh is installed (according to ../deploy.rst) to ~/work/r2smesh-at and the files relevant to particular SDDR calculations are in ~/calcs/SDDR/problem1. The latter folder is reffered to as the problem working place. First, go to the working place:
>cd ~/calcs/SDDR/problem1
The activation driver looks for the input files in the input subfolder in the working place. The following files are required:
input/meshtal.fine # meshtal with neutron flux intensities input/meshtal.coarse # meshtal with neutron spectra input/fine_mesh_content # material allocatiaon in the mesh input/mat_table # Material compositions input/cmi_table # Cell and material indices, names and densities. input/inventory_input_footer # Irradiation scenario in fispact format. r2s_env_local.sh # optional, script to change default file and directory names In the simplest case, only one of these files must be prepared by hands: this
is the file containing irradiation scenario input/inventory_input_footer.
The other files are obtained by processing the MCNP output files.
Files meshtal.fine and meshtal.coarse are parts of the meshtal file, as
generated by the standard MCNP5 during neutron transport. Assuming that in the meshtal
file written by MCNP5 the first tally correponds to the fine mesh with neutron
flux intensities and the second tally -- to the coarse mesh with neutron flux
spectra, the following commands create necessary files:
> csplit meshtal '/Mesh Tally /' '{*}' # split meshtal at lines containing "Mesh Tally " to xx?? files
> mv xx01 meshtal.fine # xx00 contains meshtal header (mcnp version prodid, nps)
> mv xx02 meshtal.coarse # xx01 and xx02 contain the 1-st and 2-nd tallies.
The material allocation file fine_mesh_content is prepared by MCNP5 modified with the ../mcnp-mod/kit-materials.patch.5 patch (later refered to as MCNP-md). MCNP-md can be started on the same MCNP input file that was used for the neutron transport, but the IDUM card with two entries must be added: the
first entry specifies the number of hits per cm3, and the second entry specifies the mesh tally
number where materials will be detected (usually, this is the fine mesh used
for neutron flux intensity). One can use an existing runtpe file from the
neutron transport (one can thus save initialization time!) and perform a continue
run with the following continuation input file:
continue nps 50000001 $ set nps above the value reached in the runtpe print 40 $ skip extra print tables, which can be big idum 100 4 $ sample 100 points per cm3 in meshtally 4
MCNP-md must be started with at least 2 MPI processes. It
generates N-1 (N -- number of MPI processes) outcellsI files, where I starts from 1
to N-1. These files must be concatenated into a single file, which can be used
as fine_mesh_content. Script combine.sh can be used
for this, simply run it in the folder with the outcellsI files.
MCNP-md prints two additional print tables to the outp file. Table print table FIS contains material compositions in the FISPACT
format (suitable for the FUEL keyword) and table print table CMI
contains cell names, material indices and names and cell densities and
concentrations. These tables can be extracted with the script
extract_tables.sh, which takes as the 1-st argument the name of the outp
file.
Assuming that MCNP-md was run in the md subfolder:
> cd md > ~/work/r2smesh-at/scripts/combine.sh # combine outcellsI to fine_mesh_content > ~/work/r2smesh-at/scripts/extract_tables.sh outp # extract tables from outp > ># put files to input subfolder > cd ../input > ln -s ../md/fine_mesh_content . > ln -s ../md/mat_table . > ln -s ../md/cmi_table .
The irradiation scenario must be given in inventory_input_footer. A
template for this file can be found in ../files/inventory_input_footer . Copy this
template to input and modify as necessary. Values for the FLUX keywords
are used to multiply flux intensity from meshtal.fine and thus depends on
the tally multiplier applied for neutron flux intensity. For ITER applications
with the standard neutron source and no tally multiplier, the value 1.973e19
after the FLUX keyword corresponds to 500 MW level and has units neutrons
per second.
All names of the input files are passed to the activation driver via environment
variables. Their default values are set with the ../scripts/r2s_env.sh script, which must be sourced from the working place. If the file r2s_env_local.sh is present in the working place, it will be sourced as well, thus giving the user
possibility to change the default values (e.g. to set the custom scratch folder):
> cd .. # return from the input subfolder to the working place > . ~/work/r2smesh-at/scripts/r2s_env.sh
Inventory calculations (fispact runs) are driven by ~/work/r2smesh-at/adriver/adriver.exe that can be run in parallel using MPI, or as a usual
sequential executable (useful for testing). The r2s_env.sh script sourced above created the
$r2s_driver variable, which points to adriver.exe. To ensure that the updated environment variables are
passed to the driver, always source r2s_env.sh before starting the driver:
> . ~/work/r2smesh-at/scripts/r2s_env.sh # this defines $r2s_driver > $r2s_driver # start the driver.
During the driver execution two folders are created, out and log
(actual names can be changed in r2s_env_local.sh).
Decay gamma intensities at each fine mesh element at every time interval are written
to files out/cgi.I,J.K, where I, J and K are indices of the
correspondent coarse mesh element. After successfull run, the out folder
contains files for each coarse mesh element where activation calculations were
necessary (i.e. where non-void cells were irradiated with non-zero neutron
flux and activated material has non-zero gamma source at particular time
interval).
UPD: A complete cgi file ends with the line containing single underscore
character _. This line can be considered as a marker for the completeness
of the cgi file. The situation when an cgi file exists but its last
line is not _ means that the writing process was interrupted and there are
chances that not all information was written to this cgi. Such files must
be discarded (deleted) and the activation driver started anew, with the
r2s_continue variable set to yes (set this in the r2s_env_local.sh
script). A list of cgi files without the _ completeness marker can be
obtained with the ../scripts/check_cgi.sh script.
Log information from each MPI process is written to log/log.i file, where
i is the process id (0 for the master process that reads all input data and
distributes job, and 1 to N-1 for the slave processes that actually start
fispact, where N is the number of MPI processes).
When the driver completes succesfully, the master log file log/log.0 contains at the last line
========== 2019/04/26 00:10:31 Program completed.
As the next step, the out/cgi* files must be postprocessed to obtain decay
gamma sources for particular irradiation time. The ../scripts/form_dgs.sh
script accomplishes this task. It requires the folder with cgi files as the
1-st command line argument, followed by the irradiation time step indices. The
script generates dgs.NN files, where NN` corresponds to the irradiation
time step index.
> ~/work/r2smesh-at/scripts/form_dgs.sh out 45 46 # form sources for time intervals 45 and 46 from files in out
For the above command, two files will be created:
out/dgs.45 and out/dgs.46.
Note
Note for Marconi cluster: it seems the $WORK file system is cached, i.e.
the second reading of a file is much faster. For this reason, it is better
to run form_dgs.sh script with all necessary time interval numbers at
once, than calling it separately for each time interval:
> form_dgs.sh out 45 46 47 48 49 50 # this is faster than the next > form_dgs.sh out 45 > form_dgs.sh out 46 ... > form_dgs.sh out 50
The decay gamma source can be used by MCNP5 modified with the ../mcnp-mod/kit-gamma.patch.5 patch. If no source is specified in the MCNP input
file, it reads the dgs file and samples photos accordingly (the dgs
name is hardcoded). The dgs file is not stored in runtpe file, which has two
consequences: (1) the dgs file must be availabe at continue run. (2)
Another dgs file can be used in the continue run. In this way, the
initialization time can be saved, by generating runtpe with nps set to 1 only
once, and using this runtpe with different dgs files.