Merging grains

solid-solid phase transformations, influence of stresses and strains
Post Reply
mtoloui
Posts: 34
Joined: Mon Jan 26, 2009 7:31 pm

Merging grains

Post by mtoloui » Tue May 08, 2012 11:43 pm

Hi,
I want to model an austenite to ferrite transformation problem in which ferrite grains are given certain orientations. When two ferrite grains with the same orientation touch one another they merge and form one grain and when the orientations are different they form a ferrite/ferrite grain boundary. Could you tell me how to introduce this in MICRESS?

Thank you

Bernd
Posts: 1504
Joined: Mon Jun 23, 2008 9:29 pm

Re: Merging grains

Post by Bernd » Wed May 09, 2012 2:53 pm

Hi,

this should be possible by using Categorization.

As described already in the link above, the word "categorization" has two meanings which are linked and both necessary for reaching your goal:

1.) The process of assingning two or more different grains to the same grain number during runtime. This is activated by setting the "categorize" keyword in the phase input and will only be done only if all properties of the grains are identical (orientation, phase number, ...).
2.) The reduction of the orientation space to a number of orientation categories, which is activated with the keyword "categorize" (followed by an opional number of categories) in the nucleation and grain input if random orientations are chosen. This is necessary to have any grains with the "same" orientation which can be categorized (in the meaning of 1.)).

Unfortunately, categorization will not be performed under the following conditions:

1.) as long as grains are "small". The reason is that they still have the different "property" of size, which is needed e.g. for calculation of their curvature.
2.) if there is a grain with a grain number in between those to be categorized and which is touching the grain with the higher number (to be more exact: relevant are the internal grain numbers which are not always identical to the numbers visible to the user...). The reason for that is that the reorganisation of the list order would be quite complicated in such a case, therefore it was not implemented so far...

In your case, it should work properly, if you take care that the new ferrite grains do not touch before they reach full size, e.g. by chosing adequate shield parameter.

Bernd

mtoloui
Posts: 34
Joined: Mon Jan 26, 2009 7:31 pm

Re: Merging grains

Post by mtoloui » Tue May 15, 2012 11:27 am

Hi Bernd,
Thank you,
I actually tried categorization but it did not work. For the ferrite phase (phase 2), categorization was toggled on. In the nucleation section, nuclei are introduced to the structure one-by-one while the nuclei of the same orientation are assigned the same categorization number. Making all these modifications, still ferrite grains of the same orientation do not merge together. Checking the TabGD file, it is obvious that when ferrite grains touch each other they are big.
Could you please advise me on how to get the ferrite grains of the same orientation to merge together?
Thank you
….
#
# Data for phase 1:
# -----------------
# Simulation of recrystallisation in phase 1?
# Options: recrystall no_recrystall
no_recrystall
# Is phase 1 anisotrop?
# Options: isotropic anisotropic faceted antifaceted
anisotropic
# Crystal symmetry of the phase?
# Options: none xyz_axis cubic hexagonal
xyz_axis
# Should grains of phase 1 be reduced to categories?
# Options: categorize no_categorize
no_categorize
#
# Data for phase 2:
# -----------------
# [identical phase number]
# Simulation of recrystallisation in phase 2?
# Options: recrystall no_recrystall
no_recrystall
# Is phase 1 anisotrop?
# Options: isotropic anisotropic faceted antifaceted
anisotropic
# Crystal symmetry of the phase?
# Options: none xyz_axis cubic hexagonal
xyz_axis
# Should grains of phase 1 be reduced to categories?
# Options: categorize no_categorize
categorize
# Orientation
# -----------
# How shall grain orientations be defined?
# Options: angle_2d
# euler_zxz
# angle_axis
# miller_indices
angle_2d
# Grain input
# ===========
# Type of grain positioning?
# Options: deterministic random from_file
deterministic
# NB: the origin of coordinate system is the bottom left-hand corner,
# all points within the simulation domain having positive coordinates.
# Number of grains at the beginning?
7
# Input data for grain number 1:
# Geometry?
# Options: round rectangular elliptic
round
# Center x,z coordinates [micrometers], grain number 1?
10.95
0
# Grain radius? [micrometers]
16
# Shall grain 1 be stabilized or shall
# an analytical curvature description be applied?
# Options: stabilisation analytical_curvature
stabilisation
# Should the Voronoi criterion?
# Options: voronoi no_voronoi
voronoi
# Phase number? (integer)
1
# Rotation angle? [Degree]
0
#

. . .

#
# ************* seed 6
#-----------------------------------------------------------------
# Options: bulk region interface triple quadruple [restrictive]
region
# Minimal value of x-coordinates? [micrometers]
0
# Maximal value of x-coordinates? [micrometers]
0.09
# Minimal value of z-coordinates? [micrometers]
10.35
# Maximal value of z-coordinates? [micrometers]
10.53
# Phase of new grains (integer) [unresolved]?
2
# Reference phase (integer) [min. and max. fraction (real)]?
1
# Which nucleation model shall be used?
# Options: seed_undercooling seed_density
seed_undercooling
# maximum number of new nuclei ?
1
# Grain radius [micrometers]?
0.3
# Choice of growth mode:
# Options: stabilisation analytical_curvature
stabilisation
# min. undercooling [K] (>0)?
70
# Determination of nuclei orientations?
# Options: random randomZ fix range parent_relation
fix
# Rotation angle? [Degree]
51.4286
# Shield effect:
# Shield time [s] ?
1.2
# Shield distance [micrometers]?
0.3
# # Shall categorization be applied to this seed type?
# Options: categorize {Number} no_categorize
categorize 5
# Nucleation range
# min. nucleation temperature for seed type 3 [K]
995
# max. nucleation temperature for seed type 3 [K]
996.7586
# Time between checks for nucleation? [s]
0.2
# Shall random noise be applied?
# Options: nucleation_noise no_nucleation_noise
no_nucleation_noise
#
# ************* seed 7
#-----------------------------------------------------------------
# Options: bulk region interface triple quadruple [restrictive]
region
# Minimal value of x-coordinates? [micrometers]
14.13
# Maximal value of x-coordinates? [micrometers]
14.31
# Minimal value of z-coordinates? [micrometers]
11.79
# Maximal value of z-coordinates? [micrometers]
11.97
# Phase of new grains (integer) [unresolved]?
2
# Reference phase (integer) [min. and max. fraction (real)]?
1
# Which nucleation model shall be used?
# Options: seed_undercooling seed_density
seed_undercooling
# maximum number of new nuclei ?
1
# Grain radius [micrometers]?
0.3
# Choice of growth mode:
# Options: stabilisation analytical_curvature
stabilisation
# min. undercooling [K] (>0)?
70
# Determination of nuclei orientations?
# Options: random randomZ fix range parent_relation
fix
# Rotation angle? [Degree]
38.5714
# Shield effect:
# Shield time [s] ?
1.2
# Shield distance [micrometers]?
0.3
# # Shall categorization be applied to this seed type?
# Options: categorize {Number} no_categorize
categorize 5
# Nucleation range
# min. nucleation temperature for seed type 3 [K]
995
# max. nucleation temperature for seed type 3 [K]
996.7737
# Time between checks for nucleation? [s]
0.2
# Shall random noise be applied?
# Options: nucleation_noise no_nucleation_noise
no_nucleation_noise
#

Bernd
Posts: 1504
Joined: Mon Jun 23, 2008 9:29 pm

Re: Merging grains

Post by Bernd » Tue May 15, 2012 8:47 pm

Dear mtoloui,

In principle, it should work like that...

But I become suspicious when I see that you are using xyz_axis symmetry. How the orientation categories are build depends on symmetry, and it could be that it is wrongly implemented in case of this (up to now practically unused) symmetry type! And I cannot remember this case when I programmed it! :?

Currently, I am in Hong Kong, and thus cannot access the code! Can you please check whether really 5 orientation categories are formed (.orie output)? Please check also whether the problem persists if you use cubic or no symmetry!

The other possibility is that the list of grain numbers has "holes", because e.g. grains of phase 1 have vanished due to ripening. In this case, MICRESS would internally reuse these grain numbers, and case 2) of my last post would apply. This process you cannot follow without access to the code because the internal numbers are hidden to the user. But then, at least, other later set grains should be categorized correctly.
I lately made a change in the code that prevents this "filling of gaps", because we now have a better solution to the problem. I think, the change is already in the latest version which you got from us and which is on our fdp download area. I can check that once I am at home again!

If you do not get the problem solved, I would like to get a copy of your driving file to find out what is going wrong.

Best wishes

Bernd

mtoloui
Posts: 34
Joined: Mon Jan 26, 2009 7:31 pm

Re: Merging grains

Post by mtoloui » Fri May 18, 2012 12:14 am

Dear Bernd,

Thank you so much for your prompt attention.
I tried all other symmetry options i.e. none xyz_axis cubic hexagonal for the phase 2 (ferrite) and it actually did not make it any better.
I do not know how to check whether 5 orientation categories are formed or not. I opened the file Results.orie through DP_MICRESS and all the ferrite nuclei had the same orientation but when they touch they do not merge.
Regarding “holes”, it is not the case here because parent grains (austenite) do not vanish in this simulation.
I just emailed the run file to you. I would really appreciate it if just take a look at the run file and advise me on how to make it work

Thank you so much

Bernd
Posts: 1504
Joined: Mon Jun 23, 2008 9:29 pm

Re: Merging grains

Post by Bernd » Fri May 18, 2012 4:38 am

Dear mtoloui,

thanks for sending me your input files! I had a look on your input file, but could not find anything wrong. After getting big and after the shield time has elapsed, the ferrite grains should merge if they did not touch before! Which MICRESS version are you using?

I will try it out myself on Monday when I am back in Aachen!

Bernd

mtoloui
Posts: 34
Joined: Mon Jan 26, 2009 7:31 pm

Re: Merging grains

Post by mtoloui » Mon May 21, 2012 3:49 am

Hi Bernd,

I have tried it with both version numbers 6.001 (Linux) and 6.003 (Linux). Results are the same and ferrite grains do not merge.

Thank you,
Morteza

Bernd
Posts: 1504
Joined: Mon Jun 23, 2008 9:29 pm

Re: Merging grains

Post by Bernd » Tue May 22, 2012 5:50 pm

Hi mtoloui,

I am now home again and checked your example. I found out the reasons why categorization is not done like expected:

1.) If fixed orientations are used, the orientation value is not changed, because the user is supposed to know what he/she wants. It is somehow inconsistent that the keywords [categorize/no_categorize] are still required in the seed type input, although they have no meaning in this case - I will change that for the next release!

2.) Categorization is done during run-time. Because checking for possible merging of grains requires some effort, it is only done in those time-steps when nucleation is checked. This strategy has historical reasons and follows the idea that categorisation is required to keep the number of grains small during continuous nucleation, i.e. merging of grains needs not to be done anymore when nucleation is not checked anymore. That means, the motivation was just to improve performance and not to prevent the formation of interfaces between grains with same orientation.
Checking for nucleation is done only in time-steps for which all the following conditions hold:
- at least one of the seed types is checked (according to the checking interval)
- temperature is inside the temperature range for this seed-type
- the maximum number of seeds has not been reached for this seed-type
- there is at least one grain which has not been checked yet and which passed the shield-time

In your case, the 2nd and 3rd condition is not given, therefore merging is not done. So, if you change the temperature interval and the maximum number of seeds for at least one of the seed types, all grains with the same orientation will be merged. Please note that the numbers of categories, which you specify for the different seed types, are meaningless as no categorisation (reduction to orientation classes) is done for the case of fixed orientations (see above)!

Bernd

Post Reply