Page 1 of 1

Output format

Posted: Wed May 28, 2014 11:29 am
by Jaakko Leppänen
Since the idea is to support group constant generation for a variety of core simulator codes (PARCS, DYN3D, several in-house codes at VTT, etc...), one of the challenges is how to present the group constant output. The way I see it, there are two options:

1) Write separate output routines for different formats, each for a different code
2) Write a general output that is easily read by processing scripts and let them handle the format conversions

There are advantages in both options, and there alredy is the _res.m output that is kind of general, although not necessarily optimal for post-processing (except with matlab).

Since the procedure of group constant generation involves a large number of independent history calculations, it makes a lot of sense to use automated driver scripts that can divide the calculation into separate nodes in a cluster environment for optimum performance. It would also make sense to leave the collection and post-processing of output data for theses scripts, as is done by SerpentXS and STOP, for example. If we take this approach, it would definitely make life easier for us, leaving more time to focus on other issues.

So if we want to make use of a single "standardized" output format (in addition to the current _res.m output), I would like to get some feedback from the developers of these wrapper scipts and users who have made their own solutions as to what is the best approach. What I have in mind is something like this:

Code: Select all

<id> <nr> <nb> <nu>                    % restart index, total number of restarts, number of burnup points, number of universes
<nc>                                   % dimensions of the coefficient matrix
<co_1> <co_2> ... <co_nc>              % combination of bra-cards for this restart (text strings)
<bu>                                   % burnup for this restart
(begin loop over universes)
<uni> <np>                             % universe name and number of output parameters
<ng> <E_0> <E_1> ... <E_ng>            % number of energy groups and group boundaries
(begin loop over output parameters)
<param> <nv> <v_1> <v_2> ... <v_nv>    % parameter name, number of values and list of values
(end loop over output parameters)
(end loop over universes)
Since it is not possible to store the output from previous restart calculations in memory, the data is printed after each restart, and the order in which the branches are listed depends on how the coefficient matrix is set up. Since history calculations are run separately, they will produce separate output files. We could add a history index and/or variables that are passed from input to output, to be used by the processing script to identify the history case. Since the required parameters may depend on the core simulator for which the data is generated, the parameters included in the output is determined by a list of names in the input (for example, using the same names as in the _res.m file).

This is all very preliminary, so any comments and ideas are welcome...

Re: Output format

Posted: Tue Jun 10, 2014 5:41 pm
by pmaxs_umich
With GenPMAXS, we are required to support a variety of codes, like SERPENT, HELIOS, CASMO, TRITON, etc. From this experience, its clear supporting many formats is challenging. For SERPENT, a single format should be sufficient. A wide variety of users take advantage of SERPENT with their own codes, and this appears to generally work well right now. A whole new suite of specialized formats will require significant testing to ensure compatibility and functionality that should really be working now. So, option 2) appears to be the wisest course.

That being said, a good deal of discussion has been given to supporting hdf5 for GenPMAXS. This binary format is more dynamic than current options, and would provide a very efficient format for storage. Just something we can all consider.

The work of collecting and organizing the branches and histories is really the burden of SerpentXS/GenPMAXS. In some sense, a summary of the cases that were packaged and run with the Serpent branching tool would be useful. This could then be taking into GenPMAXS by hand to ease organization. I am not sure how this would look, but its just an idea. The same would be true for histories, as you note below.

With 3D models, consideration of the 3D burnups (each discrete level in a single assembly), would help as well. This may already be resolved in Serpent2.

From the test cases I have for Serpent 2, it appears the user can select a variety of options for outputting Xe/Sm data, Beta, Lamba, XS spectra. For the purposes of simplicity, a default set of outputs that are ALWAYS generated, regardless of the user selection, would be great. That way, if they make a mistake in choosing an option, they will at least have something. This may be similar to Serpent1, where the standard macro XS were always printed, (RABXS, etc.). I have seen cases in Serpent2 where these values were zero, but other XS (infinite spec.) were non-zero.

In final, I may have totally outdated ideas, as most of our testing has been with Serpent1. GenPMAXS does support Serpent2 (2.1.15/2.1.16 are in our suite) at this time. I may have some more ideas and i will update as they mature.

Andrew Ward
GenPMAXS Developer
University of Michigan, USA

Re: Output format

Posted: Tue Jun 10, 2014 7:01 pm
by djw1
I too would opt for a single format.

And I'd think a long time before inventing yet another format.

And I'd want it to be directly assessible to a wide range of languages.
We spend a fair amountof effort converting the matlab format
to a format we can work with in our favorite languages.

hdf5 or maybe even xml for the summary stuff.


Re: Output format

Posted: Thu Jun 12, 2014 4:15 pm
by jesse.johns
I would also agree that a general format be used so that we may simply post-process into our respective formats.

I am also a big fan of hdf5. It might even be advantageous for this to be a general option - opt out of the MATLAB format in favor of the database format for printing detectors, _res and _dep file data as well.

Re: Output format

Posted: Sun Jun 15, 2014 2:50 pm
by Jaakko Leppänen
Thank you for these comments -- I also received useful feedback by e-mail. I think the main limitation in the file format is that the data must be printed in the order in which it is obtained from the calculations, i.e. in the order in which the branches are run. This is because of the way the branch capability is implemented. Changing the order or printing the data in tabular format would require the data to be written in intermediate files and then collecting the results at the end, which considerably complicates the procedure and adding new variables in the output.

I think at first I will stick to the simple ASCII format described earlier (and also keep the existing _res.m Matlab format files), which should be relatively easy to convert to other formats. This is at least until I get some test calculations run, which will probably reveal a lot of things that are still missing. Using a standardized format like hdf5 or xml is a good idea. I will look into these options later. One concern in using a standardized format is that they may require linking to external libraries, which I would prefer not to do, even if the libraries are open-source. I'm already getting a lot of questions about installation, and adding third-party libraries always complicates things. Also, I would need some way of testing the output, meaning an application that would read the data and convert it into libraries that can be used in a simulator code.

Writing a summary file also seems like a good idea. So this file would contain the assembly type, state-point information and burnup, etc., together with directory information on how to locate the data in the files. Both the summary and data files should be formatted in such way that output from multiple runs can be concatenated into a single file. One open question is how to identify the assembly types and branch cases? Would it work to add input variables that are directly passed into the output? Actually, the bra-card is already associated with a name.

As for the 3D burnup, we don't have any plans yet. This is because our goal is set to completing the "conventional" (2D) homogenization methodology within the on-going project that funds our work. This project ends in January 2015, after which we will start looking into 3D homogenization and other "advanced" stuff. Basically it should be relatively easy to calculate the burnup separately for the axial regions, as long as the material zones follow similar axial division.