Some tests failed

[tianjuxue]

Hi Nicolò,

Thanks for your great open-source code. When I run the tests, some of them failed. Among them, I'm particularly interested in the neper example. It seems that the output .e file is different from the provided gold .e file.

I'm using Mac OS X 11.6.5 with the latest MOOSE installed.

Appreciate it if you can take a look.

Thanks, Tianju

[ngrilli]

@tianjuxue my experience is that tests never fails on Ubuntu, but when I pull the code on CentOS, some ExoDiff appears. I have never tried on MacOS. I checked carefully several of these tests in the past and could only solve the exodiff by increasing the tolerance of exodiff. I am pretty sure it is related to the numerical precision of different platforms and does not affect the functionality of the code.

[ngrilli]

Of course, if you just want to get rid of the error message, you can copy the results file *_out.e of those particular tests inside the corresponding gold directory. In that case you have a test result that matches your machine and you don't see the error anymore, even if you pull new versions of the App in the future.

[ngrilli]

Thank you for testing this App, the neper example is just the basic way to generate a polycrystal and run the crystal plasticity simulation. Let me know if you find problems using it. Hopefully I can have better documentation and instructional videos in the future.

[tianjuxue]

Thank you for the explanations. I agree that most likely it is due to machine precisions. In the neper example, you mentioned that the raw .msh file generated by Neper is not compatible with MOOSE. What I've found is that the file seems to actually work with MOOSE. In fact, as long as the file contains Nodes information and Elements information, it works. For example, the following .msh works just fine.

$MeshFormat
2.2 0 8
$EndMeshFormat
$Nodes
64
1 0.000000000000 0.000000000000 0.000000000000
2 1.000000000000 0.000000000000 0.000000000000
3 2.000000000000 0.000000000000 0.000000000000
4 3.000000000000 0.000000000000 0.000000000000
5 0.000000000000 1.000000000000 0.000000000000
6 1.000000000000 1.000000000000 0.000000000000
7 2.000000000000 1.000000000000 0.000000000000
8 3.000000000000 1.000000000000 0.000000000000
9 0.000000000000 2.000000000000 0.000000000000
10 1.000000000000 2.000000000000 0.000000000000
11 2.000000000000 2.000000000000 0.000000000000
12 3.000000000000 2.000000000000 0.000000000000
13 0.000000000000 3.000000000000 0.000000000000
14 1.000000000000 3.000000000000 0.000000000000
15 2.000000000000 3.000000000000 0.000000000000
16 3.000000000000 3.000000000000 0.000000000000
17 0.000000000000 0.000000000000 1.000000000000
18 1.000000000000 0.000000000000 1.000000000000
19 2.000000000000 0.000000000000 1.000000000000
20 3.000000000000 0.000000000000 1.000000000000
21 0.000000000000 1.000000000000 1.000000000000
22 1.000000000000 1.000000000000 1.000000000000
23 2.000000000000 1.000000000000 1.000000000000
24 3.000000000000 1.000000000000 1.000000000000
25 0.000000000000 2.000000000000 1.000000000000
26 1.000000000000 2.000000000000 1.000000000000
27 2.000000000000 2.000000000000 1.000000000000
28 3.000000000000 2.000000000000 1.000000000000
29 0.000000000000 3.000000000000 1.000000000000
30 1.000000000000 3.000000000000 1.000000000000
31 2.000000000000 3.000000000000 1.000000000000
32 3.000000000000 3.000000000000 1.000000000000
33 0.000000000000 0.000000000000 2.000000000000
34 1.000000000000 0.000000000000 2.000000000000
35 2.000000000000 0.000000000000 2.000000000000
36 3.000000000000 0.000000000000 2.000000000000
37 0.000000000000 1.000000000000 2.000000000000
38 1.000000000000 1.000000000000 2.000000000000
39 2.000000000000 1.000000000000 2.000000000000
40 3.000000000000 1.000000000000 2.000000000000
41 0.000000000000 2.000000000000 2.000000000000
42 1.000000000000 2.000000000000 2.000000000000
43 2.000000000000 2.000000000000 2.000000000000
44 3.000000000000 2.000000000000 2.000000000000
45 0.000000000000 3.000000000000 2.000000000000
46 1.000000000000 3.000000000000 2.000000000000
47 2.000000000000 3.000000000000 2.000000000000
48 3.000000000000 3.000000000000 2.000000000000
49 0.000000000000 0.000000000000 3.000000000000
50 1.000000000000 0.000000000000 3.000000000000
51 2.000000000000 0.000000000000 3.000000000000
52 3.000000000000 0.000000000000 3.000000000000
53 0.000000000000 1.000000000000 3.000000000000
54 1.000000000000 1.000000000000 3.000000000000
55 2.000000000000 1.000000000000 3.000000000000
56 3.000000000000 1.000000000000 3.000000000000
57 0.000000000000 2.000000000000 3.000000000000
58 1.000000000000 2.000000000000 3.000000000000
59 2.000000000000 2.000000000000 3.000000000000
60 3.000000000000 2.000000000000 3.000000000000
61 0.000000000000 3.000000000000 3.000000000000
62 1.000000000000 3.000000000000 3.000000000000
63 2.000000000000 3.000000000000 3.000000000000
64 3.000000000000 3.000000000000 3.000000000000
$EndNodes
$Elements
27
1 5 3 2 2 0 1 2 6 5 17 18 22 21
2 5 3 1 1 0 2 3 7 6 18 19 23 22
3 5 3 1 1 0 3 4 8 7 19 20 24 23
4 5 3 1 1 0 5 6 10 9 21 22 26 25
5 5 3 1 1 0 6 7 11 10 22 23 27 26
6 5 3 1 1 0 7 8 12 11 23 24 28 27
7 5 3 1 1 0 9 10 14 13 25 26 30 29
8 5 3 1 1 0 10 11 15 14 26 27 31 30
9 5 3 1 1 0 11 12 16 15 27 28 32 31
10 5 3 2 2 0 17 18 22 21 33 34 38 37
11 5 3 2 2 0 18 19 23 22 34 35 39 38
12 5 3 2 2 0 19 20 24 23 35 36 40 39
13 5 3 2 2 0 21 22 26 25 37 38 42 41
14 5 3 2 2 0 22 23 27 26 38 39 43 42
15 5 3 1 1 0 23 24 28 27 39 40 44 43
16 5 3 2 2 0 25 26 30 29 41 42 46 45
17 5 3 1 1 0 26 27 31 30 42 43 47 46
18 5 3 1 1 0 27 28 32 31 43 44 48 47
19 5 3 2 2 0 33 34 38 37 49 50 54 53
20 5 3 2 2 0 34 35 39 38 50 51 55 54
21 5 3 2 2 0 35 36 40 39 51 52 56 55
22 5 3 2 2 0 37 38 42 41 53 54 58 57
23 5 3 2 2 0 38 39 43 42 54 55 59 58
24 5 3 2 2 0 39 40 44 43 55 56 60 59
25 5 3 2 2 0 41 42 46 45 57 58 62 61
26 5 3 2 2 0 42 43 47 46 58 59 63 62
27 5 3 2 2 0 43 44 48 47 59 60 64 63
$EndElements

We don't even need the $PhysicalNames information, right? Maybe MOOSE has some updates on this issue. I'm not sure.

[ngrilli]

@tianjuxue it depends on the neper version. Yes, nodes and elements will always be read properly, but indeed element sets and node sets for grains and boundary conditions may not work. I will try with the latest neper version and let you know. If you cannot get the boundaries from neper, use the meshgenerator like in the example here: https://github.com/ngrilli/c_pfor_am/blob/main/test/tests/neper/polycrystalneper.i The BoundingBoxNodeSetGenerator can create your boundaries. Hopefully you can see the individual grains as blocks and use the GrainPropertyReadFile to assign the Euler angles. Please let me know how it goes.

[tianjuxue]

I read your code and compared with some MOOSE code, and have successfully found a way for my problem. Here are my detailed procedures, in case others are also interested.

Basically, I created a Gmsh .msh file with boundaries properly defined https://github.com/tianjuxue/cp_gnn/blob/c4e5a9df9694c2401913a33a4840c89ec6e35de1/python/src/extractor.py#L7

Then I assigned the grain ids to the .msh file https://github.com/tianjuxue/cp_gnn/blob/c4e5a9df9694c2401913a33a4840c89ec6e35de1/python/src/extractor.py#L122

I didn't use the raw Neper generated polycrystal structure. Actually in my problem, my polycrystal is the result of a phase-field simulation from https://github.com/tianjuxue/polycrystal

Then by using this input file, I'm able to perform MOOSE-based simulation for polycrystal plasticity https://github.com/tianjuxue/cp_gnn/blob/c4e5a9df9694c2401913a33a4840c89ec6e35de1/problems/select/block.i#L44-L54

I guess the MOOSE PropertyReadFile.c file has a similar function as what is in your GrainPropertyReadFile.c file. Basically, this chunk code is important https://github.com/idaholab/moose/blob/378d2176fdeecc28fe572ac903880230854e93e8/framework/src/userobject/PropertyReadFile.C#L233-L248

So this is my polycrystal structure (from phase-field simulation)

And this is the stress_xx simulation result

Thank you again for your repo. Very good reference and indeed helped me a lot!

[ngrilli]

Dear @tianjuxue

Thank you very much for posting your solution.

Great you could generate the boundaries. There may not be an option to generate the boundaries in neper, but maybe you can try to export the mesh as 'inp' and see if neper generates the boundaries in that case.

Ok, I understand you need to assign some kind of seeds for the grain growth model, maybe you can consider assigning initial Euler angles based on the elements, because of the simple relationship between element number and coordinates in a structured mesh.

Yes, PropertyReadFile and GrainPropertyReadFile are very similar. The reason I developed GrainPropertyReadFile was to have a unique class that is compatible with both GeneratedMesh and FileMesh. A .msh file generated by neper will provide igrain = 1, 2, 3, et cetera, in this call: igrain = elem->subdomain_id(); while a GeneratedMesh will provide igrain = 0 and this indexing will not work in both cases _data[(igrain-1) * _nprop + prop_num];

Actually the current version of PropertyReadFile solves this problem, but last year MOOSE provided only a class called ElementPropertyReadFile that had the issue, so in some sense GrainPropertyReadFile is legacy code and should not be used.

In PropertyReadFile you can switch from 1-based indexing to 0-based indexing for the grains by using: use_zero_based_block_indexing = true

Your work on grain growth model is amazing and I will definitely follow it, as doing simultaneous grain growth and crystal plasticity model is on my radar. Sure, I hope I can provide a good collection of constitutive models in my repository for crystal plasticity and fracture in the future, so that more users can get up to speed more quickly.

Best Regards, Nicolò

[ngrilli]

I have made an instructional video about linking Neper with MOOSE:

https://www.youtube.com/watch?v=qG7EoX34hZ8&lc=Ugx39zHi2_vMuMVmFlV4AaABAg

Hence, I am closing this one. Nicolò