-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Smoothing two-stack microstructure - jutting nodes after smoothing #10
Comments
@sgbaird it's difficult to tell without more information on your volume. How are the nodes labeled in your example? What are the This might have something to do with what you're seeing. h-smooth believes whatever mesh you give it in the Since you're dealing with a 3-layer (2-voxel) structure, you should try this: artificially re-label the nodes on the "rim" in all 3 layers as a triple line (3, 13), possibly bound by quad points (4, 14) if known in advance, and then run h-smooth. By this I mean use a new, custom Back in the day I didn't bother adding a 2D smooth capability to h-smooth, because you can easily "hack" the 3D smooth for 2D meshes with the correct re-labeling of the nodes. Proper smoothing really depends on the Let me know if this hack works... |
Thanks for your suggestions! Isoview:
Also, since the first grain was a pretty good candidate to show what I'm trying to accomplish on a higher level, here is the side-view "interpolation" that I'm essentially hoping to get in the end by whatever means necessary: |
Also, to give a little more context, DREAM.3D's Laplacian smoothing filter starts to do what I'm hoping for, but despite trying different parameters the outer surfaces either always retained their "blocky" appearance or made strange distortions to the outer surfaces (latter not shown here). This (and a post on the DREAM.3D google groups forum) were what originally led me to look at using h-smooth. |
Hi @sgbaird , There might be a problem because of the size of the Z-axis separation of the layers, relative to the mesh size in the XY plane (assuming the isosurfaces you've shown have aspect ratio 1:1:1). You might try artifically compressing the Z-dimension of the grain to be comparable to the size of the XY discretization (i.e., the size of the mesh element). This will involve changing the Z components of your nodes. Then attempt the smoothing, and finally apply the inverse Z-scaling operation on the smooth nodes. By doing this, you might stop the nodes jutting out like that. I can't guarantee that you'll get the smooth variation from layer to layer that you're looking for, but you might reduce the "steppiness". If the nodes still jut out, then I'm out of ideas! Other than blaming it on possibly poor meshing, because I know for sure that if the mesh is topologically sound, h-smooth will work! I am, however, curious. Can you share a data file for that particular grain (nodes, tri, ntype, fl) that I can load in Matlab? I'm quite busy these days, but I'll play with it in my free time and see what I can glean from it. |
Just to comment that we started to integrate the H-smooth into DREAM3D here but ran into problems that stem from a commit that we put into the QuickMesh to try to "fix" some bad nodes (Commit 1ed41586a0bf7e9c528a11dd65c2530aa1d7682d) which I think we got as far as figuring out that this caused some of the issues with the H-Smooth algorithm. Unfortunately I don't have any kind of timeline as to when the code will be completed. |
Apparently @jercgreen6 ran into some problems with nodes jutting out, even though the microstructure he was using is fairly straightforward (cube with "normal" looking grains). Additionally, he mentioned that he's only seeing the issue with the C++ code, but not the native (slow) MATLAB version. @jercgreen6, could you comment more on this? |
Initially I set up the MATLAB version of Hierarchical Smooth to verify that the code would do what I wanted it to do. Other than computation time the results were ideal so I set up the C++ version. I modified my MATLAB script which I use to run Hierarchical Smooth to match the input arguments and remove the buffer elements. However, I get very different results between the two codes for the same microstructure. The C++ version produced spikes in the microstructure similar to what was shown by @sgbaird. I also get the same warning: This has occurred for all of the microstructures that I have tried. Microstructures were produced using Dream3D.
Included in the zip folder is the data that I used as the input to Hierarchical Smooth. @siddharth-maddali Do you have any ideas on what is going wrong here? Do you have suggestions on how to address this issue? Thanks! |
@jercgreen6, nice explanation. I wonder if you get the same kind of results using f = find( any( fl > 0, 2 ) );
tri = tri( f, : );
fl = fl( f, : ); before running it through All-in-all a strange issue and the inconsistency between versions suggests a possible bug. How urgent is it (days, weeks, etc.)? Also, @siddharth-maddali, sorry for not including a dataset before. Hopefully the one @jercgreen6 included will be enough to resolve the issue. Thanks in advance for the help! Let us know when you get this and what your thoughts are |
For the examples I still get the error about some of the nodes not smoothing in the C++ code (they work fine for the MATLAB code). This would suggest that it is either how I am interfacing with the code or an issue with the code itself. I am in the troubleshooting phase to try an figure out what is going on. I do remove the buffer elements before running the code. I tried running it without removing the buffer elements and more of the nodes smoothed but there were still a large amount which did not. A solution within 2 weeks would be ideal but not required. |
@jercgreen6 do you still get the "jutting nodes" with the examples via C++? @siddharth-maddali had mentioned to me in #9 (comment) about why some number of nodes aren't smoothed, but this didn't seem to be a major problem. |
It would appear there's also a difference in indexing the triangulation between the MATLAB and C++ versions. For the MATLAB version, based on the documentation, I think it's: Whereas for C++ MEX version I'm guessing it's just: Just trying to think through any possibilities other than an error in the C++ code which will probably be more painful to figure out. |
@sgbaird
As far as your comments on indexing being the issue. I tried running the code with and without adding 1 to the tri variable. The results are shown here: Alternatively, the closest that I have been able to get to things actually working are shown here. Previously I was using the fscanf command instead of the load command. I don't know why this would make a strong difference bet it seemed to help. At this point all that I know is that the smoothed vertices that I am getting out of Hierarchical Smooth do not match what is recorded as the example output. I'm not sure if that is to be expected using the Hierarchical Smooth algorithm. About 25% of vertex locations are the same (determined using nnz(MySmoothedVertices == ExampleSmoothVertices)) but 75% are different. @siddharth-maddali After running Hierarchical Smooth should my output files exactly match the example smooth file? |
@jercgreen6, looks like you're getting closer. Assuming you're using the latest version now, perhaps try using a 2018 version of DREAM.3D? From what I'm seeing, it doesn't seem like an internal error in the C++ code so much as a version incompatibility or maybe a data processing issue. I think a MWE for the DREAM.3D output process and |
@jercgreen6 @sgbaird Thanks for letting me know. I'll get back to you as soon as I can. |
I hope this helps! I need to look into why |
@jercgreen6 I haven't worked with Dream.3d in a very long time, so I don't know about new changes to the indexing or labeling conventions. The code snippet above will give you the smoothed microstructure that you see in the animation at the top of |
@jercgreen6 Here is Octave code that deals with example 1, in which I've called the C++ routines in a wrapper. I'm not seeing significantly jutting nodes.
|
I finally got around to trying out the C++/MATLAB version again using the ex2 data, and got the following: While inside the folder = fullfile('..', '..', 'examples', 'ex2');
xdat = load( fullfile(folder, 'SharedVertexList.txt') ).';
tri = 1 + load( fullfile(folder, 'SharedTriList.txt') );
fl = load( fullfile(folder, 'FaceLabels.txt') );
f = find( any( fl==-1 | fl==0, 2 ) );
fl( f, : ) = [];
tri( f, : ) = [];
ntype = load( fullfile(folder, 'NodeType.txt') );
whos
xsmooth = HierarchicalSmoothMatlab( tri, xdat, fl, ntype );
t = num2cell(xsmooth, 2);
trisurf(tri, t{:}, 'EdgeColor', 'none')
axis equal I compiled it on Linux with a modified Makefile (just the CC= ... line changed) CC= /apps/gcc/6.3.0/bin/g++ in order to compile with gcc 6.3. I modified mex -glnxa64 ...
-I./Eigen ...
-I./libigl/include ...
-I/usr/include ...
-I. ...
-v GCC='/apps/gcc/6.3.0/bin/g++' ...
HierarchicalSmoothMatlab.cpp libhsmooth.a I had the most recent versions of Eigen and libigl cloned into my folder via: git clone https://gitlab.com/libeigen/eigen.git (per the instructions at Eigen) git clone https://github.com/libigl/libigl.git At first glance, the plot looks OK to me. Nothing really jumps out as being unphysical. @jercgreen6, can you run the MATLAB code (first code snippet) and post the plot that you get? Curious if you're getting the same output. If you have some code you want me to try, I can give that a go. |
@sgbaird However, if I use the exact same code for files that I made with Dream3D I still encounter issues. For half of the microstructures I get some type of error which stops the code. The code runs to completion for the other microstructures but they come out spiky. I think the changes may be caused by variations in the Dream3D output files. The hierarchical smooth example files don't work with most of the code that I use for other Dream3D data and the Dream3D data that I make doesn't seem to be working well in Hierarchical Smooth. I uploaded a couple .txt files that I used here: @sgbarid Do you get the same output that I do for the spiky microstructure? |
@jercgreen6 try swapping the columns in FaceLabels.txt in the "spiky" dataset immediately after import using |
AKA folder = fullfile('..', '..', 'examples', 'ex2');
xdat = load( fullfile(folder, 'SharedVertexList.txt') ).';
tri = 1 + load( fullfile(folder, 'SharedTriList.txt') );
fl = load( fullfile(folder, 'FaceLabels.txt') );
fl = fliplr(fl);
f = find( any( fl==-1 | fl==0, 2 ) );
fl( f, : ) = [];
tri( f, : ) = [];
ntype = load( fullfile(folder, 'NodeType.txt') );
whos
xsmooth = HierarchicalSmoothMatlab( tri, xdat, fl, ntype );
t = num2cell(xsmooth, 2);
trisurf(tri, t{:}, 'EdgeColor', 'none')
axis equal FaceLabels.txt:
Notice how the "-1" seems to only ever appear on the right in ex2 and only ever on the left in "spiky" |
@sgbaird We remove any of the face labels that feature a -1 before the smoothing occurs:
|
I was really hoping that would fix it. Taking a second look, I guess that also makes sense that those rows are removed, so the order probably wouldn't matter. My next best guess is to manipulate SharedTriList.txt. There may be something strange going on with the order. Notice the difference between the first few lines (same pattern across the board as far as I can tell):
This could be messing with some notion of which direction the plane normals are pointing within the code. You can flip columns 2 and 3 via which would cause the updated script to be: folder = fullfile('..', '..', 'examples', 'ex2');
xdat = load( fullfile(folder, 'SharedVertexList.txt') ).';
tri = 1 + load( fullfile(folder, 'SharedTriList.txt') );
tri(:, [2, 3]) = tri(:, [3, 2]);
fl = load( fullfile(folder, 'FaceLabels.txt') );
fl = fliplr(fl); %probably unnecessary, but might as well leave it to make the versions consistent
f = find( any( fl==-1 | fl==0, 2 ) );
fl( f, : ) = [];
tri( f, : ) = [];
ntype = load( fullfile(folder, 'NodeType.txt') );
whos
xsmooth = HierarchicalSmoothMatlab( tri, xdat, fl, ntype );
t = num2cell(xsmooth, 2);
trisurf(tri, t{:}, 'EdgeColor', 'none')
axis equal Still same issue? |
@sgbaird I also tried multiplying the first and third columns of xdat to match the signs of the example file. This rotates the cube as expected while still maintaining spikes.
|
Darn.. Here are some other observations I made: NodeType.txtIt's maybe worth noting that there are 346730 nodes in ex2 and 13886 nodes in ex1. 2
3
4
12
13
14 The histograms of the various NodeTypes are also similar: SharedVertexList.txtIn "spiky" the values are all positive. In ex2, some values are negative. I doubt this would make a difference. Just has to do with the center of the microstructure. You tried changing this and had the same issue though. Other CommentsTry with a similar number of grains/resolution as in ex2. Do you get the same behavior? Here's a look at the input microstructures: "spiky" obviously has fewer grains but the resolution is probably about the same and I don't notice anything wildly different qualitatively. @siddharth-maddali, looks like the code works fine for the examples, but not for the data @jercgreen6 is working with. |
@siddharth-maddali What's still particularly disconcerting is that I verified the pure MATLAB code seems to work just fine on @jercgreen6's data: |
In other words, since formatting of the input files doesn't seem to be an issue (based on the troubleshooting here), this suggests a bug with the C++ code implementation. Just for an easy download for myself: spiky.zip |
@jercgreen6 @sgbaird Can you try out the following and see what happens: |
@siddharth-maddali, good suggestion. Thank you for getting back on this. I got my supercomputer account renewed and was able to run the MEX function. It still appears spiky, whether smoothing the full microstucture or a single grain. Select Spiky GrainCodeI selected grain #10 and renumbered the i = 10;
ids3 = any(fl2==i, 2);
tri3 = tri2(ids3, :);
fl3 = fl2(ids3,:);
tri3u = unique(tri3);
xdat3 = xdat2(:, tri3u);
ntype3 = ntype2(tri3u,:);
nmax = max(tri2,[],'all');
npts = length(tri3u);
for i = 1:npts
tri3(tri3 == tri3u(i)) = i+nmax;
end
tri3 = tri3 - nmax; DataHere's the data for grain 10: subgrain.mat direct download, with the Full Microstructure Smoothing(left) Original, (right) Pure MATLAB:(left) Original (right) MEX:Single GrainThe following is after condensing to a single grain, and then smoothing just the one grain: Pure MATLAB:xsmooth3 = HierarchicalSmooth( xdat3, tri3, fl3, ntype3 ); MEX:xsmooth3 = HierarchicalSmoothMatlab(tri3, xdat3, fl3, ntype3 ); |
@sgbaird The first thing I noticed with the single-grain data set that you shared, is that running the C++ code gives me a warning that about 1/3 of the nodes weren't smoothed. This is concerning, because it means the algorithm couldn't resolve much of the nodes in that dataset, into a well-behaved hierarchy. By this I mean interior (albeit pixelated) surface nodes, bound by triple line nodes on the outer rim, in turn bound by quad points. This is usually a result of faulty labeling of node types (faulty with respect to the algorithm!). Here is an image of the migration of 'smoothed' nodes from their original position, as you can see very few of them have moved. Is it possible to work with a microstructure with finer discretization? This would resolve a lot of these topological problems you're seeing. I realize this is hard, seeing as real-world data is what it is...! |
Thanks @sgbaird @jercgreen6 for pointing out the potential bug, I will definitely look into it! |
@siddharth-maddali thanks for the reply! I know this is a rather old project and things can get very busy. Appreciate you taking the time. @jercgreen6 what about for the test microstructure you have? It would be good to verify that increasing the resolution is one way to resolve the behavior just to make sure nothing else strange is going on (though probably not the solution for your use case). Is that feasible with the pipeline you have? |
@sgbaird No problem, happy to help! |
You could revert to Laplacian smoothing for the misbehaving nodes, it doesn't discriminate between node types. But of course, you'll lose the benefit of faithful smoothing... |
Hi @siddharth-maddali,
Thanks for your help so far. I've been plotting the grains after doing h-smoothing and have been getting some strange results. See for example:
![image](https://user-images.githubusercontent.com/45469701/80677448-1f0de600-8a76-11ea-8c83-6a7497155f67.png)
I also get:
which may be related to the quad points being too close together as you mentioned before, or it could be an issue of having a thickness of only 2 voxels in the z-dimension (I have EBSD data from both sides of a sample with a large proportion of through-thickness grains).
Using the sample data produces expected results:
![image](https://user-images.githubusercontent.com/45469701/80677287-e79f3980-8a75-11ea-843e-3d1ba8feebb9.png)
If I apply DREAM.3D's laplacian smoothing filter before doing the hierarchical smoothing, I get the following, where on further inspection, it seems the triangles that "jut" leave concave "divots" in the grain.
![image](https://user-images.githubusercontent.com/45469701/80677846-ecb0b880-8a76-11ea-8a40-4f9c4fd0d8e5.png)
with the following workspace:
One round-about way I might deal with this is turning the 2-stack into a 4-stack by copying the stacks above and below as appropriate and cropping it afterwards, but I'm worried this would have the artificial effect of the grain boundary always being normal to the surface when it's close to the surface.
Another similar approach would be breaking up the interior into multiple voxels, though I'm not sure how I would go about this.
Do you think this is an inherent limitation of the method for this unique use case?
The text was updated successfully, but these errors were encountered: