Enable use of mesh adaptivity with GrainTextureVectorPostprocessor

[j2bradley]

Description of the enhancement or error report

Enable GrainTextureVectorPostprocessor in the phase-field module to work with non-uniform grids (mesh adaptivity).

Rationale for the enhancement or information for reproducing the error

Currently this VPP only works for uniform meshes, and thus users are required to use high levels of refinement inside grains where it is not needed.

Identified impact

Increases compatibility with existing MOOSE systems (mesh adaptivity).

[dschwen]

What prevents this from working with mesh refinement?

[permcody]

There are assumptions in the element numbering for simplicity. It depends on a structured grid layout right now.

[j2bradley]

The DREAM.3D filter which I am using to process the output requires data of uniform spacing. It needs to know what grain each sampled point in the grid belongs to, with the sampled points being uniformly spaced (with different spacings along each axis ok).

Currently the VPP loops through each element, and outputs the coordinates of the element centroid and the grain to which that element belongs (determined with GrainTracker).

For use with mesh adaptivity, I would like to sample the entire data set with a spacing equal to the highest mesh refinement. So, I need to take multiple samples, so to speak, of the courser grains. I also want to make sure that the solution enables sampling of material properties at these points.

[j2bradley]

@permcody, I am thinking it will be better to just write a DREAM.3D output module for MOOSE if I am going to make this more robust. Daniel suggested using the point locator in PointSamplerBase to just query the mesh by whatever spatial coordinate I want, instead of looping through each element centroid. In that case, I just need to retrieve the mesh dimensions and the highest level of uniform refinement and just feed that into the loop that decides what coordinates to sample.

[j2bradley]

Would that be an AdvancedOutput<FileOutput>?

[permcody]

I'll tag @aeslaughter for advice on building a new output format.

As far as your other idea, that sounds reasonable but I'll tell you there are plenty of complications to this. First, there isn't a way to query max h_level refinement in MOOSE or libMesh. I guess nobody has ever asked for that before so that would have to be added. Alternatively, you could just start simply by looping over all local elements and voting on the max element size before starting your output loop. Also, you'll have to use MPI to gather all your information on the root rank to output it. You can't just output files from all ranks (well you can, it's called Parallel I/O, but that's a huge can of worms in itself).

[j2bradley]

Yeah, no need for Parallel I/O.

[aeslaughter]

@jhbradley I would like to know what the DREAM.3D file looks like before I recommend what type of Output object you should create/inherit from, can you stop by sometime and talk to me about this.

[j2bradley]

Sure.

Here is a photo explaining the format from poissonboltzmann.org

[aeslaughter]

This seems to require a structured grid, how do you plan on handling this if grid is not structured?

On Mon, Aug 29, 2016 at 3:30 PM, John-Michael H. Bradley < notifications@github.com> wrote:

Sure.

Here is a photo explaining the format

[image: image] https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.githubusercontent.com_assets_12360457_18068160_49422e52-2D6dfd-2D11e6-2D8708-2Daae184064fe4.png&d=CwMCaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=h7heP8xwI1i_HikChvhFbEBurKirgfOCdwgBxB9lM8c&m=yCb_W5S3-wcLVa_3_7_hvCJA4Mc-23WnDGfMudqvyEw&s=U5SiAct8annGPlcoB3jA8llchec4zBffDZKovkG4gqg&e=

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_idaholab_moose_issues_7308-23issuecomment-2D243262849&d=CwMCaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=h7heP8xwI1i_HikChvhFbEBurKirgfOCdwgBxB9lM8c&m=yCb_W5S3-wcLVa_3_7_hvCJA4Mc-23WnDGfMudqvyEw&s=_X5wMiECTIwl0PvttHYQtCS952bBiC1oxzzZu-xHUOA&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAU1VR1qUiZ9OfT-5FHQU8DKZ8jVSPN5wmks5qk097gaJpZM4JJuqW&d=CwMCaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=h7heP8xwI1i_HikChvhFbEBurKirgfOCdwgBxB9lM8c&m=yCb_W5S3-wcLVa_3_7_hvCJA4Mc-23WnDGfMudqvyEw&s=NglUvHl2BeWqWnJhDObVVQrT4nHqY6QgBJLDXn84_u8&e= .

[j2bradley]

There are two possibilites. @dschwen suggested using the point locator in PointSamplerBase to loop through any spatial coordinates we want and query the mesh at those locations. This would require simply knowing the mesh dimensions and the max_h_level if using adaptivity.

Second, we could make an output that uses oversampling, and then loop through each element on the oversampled mesh. We would again need to know the maximum refinement level currently in the mesh in order to have an oversampled mesh of appropriate refinement.

[j2bradley]

Additional comments on file format

With our data, u is just the number of the grain that the spatial location we have queried belongs to.

DREAM.3D currently has some inconsistencies between their filters and the OpenDX file format:

One, The DREAM.3D filter which reads the OpenDX format requires that the values nx, ny, nz, where listed individually, be replaced with the values nx+1, ny+1, nz+1.

Two, DREAM.3D assumes a sorting where the x-index increases most rapidly, then the y, then the z, instead of the other way around. I have made the developers aware of these errors, but there is no telling when they will be fixed.

Second output file required

Another complication is that _there is actually a second input file_ that is required by DREAM.3D for the texture analysis. This is simply a text file with the total number of grains appearing at the top, with a list following of each grain (1st column) in ascending order and its phase (2nd column) and Euler Angles (in radians) as follows

123 1 2 1.2 0.4 0.8 2 1 0.8 0.99 1.0 ..... 121 1 0.3 0.5 0.9 123 2 1.0 1.1 0.03

This was easy enough to generate from the GrainTextureVectorPostprocessor output, but I am not familiar enough with the output system to know if it presents significant complications to output two files with one output module.