temperature dependent mobilities

[ilovemicress]

Hi,

I used temperature dependent mobilities in simulation of solidification.
Following setting file was used.

1800 8.0e-04
1635 2.0e-05
1450 2.0e-05
1385 9.0e-07

I ran MICRESS from 1710K to 1388K with Q=-5K/s.
In the case of restart at 1388K, does MICRESS use 2.0e-05 from 1388K to 1385K and 9.0e-07 from 1385K to the end of simulation?

Regards,
Taka

[Bernd]

Hi Taka,

MICRESS is always doing a linear interpolation of the mobility values in temperature. This behaviour is independent from whether you use restart or not.
You can check the actually used mobility values with the .mueS output. But be careful because this output includes the effect of anisotropy!

Bernd

[ilovemicress]

Hi Bernd,

Thank you for your reply and acvice!
I didn't know the method to check of the actually used mobility values with the .mueS output.

I'd like to ask you more question.
I ran MICRESS from 1710K to 1388K and restarted it at 1388K to 1338K with Q=-5K/s.
Following above-mentioned setting file was used.

1800 8.0e-04
1635 2.0e-05
1450 2.0e-05
1385 9.0e-07

The simulation resulted in discontinuous change in slope of the ferrite fraction curve at 1388K.
Does the interpolation concern this unexpected phenomenon?
Attached file will help you understand the situation.

Regards,
Taka

P.S.;
Sorry. I didn't set "output .mueS" in this simulation.

[Bernd]

Hi Taka,

I do not really understand what you did - why did you make this restart? What did you change in the input file between the first run and the restart?
There is no reason why the program should do anything different after restart to what it would have done in a single run, if you did not change the conditions (like the cooling rate or the mobility input file) between the first run and the restart! And there should never occur an abrupt change of the slope because the mobility values are interpolated and never change abruptly.
The best would be if you could show me the .log output files from the first run and from the restart. I think that something went wrong in the simulation...

Bernd

[ilovemicress]

Hi Bernd,

Thank you for your reply!

>There is no reason why the program should do anything different after restart to what it would have done in a single run, if >you did not change the conditions (like the cooling rate or the mobility input file) between the first run and the restart!

Your comments sound reasonable. I also think that the single run is the best with the same conditions.

However, the result of the first run had been already obtained.
Therefore, I used the restart to obtain the result under 1388 K without wasting time.

Attached please find the .log output files.

Regards,
Taka

[Bernd]

Hi Taka,

unfortunately, I cannot find any clue what is going wrong here!
(I assume that you did not change the file CaseB-3_BCC_FCC.dat between the first run and the restart...)

If I had all the input and result files available, I would check for the following:

- is growth of phase 2 against phase 1 really slowing down after restart, if you look at the level of the individual grains (using DP_MICRESS and e.g. the .phas, .frac2 or .conc*)? Is it the same for all grains or an effect of a single grain?
- Is there any discontinuity of any important quatity before and after restart? In the ASCII outputs there is a lot of information to check, like temperature and T gradient in .TabL, time stepping in .TabT, diffusion coefficients in TabD? In the graphical outputs, the mobility (.mueS), the driving force (.driv) and the concentration distribution are of particular interest.
- try to reproduce the problem with the smalles possible domain size. Then, if the problem persists, I would try to redo in with a newer MICRESS version (5.504, download with ftp from our web server).

If you like you also can send me your driving file, and I can try myself. Then, I would need also the .GES5 and the CaseB-3_BCC_FCC.dat.

Bernd

[ilovemicress]

Hi Bernd,

Thank you for your reply & consideration!
I have checked result files.
However, I couldn't find the reason for the discontinuous change of the ferrite fraction.

Would you like to reproduce the same situation on your machine?
Attached please find the files.
I will send you the password via "private messages".

Regards,
Taka

[Bernd]

Hi Taka,

I ran the simulation on our machines and found a similar result as you. But when I looked closer on the fraction change around the restart time, I could see that there is no discontinuity, in contrary to what the images you sent suggest! Just occasionally, the time of the kink in the phase fraction curve and the restart time coincide! But I could clearly see that the turning of the curve already starts before 70s, i.e above 1388K. The transition of the mobility, according to the mobility output .mueS, is also smooth.
The reason of the appearance of the kink around 1388 K, which is in contrary to your expectations, is that the step in the mobility from 2E-5 to 9E-7 is quite high. As a consequence of linear interpolation, if plotted logarithmically, mue is dropping most strongly some K before reaching the step temperature at 1385 K. (Another effect, which is shifting the position of the kink to the other direction, is the temperature gradient in the simulation domain, which makes that the top of the simulation domain has a 2-3 K higher temperature than the bottom.)

Please check whether in your data the kink is also smooth if looking closer. If not, it is perhaps that you calculated the first run before adding line 4 of the mobility input file with the lowest value. Then, of course, a discontinuity would be the consequence, because in the first run there was no interpolation.

I have some other remarks with respect to the simulation:

- During solidification, the interface is spreading, leading to smeared dendrites and reducing performance. This is because resolution is too low or because the mobility is too high. The effect vanishes if the mobility is lowered to 2.E-2. For quantitative work, a calibration would be necessary.

- Solidification is never finished because the element C is included but no carbides, and an extremely high C composition is accumulating in the rest liquid. Consider adding carbides to the simulation!

- The minimum and maximum time step are not chosen optimally, a higher value for the latter would increase performance.

Best regards

Bernd

[ilovemicress]

Hi Bernd,

Thank you very much for your validation.

The discontinuity was found though the enlarged figure around the restart time as the attached image file.
I think that I calculated the first run with line 4 of the mobility input file.
However, I will re-calculate the first run with line 4, in addition, without line 4.

And thank you for your several advices.

>During solidification, the interface is spreading, leading to smeared dendrites and reducing
>performance. This is because resolution is too low or because the mobility is too high.
>The effect vanishes if the mobility is lowered to 2.E-2. For quantitative work, a calibration
>would be necessary.

The recommended mobility value constricted the width of interface. I will use such lower value.

>Solidification is never finished because the element C is included but no carbides, and an extremely
>high C composition is accumulating in the rest liquid. Consider adding carbides to the simulation!

Does this expertise mean that granting that the used cooling rate, i.e. 5K/s, doesn't cross the nose of carbide formation in CCT diagram, I have to consider carbide formation in the simulation of solidification?

>The minimum and maximum time step are not chosen optimally, a higher value for the latter would
>increase performance.

Sorry. I couldn't understand what you mean for certain.
I'd like your additional advice.

The following description is in the log file.

"Maximal value for tWidth =1.5000000E-06 s for phase-field solver
Maximal value for tWidth =6.9036839E-05 s for conc-field solver"

And the following description is in the drive file.

"# Time-step?
# Option: (real) automatic [0<factor_1<=1] [0<=factor_2] [max.] [min.]
# (Fix time steps: just input the value)
automatic 0.9 0.9 1.5E-4 1.5E-6"

Concretely speaking, where I should change this condition?
Thank you in advance for your anticipated cooperation in this matter.

Best Regards,
Taka

[Bernd]

Dear Taka,

having seen your enlarged fraction plot it gets clear that you really have a discontinuity. Interestingly, when I did the simulation, I got a smoother "kink" in exactly the same region, which is just a consequence of the quite big mobility step in conjunction with the interpolation. Therefore I was not 100% sure whether you really found a discontinuity...
Please check whether you had line 4 in the first run, as you suggested. If not, this would be the simplest explanation!

Now to the question of the carbides: I assume that the CCT diagram which you refer to is for solid state reactions. In case of solidification, you should rather do a Scheil simulation with Thermo-Calc and see which phases are found. All phases which appear before about fS=99% should be considered in the MICRESS simulation, if there is no explicit experimental evidence that they do not form.

Normally, MICRESS would not need any minimum or maximum time step to be defined, as in the automatic mode the time step is always calculated such to ensure a stable simulation. But there is a strong performance reason to define a minimum time step: If one single grid cell requires a very small time step, e.g. due to some numerical problem, the whole simulation will run at this small time step. If a minimum time step is defined, and this value is higher than the value required for this grid cell, then the mobility in this grid cell is temporarily reduced to ensure stability with the higher time step. This can tremendously increase performance and does not really hurt as long as only a very small proportion of the interface cells is involved. Therefore, the aim is to increase the minimum time step value as much as possible, but not so much that the mobility of too many grid cells is reduced. This can be monitored in the .mueS output. The maximum time step is not critical and should be set to a high value like 1.
The reason why I said your time stepping scheme is not optimal is because, as far as I could see in the .log file for the intermediate outputs, time steps were always at the upper limit, so you were forcing the simulation to use a smaller value than necessary. The initial time step values which you cited from the .log file are not relevant, because the system is rapidly changing afterwards.

Best wishes

Bernd