svalinn / dagmc-viz Goto Github PK

Please update the README file to document your additions/improvements and consider removing the (BahsTools) that are no longer required

Generate STL files from the ACIS geometry:

• no graveyard
• one STL file for surfaces
• one STL file for curves

Possibly a Cubit/Trelis Journal file

We should have a standard license added here, probably MIT or BSD 3-clause?

This was requested in #1.

It's very likely that the functionality of this script will be used in other places. Rather than allow it to only operate as a script called from the command line. This module should be made an importable set of code (a module), so that it can be called by modules in this repo without having to setup a command-line call (which is what we do now).

Guidelines for making the code importable are here: https://kkiesling.github.io/python-novice-gapminder-custom/34-importing/.

Right now, TagExpansion.py expands vector tags by using two moab instances of the same mesh file. One is reference mesh, from which all vector tags are deleted so scalar tags can be written. The other is a mesh that the vector tags are extracted from. With the recent update to Moab 5.1.0, this is no longer necessary.

Instead, using the output_tags argument in the write_file method, it can be specified exactly which tags are to be written at a time, and therefore the need for a reference mesh is eliminated.

Additional tool (or options) for generating lists of input variables for #1 in order to make streams of images or movies or gifs

• multi-slices along an axis
• orbit around a 3-D view
• multi-group sweep on tagnames

Move master branch to main branch as default:

• create main branch
• change default branch
• remove master

Some argument parsing was requested by @gonuke and @kkiesling in #7.

This will be a nice way checking that the right information is provided to the script and perhaps also allow users to specify a custom output file name.

Right now we expect the entire name of a group to be "graveyard", but this won't always be the case - particularly in the UWUW workflow where names are required to look like mat:Graveyard.

I think a better check would be to see if "graveyard" exists in the name of that group at all.

Describe the Bug

invalid syntax when running graveyard_removal

To Reproduce

run the command
graveyard_removal dagm.h5m

Expected Behavior

dagmc file should be converted to a dagmc file without the graveyard

Screenshots or Code Snippets

Desktop (please complete the following information):

• OS: ubuntu 18.04
• Python Version: 3.8.3

Additional Context

this can be fixed by changing this line

from
except LookupError , e:
to
except LookupError as e:

Inputs: H5M geometry, mesthal (or equiv from other code), session template
Output: STL geometry without graveyard, VTK data, session file

python or bash script??? (basically a text parsing/replace)

• convert H5M to STL
• convert meshtal to VTK
• search/replace data filenames from session file template

option to only write session file or launch visit with that file
Automatic windows, linked for navigation: Pseudo color of tally, contour of error (Default contours), XY slice, YZ slice, ZX slice, Clip quadrant 1 at center

Option: Tally tagname, Error tagname

Right now the remove_graveyard function will print a warning if a graveyard cannot be found in the specified file and call exit(). Now that this function is called outside of the GraveIdentifyAndRemove.py module, we should probably raise an exception here.

This behavior currently forces users to provide a .h5m geometry with a graveyard to the DataLoading.py script. After updating the remove_graveyard function, the call to remove_graveyard should catch that exception and move on if no graveyard is found in the geometry file.

due to changing rules on dockerhub about maximum number anonymous image pulls, CI needs to be updated here to include the svalinn docker context.

Many, if not all, of the tags used in MOAB .h5m files have predefined tag names and sizes included as part of the pymoab.types module. We should use those when possible so if they are ever updated or changed in MOAB, those names are updated in the visualization scripts as well.

An example of this is:

cat_tag = mb_core.tag_get_handle("CATEGORY")

which would become:

cat_tag = mb_core.tag_get_handle(types.CATEGORY_TAG_NAME)

Right now, TagExpansion.py can only expand vector tags if the given mesh file contains hex elements. An option for the user to change the element type, with the default remaining hex, should be implemented.

Many results in a DAG-MCNP run produce vectors, especially in terms of multi-group energy fluxes, etc. Various tools exist (mostly ad-hoc?) to convert between vector tags (a single tag with an array of N values) and scalar tags (N tags each with a single value).

A useful capability would be to generate data files that are named according to VisIt's convention that allows them to be treated as "database" and easily animate/slider bar between them.

This seems like a useful capability to add here. It might make sense to implement it in a way that can be a standalone tool (overcoming the above mentioned ad-hoc nature) and also be callable from our viz tools.

1. Slice[=args]

   • with no args - default direction and location
   • with args : [(<x,y,z>,val),(<x,y,z>,val),....] produces one image for each tuple with slice at plane <x,y,z>=val

2. Clip[=args]

   • with no args - default octant, rotation and midpoint
   • with args : [{loc:(x,y,z),octant:(+/-1,+/-1,+/-1),rot:(alpha,beta,gamma)},...] produces one image for each dictionary
   • if only partially defined - default rotation depends on octant
   • default position is center of data (not origin and not center of geometry)

3. Threshold=expr

   • expr = tagname > val | tagname < val | tagname = (min,max)

4. Pseudo = tagname [, log|lin, lower, upper]

5. Contour = tagname

Right now, TagExpansion.py only has the capability to expand one vector tag per element in a mesh file. However, it is possible for a mesh file to contain elements with multiple vector tags on each, that are also of different length.

To successfully handle this scenario, TagExpansion.py must include a function that is passed each vector tag and reference length in order to create one database per vector tag.

The bash scripts dealing with the graveyard reuse a lot of the same elements. It should be possible to refactor these into a single script with some command line options.

It's also possible that it may be easier to do it in Python.

There may also be an opportunity for tests.

See here for additions necessary to comply with best practices