repositony / meshtal Goto Github PK

The major change with the release of version 6.3 is that except for none and xdmf, all output formats for the FMESH are deprecated. These formats may still be output as before but will no longer be developed for future MCNP versions.

This means that going forward it may be better to pivot toward assuming HDF5 as the default use case. It is unclear if this support should be behind a --hdf5 feature flag that implements to/from Mesh traits for conversion and interoperability.

There is also the introduction of COLSCI and CFSCI output variants for the legacy meshtal output formats. This should be fairly trivial to implement.

There should be a way to turn off parsing data and collect only the header information.

This would speed up basic checks significantly, such as checking the dimensions of a mesh. Right now the entire tally is read even if you just wanted to check what particle type it represents. For the vast majority of cases the read is extremely fast, but for large 5-10GB size meshes this can take a couple of minutes.

This information is consistent across most output types, only UKAEA CuV would need special treatment.

For example, the conversion of a cylinder with 4 theta bins is square. But what happens when there are only 1 or 2 bins in total?

• Perhaps enforce a minimum of 3 verticies for 1 theta bin, and 4 verticies for 2 theta bins to make triangular approximations
• Must warn the user that this is what happened in the background
• This will look horrible, so also suggest --resolution is used

This needs testing and a solution implemented in the vtk module implementations.

A general consensus from those with far more experience, it is usually better to have junk over analogue that can be updated in later iterations.

Small update to mesh2ww will therefore be to set the default --error to 1.0

All of the traits that are appropriate and intuative should be implemented for the Mesh object at least.

See std::core for details.

Being able to combine and mess around with meshes via the command line will be a very easy tool to build on top of the core famework.

For example, perhaps there are multiple runs of the same mesh that should be combines into one. Other ideas include:

• multiplication/division of constants (no different to scale())
• raise all voxels to some power factor
• addition/subtraction of constants, or one mesh with another of the same geometry
• averaging of several meshes of the same geometry
• min/max of several meshes of the same geometry

No idea why someone would want half of these but no harm in giving people the option.

Note that all of this will also need a way of writing to a new meshtal, which could be difficult. Information is lost during the parse to coerce all possible meshtal output formats into the same structure. This will therefore be limited to the COL ascii format or a lossy HDF5.

Writing to VTK is very simple and already uses the existing framework.

Should be able to use a wildcard to indicate all groups. For example:

(energy, time, x, y, z)
1.0   1e12 1.0 2.0 3.0
10.0  1e12 1.0 2.0 3.0
1e6   1e12 1.0 2.0 3.0
Total 1e12 1.0 2.0 3.0

This should be easily requested with a wildcard * to mean just find every energy group

(energy, time, x, y, z)
 *  1e12 1.0 2.0 3.0

It would also work for coordinates, for example every voxel in x at the same y and z coordinate

(energy, time, x, y, z)
 Total  1e12 * 2.0 3.0

Currently there may be confusion around what 4 values represents. This would be far more explicit and clearly separate basic use (x,y,z only) from advanced use (e,t,x,y,z) as having either 3 or 5 values.

This should be simple to implement, with a special character for the parser and just calling mesh.energy_groups() and mesh.time_groups() for the groups, and something like the mesh.voxel_coordiantes() source that just loops over imesh/jmesh/kmesh and collects every midpoint between bounds.

The old v6.2 output formatting is a nightmare for values of energy and time groups that are too close together. The .2e precision is ridiculously imprecise and restricts the use of --energy and --time options on the mesh2vtk tool.

Times a few minutes apart are inseperable at 1e15 scales like this and end up duplicating time groups for tmesh. Currently the main implementation takes the first it finds, but there needs to be a way to ask for groups by index.

In fact, index should probably be the default and have a flag for using the absolute values but checks for these precision issues if there are duplicates. Something like:

# default take the index of groups
mesh2vtk file.msht 14 --energy 0 1 3 --time 5 6 7 total 

# or if you really want to use actual values
mesh2vtk file.msht 14 --energy 1.0 20.0 --time 1e15 1e36 --absolute 

This check should be added after the parse to warn users about an issue with precision.

Should be able to update weight windows over multiple runs.

For example, the current implementation is simple,

• get original mesh
• generate weight window file

But what if this is done multiple times?

• get original mesh
• generate weight window file
• new mesh using weights
• generate weight window file
• new mesh using weights

However, it can not be assumed that the next run will always produce better results for the next weight windows set.

Feature

Instead of generating a brand new set of weights every time a simulation produces a new mesh, the previous weights should be updated and iterated upon.

Rules for updating could be as simple as updating the weight for a voxel if the error in flux is less than it was in the previous run.

Issues

This must require either reading in the pervious mesh data again (assuming it has not been overwritten or deleted), or generating new files to keep track of the previous dataset. Either works, but there is probably a choice to be made about which is best as a few extra files will be needed:

• Files for string the previous mesh results (or could re-parse old mesh directly, which would be slower)
• Possibly keep the previous weight window file

There needs to be a smart way of doing this to mitigate memory usage when comparing meshes. The best case would be to read the new mesh, and compare against a buffered byte stream from a binary of the previous mesh uncertainties. The result will be a small vector of boolean values indicating whether or not to update the weight.

Of course, this whole thing may also require a reader for WWINP files, which was on the todo list anyway.

When a point is exactly on the boundary of multiple voxels, this needs to be well defined behaviour for the user.

Current behaviour is to favour the low edges of mesh boundaries.

if &value >= low && &value < high

Ideally we need to:

• Detect when a point is on a boundary
• Collect all voxels involved (complicated by r=0 cylindrical)
• Average the voxels
• Inform the user that this has happened

The immediate action is to note this in the pointextract help messages. This is all already explained in the main documentation.

Documentation can easily be built using github actions, and then published to pages.

This will provide an online reference for the crate that is easily accessible and does not require anyone to clone the repository and run cargo doc --no-deps themselves.

Someone wanted to use the advanced usage of mesh to weights, which would need bringing into the CLI for most. This should be simple to implement.

If the --power and --error parameters are moified to take an array of values instead of one, then the only change needs to be switching from a call to the usual function to the advanced function.

Basic call for single --power/--error values is:

pub fn mesh_to_ww(mesh: &Mesh, power: f64, max_error: f64, total_only: bool) -> WeightWindow`

So if --total is abasent as an argument, and there is more than one value in either --power or --error, then they can just be passed to the advanced function instead. This will handle all the issues itself which makes this an easy addition as the work is already done.

pub fn mesh_to_ww_advanced(mesh: &Mesh, powers: &[f64], max_errors: &[f64]) -> WeightWindow

The only foreseen issues will be things like the user mixing intent, which will have to handled sensibly with warnings. For example, someone could request

mesh2ww run1.msht 104 --power 0.81 0.70 0.85 --total

This makes no sense as just using the 'Total' bin will only need one power factor, so a special case like this should either use the default or take the first power value found.

The best course of action is TBD for issues like this.