Dear Dr. Böttger,
I have an initial cold rolled ferrite-pearlite structure. I am modelling its heating to study the kinetics of austenite formation. At first, I model the recrystallization of ferrite. And simultaneous pearlite to austenite and ferrite to austenite transformation. For this purpose I am using a linearized phase diagram. And Pearlite is described as a stoichiometric phase with Carbon content of eutectoid composition. Let's call this as Program 1.
When all the pearlite transform to austnite I want to create a new program coupled with ThermoCalc. (As now I only have ferrite and austenite). Let's call this Program as Program 2. Can you please let me know what outputs I should take from Program 1 to put as a input to Program 2. Only Program1.conc1 (carbon map) I did manage properly. Which output formats shall I take from Program 1 to input to Program 2 for phase number, and ferrite recrystallization energy?
Thanking you,
Yours sincerely,
Krishnendu Mukherjee
Output and input files format
Re: Output and input files format
Dear Krishnendu,
isn't that similar to what Jenny was doing? The argument then was that for a "pseudo-Phase approach" for pearlite a linearized phase diagram was needed, but for the following step, the austenite-ferrite transformation, coupling to TQ and a thermodynamic database was better. So, she did a two-step simulation. In principle, you should transfer as much of the information of the first step as possible to the second step in such an approach, that means the phase/grain distribution and the concentration fields (I do not know in which step the recrystallisation is important...).
But, other than for Jenny, with MICRESS version 5.5 now it is possible to mix thermodynamic descriptions via thermodynamic databases and linearized phase diagrams! The only condition is that both descriptions include the same alloying elements. So, you could describe the austenite-ferrite interaction using the database, and the pearlite-ferrite and pearlite-austenite interaction as linearized phase-diagrams. I think, this would make it much easier, provided that you are able to make the linearized "pseudo-phase approach" for all alloy components. Actually, I developed this new option for Jenny, but it came too late for her...
Bernd
isn't that similar to what Jenny was doing? The argument then was that for a "pseudo-Phase approach" for pearlite a linearized phase diagram was needed, but for the following step, the austenite-ferrite transformation, coupling to TQ and a thermodynamic database was better. So, she did a two-step simulation. In principle, you should transfer as much of the information of the first step as possible to the second step in such an approach, that means the phase/grain distribution and the concentration fields (I do not know in which step the recrystallisation is important...).
But, other than for Jenny, with MICRESS version 5.5 now it is possible to mix thermodynamic descriptions via thermodynamic databases and linearized phase diagrams! The only condition is that both descriptions include the same alloying elements. So, you could describe the austenite-ferrite interaction using the database, and the pearlite-ferrite and pearlite-austenite interaction as linearized phase-diagrams. I think, this would make it much easier, provided that you are able to make the linearized "pseudo-phase approach" for all alloy components. Actually, I developed this new option for Jenny, but it came too late for her...
Bernd
Re: Output and input files format
Dear Dr. Böttger,
Thank you for your reply. I am eager to try both options. Let me first tell you the problem I faced for the old option. I took korn.txt and phas. txt output from program 1 (I defined what is Program 1 in my earlier post). Then I tried to put it as an input in the Program 2 ( I defined what is Program 2 also in my earlier post). Here is the problem I have:
# Grain input
# ===========
# Type of grain positioning?
# Options: deterministic random from_file
from_file
# File for initial grain/phase structure
s17korn.txt
# Treatment of data?
# (n: none, 1: 1D, f: flip (bottom<->top), t: transpose,
# or p: 'phase to grains transformation')
# 'Driving file' read to the end. Reverting to keyboard input.
n
n
# AnzX for initial microstructure?
545
545
# AnzZ for initial microstructure?
410
410
# Number of grains at the beginning?
# (Set to less than 1 to read from input data,
# with optionally a minimal size, in cells)
0
0
# Number of grains found in input data: 467
# Read grain properties from a file?
# Options: input from_file identical blocks
from_file
from_file
# File for initial grain/phase structure?
s17phas.txt
s17phas.txt
# Parsing input file...
# (s17phas.txt)
# Done!
# Input data for grain number 1:
# Phase number? (integer)
Warning! Trailing characters in string: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Error in routine outAusgabe
Call parameters:
Output on screen and in logfile
Outputs: +1
String: Warning! Trailing characters in string: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Format: (//A//)
'IO stat' variable: -2
'IO message': End of record
'Unit': 11
Error in routine outAusgabe
Call parameters:
Output on screen and in logfile
Outputs: +1
String: Warning! Trailing characters in string: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Format: (//A//)
'IO stat' variable: -2
'IO message': End of record
'Unit': 18
Input error in routine leseEingabe
Input: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Error in routine outAusgabe
Call parameters:
Output on screen and in logfile
Outputs: +1
String: Input: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Format: (A//)
'IO stat' variable: -2
'IO message': End of record
'Unit': 11
Error in routine outAusgabe
Call parameters:
Output on screen and in logfile
Outputs: +1
String: Input: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Format: (A//)
'IO stat' variable: -2
'IO message': End of record
'Unit': 18
Bad integer for item 1 in list input
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
For the new approach: Please see attached the Fe-Mn phase diagram.
Although I know the pseudo-phase approach for the Fe-C phase diagram, I do not know
the pseudo-phase approach for the Fe-Mn phase diagram (to define the Pearlite-Austenite, and
Pearlite-Ferrite interaction). Please let me know if you have
any reference for this.
Thanking you,
Best regards,
Krishnendu
Thank you for your reply. I am eager to try both options. Let me first tell you the problem I faced for the old option. I took korn.txt and phas. txt output from program 1 (I defined what is Program 1 in my earlier post). Then I tried to put it as an input in the Program 2 ( I defined what is Program 2 also in my earlier post). Here is the problem I have:
# Grain input
# ===========
# Type of grain positioning?
# Options: deterministic random from_file
from_file
# File for initial grain/phase structure
s17korn.txt
# Treatment of data?
# (n: none, 1: 1D, f: flip (bottom<->top), t: transpose,
# or p: 'phase to grains transformation')
# 'Driving file' read to the end. Reverting to keyboard input.
n
n
# AnzX for initial microstructure?
545
545
# AnzZ for initial microstructure?
410
410
# Number of grains at the beginning?
# (Set to less than 1 to read from input data,
# with optionally a minimal size, in cells)
0
0
# Number of grains found in input data: 467
# Read grain properties from a file?
# Options: input from_file identical blocks
from_file
from_file
# File for initial grain/phase structure?
s17phas.txt
s17phas.txt
# Parsing input file...
# (s17phas.txt)
# Done!
# Input data for grain number 1:
# Phase number? (integer)
Warning! Trailing characters in string: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Error in routine outAusgabe
Call parameters:
Output on screen and in logfile
Outputs: +1
String: Warning! Trailing characters in string: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Format: (//A//)
'IO stat' variable: -2
'IO message': End of record
'Unit': 11
Error in routine outAusgabe
Call parameters:
Output on screen and in logfile
Outputs: +1
String: Warning! Trailing characters in string: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Format: (//A//)
'IO stat' variable: -2
'IO message': End of record
'Unit': 18
Input error in routine leseEingabe
Input: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Error in routine outAusgabe
Call parameters:
Output on screen and in logfile
Outputs: +1
String: Input: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Format: (A//)
'IO stat' variable: -2
'IO message': End of record
'Unit': 11
Error in routine outAusgabe
Call parameters:
Output on screen and in logfile
Outputs: +1
String: Input: -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 2.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 -1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 -1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.00000000 1.0000000
Format: (A//)
'IO stat' variable: -2
'IO message': End of record
'Unit': 18
Bad integer for item 1 in list input
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
For the new approach: Please see attached the Fe-Mn phase diagram.
Although I know the pseudo-phase approach for the Fe-C phase diagram, I do not know
the pseudo-phase approach for the Fe-Mn phase diagram (to define the Pearlite-Austenite, and
Pearlite-Ferrite interaction). Please let me know if you have
any reference for this.
Thanking you,
Best regards,
Krishnendu
- Attachments
-
- phase diagram for Fe-Mn.JPG (22.1 KiB) Viewed 8763 times
Re: Output and input files format
Dear Krishnendu,
while you try to read in the initial microstructure there seems to be a problem with the file structure. The first file you read contains the geometrical grain distribution. I guess, you have created it from an .korn output of "Program 1" which you transferred to ASCII format. It should have the size you specified, namely 410x545 grid points. The second file you read should contain non-geometrical information about the grain propeties, i.e. it should consist of a list of phase numbers for each grain, and not a mapping of the spacial phase distribution! Alternatively, you could just define them block-wise if they are sorted, i.e. for example if the lower grain numbers correspond to phase number 1 and the higher grain numbers to phase 2, or read them one by one.
I understand that it may not be easy to define a pseudo-phase "pearlite" in a stringent multi-component way. But if you make your two-step approach, you also have to make crude assumptions for the other elements, namely e.g. that they are not redistributed during the pearlite dissolution. This assumption you also can easily implement in the pseudo-phase approach: You just make the c0 for these elements and both phases in each of the interactions ferrite-pearlite and austenite-pearlite equal (e.g. the alloy composition), and assign very small and equal slopes to both sides (e.g. 1.0E-12). Then you can be sure that these elements are not redistributed and do not have any effect on the driving force, just the same as it would do in your two-step approach!
Bernd
while you try to read in the initial microstructure there seems to be a problem with the file structure. The first file you read contains the geometrical grain distribution. I guess, you have created it from an .korn output of "Program 1" which you transferred to ASCII format. It should have the size you specified, namely 410x545 grid points. The second file you read should contain non-geometrical information about the grain propeties, i.e. it should consist of a list of phase numbers for each grain, and not a mapping of the spacial phase distribution! Alternatively, you could just define them block-wise if they are sorted, i.e. for example if the lower grain numbers correspond to phase number 1 and the higher grain numbers to phase 2, or read them one by one.
I understand that it may not be easy to define a pseudo-phase "pearlite" in a stringent multi-component way. But if you make your two-step approach, you also have to make crude assumptions for the other elements, namely e.g. that they are not redistributed during the pearlite dissolution. This assumption you also can easily implement in the pseudo-phase approach: You just make the c0 for these elements and both phases in each of the interactions ferrite-pearlite and austenite-pearlite equal (e.g. the alloy composition), and assign very small and equal slopes to both sides (e.g. 1.0E-12). Then you can be sure that these elements are not redistributed and do not have any effect on the driving force, just the same as it would do in your two-step approach!
Bernd
Re: Output and input files format
Dear Dr. Böttger,
Thank you for your reply.
Can we create a grain properties text file from ''Program 1''? It should be of the following format:
grain number
phase number
recrystallization energy (if phase number is the phase number for ferrite)
Then we can input it to ''Program 2''.
Best regards,
Krishnendu
Thank you for your reply.
Can we create a grain properties text file from ''Program 1''? It should be of the following format:
grain number
phase number
recrystallization energy (if phase number is the phase number for ferrite)
Then we can input it to ''Program 2''.
Best regards,
Krishnendu
Re: Output and input files format
Dear Krishnendu,
the input format is exactly the same as if one would select "input" and enter the requested values consecutively. Comments are erased automatically. As the grain numbering is consecutive, the grain number itself is not included in the file. Depending on the phase properties, the input consists of only the phase number or additionally the recrystallisation energy, orientation etc. All values have to be given as an extra line.
I do not know whether there is a way of creating such a table automatically, maybe from the .TabGD file. An alternative would be to make a VTK output from program 1. If you would read the grain input in VTK format which also contains the .phas output, it would automatically combine the information from both files. What I do not know is whether it would also combine the .rex information, probably not. Antoine is the expert for that...
Bernd
the input format is exactly the same as if one would select "input" and enter the requested values consecutively. Comments are erased automatically. As the grain numbering is consecutive, the grain number itself is not included in the file. Depending on the phase properties, the input consists of only the phase number or additionally the recrystallisation energy, orientation etc. All values have to be given as an extra line.
I do not know whether there is a way of creating such a table automatically, maybe from the .TabGD file. An alternative would be to make a VTK output from program 1. If you would read the grain input in VTK format which also contains the .phas output, it would automatically combine the information from both files. What I do not know is whether it would also combine the .rex information, probably not. Antoine is the expert for that...
Bernd
Re: Output and input files format
Dear Dr. Böttger,
Thank you for your reply. I decided to use the new MICRESS version 5.5 as it is possible to mix thermodynamic descriptions via thermodynamic databases and linearized phase diagrams.
But I have a problem. The program is slow. My grid size is 545 * 410. And the cell dimension is 0.2 micron. I want to ask if the following steps can improve the speed.
1. global linearization.
2. in the log file I see lot of statements:
--> Relinearisation in interface of grains 195/ 368 t= 32.3408
due to a T deviation of 30.133442 K zp = 2131
I used
# Interval for updating thermodynamic data [s] =
5.000
Will a increment in this value increase the speed of the calculation?
Please let me know if these can increase the speed of the calculations. If let me know if there are other things that I can do to achieve higher speed of calculation.
Best regards,
Krishnendu
Thank you for your reply. I decided to use the new MICRESS version 5.5 as it is possible to mix thermodynamic descriptions via thermodynamic databases and linearized phase diagrams.
But I have a problem. The program is slow. My grid size is 545 * 410. And the cell dimension is 0.2 micron. I want to ask if the following steps can improve the speed.
1. global linearization.
2. in the log file I see lot of statements:
--> Relinearisation in interface of grains 195/ 368 t= 32.3408
due to a T deviation of 30.133442 K zp = 2131
I used
# Interval for updating thermodynamic data [s] =
5.000
Will a increment in this value increase the speed of the calculation?
Please let me know if these can increase the speed of the calculations. If let me know if there are other things that I can do to achieve higher speed of calculation.
Best regards,
Krishnendu
Re: Output and input files format
Dear Krishnendu,
In general, in order to check and optimize performance, one first should look up the .TabP output file. This text file is written with the same frequency as the .TabL and gives a summary in which parts of the code time was spent:
# Simulation CPU Time Wallclock TQ Time PF Time Diff Time List Time Seed Time ...
# time [s] [s] Time [s] [CPU-s] [CPU-s] [CPU-s] [CPU-s] [CPU-s] ...
0.2500000 3.375000 3.422000 3.312500 0.000000 0.4687500E-01 0.000000 3.328125
0.5000000 8.468750 8.578000 6.828125 0.000000 1.125000 0.000000 6.796875
0.7500000 11.12500 11.23400 8.406250 0.1562500E-01 2.171875 0.1562500E-01 8.375000
1.000000 13.71875 13.82800 9.984375 0.1562500E-01 3.187500 0.1562500E-01 9.953125
1.250000 16.92188 17.12500 11.78125 0.1562500E-01 4.187500 0.1562500E-01 11.51562
The times are cumulative, so, typically, one looks at the latest output to get an overview where cpu time has been spent up to now. The first column is the simulation time which is identical to the first column in the .TabL file. The following two columns contain the total CPU time and the Wallclock time. If the second is considerably larger than the first, the process did not get full processor time. The reason can be processor overload or too frequent writing over a slow network connection (e.g. .TabL!).
The following columns give the cumulative CPU time which was spent in different parts of the code:
TQ Time: time spent inside the TQ subroutines. It depends mainly on the amount of interface cells and the relinearisation conditions, but also on the number of components and on numerical issues. The option "database global" can significantly reduce the TQ time, but should be used with care. The .TabTQ text output gives further details on the distribution on the different phase interaction, the graphical .numR output on the spacial distribution, i.e. which grid cells are responsible for the time loss. In your case, I assume the TQ time to be the most critical part (see below).
PF Time: time spent inside the phase-field solver. The value typically increases with the lenght of the interface and nTupelo lists and with decreasing time step.
Diff time: time spent inside the diffusion solver (including solute redistribution). If this is most of the total CPU time, nothing can be done apart from reducing resolution or changing diffusion data. If PF Time and List Time are also high, a considerable part of the Diff Time is related to the solute redistribution, and the value will automatically decrease if the latter two can be controlled.
List Time: time spent for list administration. This value typically goes parallel with the PF Time.
Seed Time: time spent for nucleation checking. In case of TQ coupling, this time also appears in TQ Time. Reasons for extreme values are typically too frequent checking or too small shield distance
Enthalpy Time: Only relevant with TQ and release of latent heat. In the current version, it depends mainly on the number of phases and the time step, in future versions it can be controlled via an update frequency for enthalpy data. The time is also included into the TQ Time.
Stress Time: Only relevant with stress coupling
In your example, I assume that the TQ Time will be predominant. You have defined a double relinearisation scheme, i.e. update thermodynamic data all 5 seconds and additionally if an "effective" temperature deviation value is found in any of the cells of an interface. The lots of outputs which you are referring to are consuming a lot of time!
Secondly, you should check whether you are occasionally using Release 5.501. Due to a compilation problem, this version is much slower than it should be, please download Release 5.502 from our website "ftp://micress@ftp.access.rwth-aachen.de"!
Bernd
In general, in order to check and optimize performance, one first should look up the .TabP output file. This text file is written with the same frequency as the .TabL and gives a summary in which parts of the code time was spent:
# Simulation CPU Time Wallclock TQ Time PF Time Diff Time List Time Seed Time ...
# time [s] [s] Time [s] [CPU-s] [CPU-s] [CPU-s] [CPU-s] [CPU-s] ...
0.2500000 3.375000 3.422000 3.312500 0.000000 0.4687500E-01 0.000000 3.328125
0.5000000 8.468750 8.578000 6.828125 0.000000 1.125000 0.000000 6.796875
0.7500000 11.12500 11.23400 8.406250 0.1562500E-01 2.171875 0.1562500E-01 8.375000
1.000000 13.71875 13.82800 9.984375 0.1562500E-01 3.187500 0.1562500E-01 9.953125
1.250000 16.92188 17.12500 11.78125 0.1562500E-01 4.187500 0.1562500E-01 11.51562
The times are cumulative, so, typically, one looks at the latest output to get an overview where cpu time has been spent up to now. The first column is the simulation time which is identical to the first column in the .TabL file. The following two columns contain the total CPU time and the Wallclock time. If the second is considerably larger than the first, the process did not get full processor time. The reason can be processor overload or too frequent writing over a slow network connection (e.g. .TabL!).
The following columns give the cumulative CPU time which was spent in different parts of the code:
TQ Time: time spent inside the TQ subroutines. It depends mainly on the amount of interface cells and the relinearisation conditions, but also on the number of components and on numerical issues. The option "database global" can significantly reduce the TQ time, but should be used with care. The .TabTQ text output gives further details on the distribution on the different phase interaction, the graphical .numR output on the spacial distribution, i.e. which grid cells are responsible for the time loss. In your case, I assume the TQ time to be the most critical part (see below).
PF Time: time spent inside the phase-field solver. The value typically increases with the lenght of the interface and nTupelo lists and with decreasing time step.
Diff time: time spent inside the diffusion solver (including solute redistribution). If this is most of the total CPU time, nothing can be done apart from reducing resolution or changing diffusion data. If PF Time and List Time are also high, a considerable part of the Diff Time is related to the solute redistribution, and the value will automatically decrease if the latter two can be controlled.
List Time: time spent for list administration. This value typically goes parallel with the PF Time.
Seed Time: time spent for nucleation checking. In case of TQ coupling, this time also appears in TQ Time. Reasons for extreme values are typically too frequent checking or too small shield distance
Enthalpy Time: Only relevant with TQ and release of latent heat. In the current version, it depends mainly on the number of phases and the time step, in future versions it can be controlled via an update frequency for enthalpy data. The time is also included into the TQ Time.
Stress Time: Only relevant with stress coupling
In your example, I assume that the TQ Time will be predominant. You have defined a double relinearisation scheme, i.e. update thermodynamic data all 5 seconds and additionally if an "effective" temperature deviation value is found in any of the cells of an interface. The lots of outputs which you are referring to are consuming a lot of time!
Secondly, you should check whether you are occasionally using Release 5.501. Due to a compilation problem, this version is much slower than it should be, please download Release 5.502 from our website "ftp://micress@ftp.access.rwth-aachen.de"!
Bernd
Re: Output and input files format
Dear Dr. Böttger,
Thank you for your reply. I changed the following to get rid of the double relinearisation scheme ( as mentioned in your reply:
In your example, I assume that the TQ Time will be predominant. You have defined a double relinearisation scheme, i.e. update thermodynamic data all 5 seconds and additionally if an "effective" temperature deviation value is found in any of the cells of an interface. The lots of outputs which you are referring to are consuming a lot of time! )
# Maximal allowed local temperature deviation [K]
-1.0000000000000000
But now I have the following comments in the log file:
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 43 196
time: 77.958703897502858 s
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 43 196
time: 77.963024833671255 s
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 118 188
time: 77.965790773343940 s
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 43 196
time: 77.967306092992644 s
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 47 195
time: 77.968566039010085 s
.....................................................
with the occasional comment:----
Serious error in linearisation! 1
Please let me know what can I do now.
Best regards,
Krishnendu
Thank you for your reply. I changed the following to get rid of the double relinearisation scheme ( as mentioned in your reply:
In your example, I assume that the TQ Time will be predominant. You have defined a double relinearisation scheme, i.e. update thermodynamic data all 5 seconds and additionally if an "effective" temperature deviation value is found in any of the cells of an interface. The lots of outputs which you are referring to are consuming a lot of time! )
# Maximal allowed local temperature deviation [K]
-1.0000000000000000
But now I have the following comments in the log file:
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 43 196
time: 77.958703897502858 s
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 43 196
time: 77.963024833671255 s
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 118 188
time: 77.965790773343940 s
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 43 196
time: 77.967306092992644 s
ERROR RETURN FROM solveCNewton BECAUSE THERE HAVE BEEN
Error number 3 in Interface 47 195
time: 77.968566039010085 s
.....................................................
with the occasional comment:----
Serious error in linearisation! 1
Please let me know what can I do now.
Best regards,
Krishnendu
Re: Output and input files format
Dear Krishnendu,
If I understood you correctly, you only removed the automatic relinearisation if a maximal allowed temperature deviation is exceeded, but you kept the updating interval of 5 seconds. That means, the initialisation and regular updating is working correctly, and the error you showed me occurs at a later stage! (if this is not the case, you should show me the first error messages which occur...).
The error messages just say that for the given grain interactions (43/196 etc.), the iterative calculation of the quasi-equilibrium failed because the maximum number of iterations was exceeded.
"Serious error in linearisation!" means that despite of several trials no new quasi-equilibrium could be calculated, and the old one was retained.
There are hundreds of possible reasons for this behaviour, as all kinds of numerical instabilities may lead to problems with iteration of the quasi-equilibrium. Therefore, without knowing more details, I cannot tell you what could be the reason...
One starting point could be the question whether this error did also occur before you removed the automatic updating on a temperature deviation. If not, i.e. if you passed 77.96 seconds of simulation without having this problem, then a more frequent updating of the thermodynamic data (e.g. all 1 second instead of 5) could help!
Bernd
If I understood you correctly, you only removed the automatic relinearisation if a maximal allowed temperature deviation is exceeded, but you kept the updating interval of 5 seconds. That means, the initialisation and regular updating is working correctly, and the error you showed me occurs at a later stage! (if this is not the case, you should show me the first error messages which occur...).
The error messages just say that for the given grain interactions (43/196 etc.), the iterative calculation of the quasi-equilibrium failed because the maximum number of iterations was exceeded.
"Serious error in linearisation!" means that despite of several trials no new quasi-equilibrium could be calculated, and the old one was retained.
There are hundreds of possible reasons for this behaviour, as all kinds of numerical instabilities may lead to problems with iteration of the quasi-equilibrium. Therefore, without knowing more details, I cannot tell you what could be the reason...
One starting point could be the question whether this error did also occur before you removed the automatic updating on a temperature deviation. If not, i.e. if you passed 77.96 seconds of simulation without having this problem, then a more frequent updating of the thermodynamic data (e.g. all 1 second instead of 5) could help!
Bernd