adding the base structure for on the fly amalgamation

[magnoxemo]

This code change is for doing mesh tally amalgamation in the post processing.

Main goal is if mesh_tally_amalgamation is on and a bin is part of a cluster then we will only store tally in the first element in that cluster. When cardinal will access the raw tally data from openmc it will store the result in other elements in the cluster

[details] (magnoxemo/cardinal#13 )

@gonuke @pshriwise

[magnoxemo]

Documenting my thought process:

Based on in person discussion, for the better performance it will be nice to create a hash map [as $O(1)$] look up time,
of all the bins at the beginning of each openmc run. This way we won't have to look up the first element/bin in the cluster for each individual event.

Not sure if would be better to put in the constructor since MeshTally::spatialFilter() gets called before every openmc run (I need to confirm that with April or Kevin ).

goal

create a hash map where every element in a cluster would map to the first element of in that cluster if the element isn't part of a cluster then it will point to it self. Overall it will be something like this

<any_element_in_a_cluster, first element in that cluster >

I was seeing that openmc creates vectors for element_to_bin and bin_to_element mapping, maybe it would more optimize to use those rather than creating a new hash map?

ps: I need to test if this works or not.

[magnoxemo]

So far the hash map was failing as we only do the mapping when the system is adaptive. Now openmc determines if the system is adaptive or not, by comparing if the number_of_active_element isn't equal to the number_of _total element . Which implies that for every AMR simulation the first run is non adaptive since (number_of_active_element == number_of _total element )

That kinda forces us to create the hash map anyway even if the mesh is adaptive or not. Not sure how that OpenMC folks will think about this, as in case someone isn't doing AMR, that hash map will just hold on to some chunk of memory.

[magnoxemo]

mesh_tally_amalgamation_valid_ = (extra_element_integer_index_ == -1) ? false : true rather than doing this I think it will better to just parse the mesh_tally_amalgamation_valid_ from openmc side and then check throw a fatal error incase mesh_tally_amalgamation_valid_ == true and extra_element_integer_index_ isn't valid.

[magnoxemo]

Documenting my though process:

So I ran the 1D UO2 and graphite slab test case with mesh tally amalgamation on the fly but got the same result as standalone AMR case which was weird as I did saw that clustering process was working just fine, grouping elements where I wanted to see the clustering.

After doing some poor man's debugging, I realized that, this constructor LibMesh::LibMesh( input_mesh, length_multiplier) was in the initializer list for my overloaded constructor (which I thought would be good to avoid code repetition ) and hash map was created there but the other necessary params are getting set in this
LibMesh::LibMesh(libMesh::MeshBase& input_mesh, const std::string& extra_element_integer_name, double length_multiplier) constructor. which caused the hash map to be created before without any clustering information from cardinal. So it was just a standalone AMR case.

Ig maybe I shouldn't worry about code repetition in this case

[gonuke]

Nice addition @magnoxemo - fascinatingly cool that it's a relatively modest change to make this happen.

[gonuke]

I am not sure the final version of get_bin_from_element() is safe when amalgamatation_ is false.

[gonuke]

One last readability fix.

[gonuke]

Some changes from today's discussion

[gonuke]

Nice!

[gonuke]

LGTM

[magnoxemo]

I am going to merge it and open a new PR from mesh_tally_amalgamation to openmc/devel.