Guten Morgen!
In the driving file, there must be two parameters as,
# Phase field data structure
# --------------------------
# Coefficient for dimension of field iFace
1.0
# Coefficient for dimension of field nTupel
0.5
I, however, did not see any numerical deviation of calculation result by changing these two parameter values in my a few calculations.
Please explain that what do the roles of these two parameters play in.
---
original message from Sukeharu Nomoto
What are roles of parameters for phase field data structure?
Good point!
Guten Morgen!
You are addressing a very good point, because this is something which has been improved for the new version which will be released very soon!
Up to now (in your version) these two parameters specify the dimension of the iFace and nTupel list in MICRESS in units of Nxyz. That means if you input 1.0 for the iFace field in principle you can have all your calculation domain (with the size Nxyz) full of interface region without exeeding the list size (effectively even a bit more because Nxyz also includes the domain boundaries which are used for the boundary conditions).The same holds for the nTupel (these are list elements for multiple grain interactions, you can find them as values >=3 in the .intf output). You can track the effective usage relative to the allocated size in the .TabL output.
This fix allocation still is a remnant of the fortran77 times where dynamic allocation was not allowed. In the next version the iFace and nTupel field will be allocated dynamically according to the size which is actually needed.The input will be still there, the meaning is then just the initial size relative to Nxyz. The .TabL output will give the actual size relative to Nxyz.
For the user this means:
-up to now:
As long as the values are big enough there will be no effect of these two parameters, except that too big arrays can slow down big calculations or even produce a crash if the physically available memory size is exceeded. If the values are too small the program will stop when the allocated size of one of the two lists is exceeded. Then you have to restart the calculation (using the restart option) with a higher value of the corresponding parameter.
- in near future (new version):
In most cases you will not have to worry about the iFace and nTupel parameter values because the field sizes are adjusted automatically. This is what we recommend to our users.
We still will leave the two parameters (plus 2 optional parameters in the same line for both) in the driving file because under special condition one might wish to be able to controll the field sizes in an even better way.This may be e.g:
- if for some reason the user is interested in having a static list size. Then the second optional parameter should be 0:
# Phase field data structure
# --------------------------
# Coefficient for dimension of field iFace
1.0 0
# Coefficient for dimension of field nTupel
0.5 0
- if the calculation is begining with a lot of grains (like in ordinary grain ripening,) starting with 0 as initial size would lead to a high number of list increasing actions during initialisation. This is not bad but could take some extra time!
- if you are interested in keeping your list size as small as possible you could wish to adjust the allocated size to the actual size rather very often than in few bigger steps. This can be achieved by properly specifying the second and third parameter:
# Phase field data structure
# --------------------------
# Coefficient for dimension of field iFace
1.0 0.8 0.9
# Coefficient for dimension of field nTupel
0.5 0.7 0.85
This for iFace means, that if less than 80 % of the allocated iFace-Field is used it will be reduced such that 90 % of it is used after the reallocation. On the other hand, if in the case of a growing iFace list 100 % usage is reached, then the iFace field is increased such that afterwards 90 % are used (The default values are 0.25 and 0.75 respectively).
This may seem a bit complicated, but I hope it will be just for expert fine tuning and not for normal usage.
I hope this gives you the required information!
Bernd
---
original message from Bernd
You are addressing a very good point, because this is something which has been improved for the new version which will be released very soon!
Up to now (in your version) these two parameters specify the dimension of the iFace and nTupel list in MICRESS in units of Nxyz. That means if you input 1.0 for the iFace field in principle you can have all your calculation domain (with the size Nxyz) full of interface region without exeeding the list size (effectively even a bit more because Nxyz also includes the domain boundaries which are used for the boundary conditions).The same holds for the nTupel (these are list elements for multiple grain interactions, you can find them as values >=3 in the .intf output). You can track the effective usage relative to the allocated size in the .TabL output.
This fix allocation still is a remnant of the fortran77 times where dynamic allocation was not allowed. In the next version the iFace and nTupel field will be allocated dynamically according to the size which is actually needed.The input will be still there, the meaning is then just the initial size relative to Nxyz. The .TabL output will give the actual size relative to Nxyz.
For the user this means:
-up to now:
As long as the values are big enough there will be no effect of these two parameters, except that too big arrays can slow down big calculations or even produce a crash if the physically available memory size is exceeded. If the values are too small the program will stop when the allocated size of one of the two lists is exceeded. Then you have to restart the calculation (using the restart option) with a higher value of the corresponding parameter.
- in near future (new version):
In most cases you will not have to worry about the iFace and nTupel parameter values because the field sizes are adjusted automatically. This is what we recommend to our users.
We still will leave the two parameters (plus 2 optional parameters in the same line for both) in the driving file because under special condition one might wish to be able to controll the field sizes in an even better way.This may be e.g:
- if for some reason the user is interested in having a static list size. Then the second optional parameter should be 0:
# Phase field data structure
# --------------------------
# Coefficient for dimension of field iFace
1.0 0
# Coefficient for dimension of field nTupel
0.5 0
- if the calculation is begining with a lot of grains (like in ordinary grain ripening,) starting with 0 as initial size would lead to a high number of list increasing actions during initialisation. This is not bad but could take some extra time!
- if you are interested in keeping your list size as small as possible you could wish to adjust the allocated size to the actual size rather very often than in few bigger steps. This can be achieved by properly specifying the second and third parameter:
# Phase field data structure
# --------------------------
# Coefficient for dimension of field iFace
1.0 0.8 0.9
# Coefficient for dimension of field nTupel
0.5 0.7 0.85
This for iFace means, that if less than 80 % of the allocated iFace-Field is used it will be reduced such that 90 % of it is used after the reallocation. On the other hand, if in the case of a growing iFace list 100 % usage is reached, then the iFace field is increased such that afterwards 90 % are used (The default values are 0.25 and 0.75 respectively).
This may seem a bit complicated, but I hope it will be just for expert fine tuning and not for normal usage.
I hope this gives you the required information!
Bernd
---
original message from Bernd
Thank you very much for your explanation
I understood role of the parameters for Phase Field Data Structure in MICRESS driving file well.
---
original message from Sukeharu Nomoto
---
original message from Sukeharu Nomoto
Re: What are roles of parameters for phase field data structure?
It seems MICRESS only stores data at the grid points of interface during running to save memory, right?
When coupled with diffusion,how to deal with that outside of interface since no data recorded?
When coupled with diffusion,how to deal with that outside of interface since no data recorded?
Re: What are roles of parameters for phase field data structure?
Dear zhubq,
What has been said in this thread refers to the phase-field variables, i.e. the fractions of the phases or grains. They need to be stored only at the interfaces, because inside the grains, the values are trivial (1 for the present grain and 0 for all others). Of course, the composition has to be stored on the complete grid! The phase compositions, again, are stored only for the interfaces, because inside the grains, for the present phase, they are identical to the (mixture) composition.
Bernd
What has been said in this thread refers to the phase-field variables, i.e. the fractions of the phases or grains. They need to be stored only at the interfaces, because inside the grains, the values are trivial (1 for the present grain and 0 for all others). Of course, the composition has to be stored on the complete grid! The phase compositions, again, are stored only for the interfaces, because inside the grains, for the present phase, they are identical to the (mixture) composition.
Bernd
Re: What are roles of parameters for phase field data structure?
I see. Thank you for explanation!