Hi Bernd!
After starting the simulation with Micress the simulation crashes. Then i looked into the documentation file of this simulation and an error named ERROR 78 appered. My guess is that something isn't right with my *.dri-file. Perhaps you need some details of the documentation:
...
# Beginning of initialisation
# ===========================
# Routine init calls routine initDateien
# Routine init calls routine initRand
# Routine init calls routine initWorkspace
# Routine init calls routine initFixeFelder
# Routine init calls routine initPointer
# Routine init calls routine initIFaceSharp
# Grain number 1 set
# Grain number 2 set
# Grain number 3 set
....
# Grain number 50 set
# Routine init calls routine initFracPhase
forrtl: error (78): process killed (SIGTERM)
Image PC Routine Line Source
MICRESS 08186D6A Unknown Unknown Unknown
MICRESS 08194FB1 Unknown Unknown Unknown
MICRESS 08054D2F Unknown Unknown Unknown
MICRESS 08054C81 Unknown Unknown Unknown
libc.so.6 0084AE9C Unknown Unknown Unknown
MICRESS 08054B91 Unknown Unknown Unknown
Can you tell me if something is wrong with the dri-file or should I search for an other reason?
An other question: Is there any Micress-documentation which contains any information about error-handling or error-documentation?
With kind regards
Karl
bugs
Post shifted to pre-processing board
This post has been shifted from the post-processing board to this place, because is obviously has nothing to do with post-processing (i.e. treatment of MICRESS simulation results etc.)!
admin
admin
Re: bugs
Dear Karl,
Welcome to the MICRESS forum and happy new year!
The error messages which you show us are not issued by MICRESS, they come from the operating system! The messages do not give any information why it happens.
In principle, it can be related to the data in the .dri file, for example, if the simulation domain is defined such big that the computer is running out of memory, of if you use combinations of input that are very unusual and which erroneously lead to a system crash.
Maybe, the fastest way to find out is to provide me with the .dri file (by posting to this forum or by e-mail). In the best case, I can find out the problem immediately, otherwise we have to consider installation problems or a specific bug, and have a closer look...
There is currently no specific document on error handling, we consider MICRESS error messages as self-explanatory - if a direct explanation can be given! Apart from that, of course, we have code-related internal error checks for in-house debugging which are not useful for external users.
Best regards
Bernd
Welcome to the MICRESS forum and happy new year!
The error messages which you show us are not issued by MICRESS, they come from the operating system! The messages do not give any information why it happens.
In principle, it can be related to the data in the .dri file, for example, if the simulation domain is defined such big that the computer is running out of memory, of if you use combinations of input that are very unusual and which erroneously lead to a system crash.
Maybe, the fastest way to find out is to provide me with the .dri file (by posting to this forum or by e-mail). In the best case, I can find out the problem immediately, otherwise we have to consider installation problems or a specific bug, and have a closer look...
There is currently no specific document on error handling, we consider MICRESS error messages as self-explanatory - if a direct explanation can be given! Apart from that, of course, we have code-related internal error checks for in-house debugging which are not useful for external users.
Best regards
Bernd
Re: bugs
Dear Karl,
thanks for sending me your input and screen output file from the crashing simulation. What I can see in the output file is the following:
...
# Other numerical parameters
# ==========================
# Phase minimum?
1.00E-04
# Interface thickness (in cells)?
# 'Driving file' read to the end. Reverting to keyboard input.
Input error in routine leseEingabe
Input: EOF
This looks like if MICRESS could not read the interface thickness, Please check if the input file is correct in this place!
Bernd
PS: The driving file you sent me is not consistent with the output file...
thanks for sending me your input and screen output file from the crashing simulation. What I can see in the output file is the following:
...
# Other numerical parameters
# ==========================
# Phase minimum?
1.00E-04
# Interface thickness (in cells)?
# 'Driving file' read to the end. Reverting to keyboard input.
Input error in routine leseEingabe
Input: EOF
This looks like if MICRESS could not read the interface thickness, Please check if the input file is correct in this place!
Bernd
PS: The driving file you sent me is not consistent with the output file...
Re: bugs
Hooray!
Everything seems to work properly!
I don't really know if the change from editing the dri-file in windows to linux has caused the problem, but in the end I just had to make sure that every input parameter is set in an own line. Thanks a lot Bernd.
While changing the parameters of the grid size and the size of the input picture of my microstructure , I wonder if they somehow are influencing each other.
A problem could exist if the txt-file of the picture hasn't the right size compared to the input parameters in the dri-file. Or,if it doesn't fits, is it possible that Micress scales the size of the txt file ?
And what about the grid size in connection with the txt file input in the dri file? Are they depending on each other?
With kind regards,
Karl
Everything seems to work properly!
I don't really know if the change from editing the dri-file in windows to linux has caused the problem, but in the end I just had to make sure that every input parameter is set in an own line. Thanks a lot Bernd.
While changing the parameters of the grid size and the size of the input picture of my microstructure , I wonder if they somehow are influencing each other.
A problem could exist if the txt-file of the picture hasn't the right size compared to the input parameters in the dri-file. Or,if it doesn't fits, is it possible that Micress scales the size of the txt file ?
And what about the grid size in connection with the txt file input in the dri file? Are they depending on each other?
With kind regards,
Karl
Re: bugs
Hi Karl,
nice to hear that the problem could be solved easily!
If you read an initial microstructure from an ASCII file, MICRESS always will interpolate the data such that it fits into the calculation domain which you specify in the .dri file. That means, the absolute size of the (experimental) microstructure is not taken into account.
Naturally, it is wise use a grid size which is identical (or a multiple) of the image size in order not to loose information by interpolation. And take care, if the relation between the number of grid points in x an z is not the same for the simulation domain and the text image file, the structure would be distorted!
Bernd
nice to hear that the problem could be solved easily!
If you read an initial microstructure from an ASCII file, MICRESS always will interpolate the data such that it fits into the calculation domain which you specify in the .dri file. That means, the absolute size of the (experimental) microstructure is not taken into account.
Naturally, it is wise use a grid size which is identical (or a multiple) of the image size in order not to loose information by interpolation. And take care, if the relation between the number of grid points in x an z is not the same for the simulation domain and the text image file, the structure would be distorted!
Bernd