|
[Sponsors] |
June 6, 2005, 16:34 |
Anyone met this strange problem?
|
#1 |
Guest
Posts: n/a
|
Dear all,
I met a strange problem that nearly made me crazy. I used Linux system to run a job that needs to read some experimental data from one external file. In my OS the absoft pro fortran 9.0 is installed. The star-cd version is 3.24. The job does with a transient and compressible flow. For the outlet region (only one) I defined pressure boundary type, for the inlet region before and after one specific time step, I changed the boundary type form pressure boundary into transient-wave transmissive boundary. When I let star-cd read some numbers of experiment data by using the bcdefp.f file, when this number (data number read by bcdefp.f, actually the data number is equal to the time step number) was different, it produced some different results. For example, when that number is bigger than or equal to 970, the error message is the following: *** GEOMETRICAL CALCULATIONS STARTED *** GEOMETRICAL CALCULATIONS COMPLETED [ 1 ] ***Received signal sigsegv - exiting star: tfile.c:383: tmpclose_: Assertion `TmpFiles[*unit].Mode!=Unused' failed. /usr/local/mech/star/STAR/3.24.000/linux64_2.4-absoft_9.0a-glibc_2.2.5-dso/bin/star: line 3928: 9407 Aborted $PNP_STARLOADER$PNP_EXE PNP: Shutdown [2005-*-*-19:35:14] Execution aborted by request (SIGABRT) after 5 seconds (TOTAL ELAPSED TIME). When the number is between 864 and 969, the error message changed into the following: *** GEOMETRICAL CALCULATIONS STARTED *** GEOMETRICAL CALCULATIONS COMPLETED [ 1 ] ***Received signal sigsegv - exiting PNP: Shutdown [2005-*-*-19:38:06] Execution aborted by request (SIGABRT) after 3 seconds (TOTAL ELAPSED TIME). When the number is smaller than 864 and bigger than 840, the error message is changed as star: tfile.c:561: treadi__: Assertion `*n>=1' failed. /usr/local/mech/star/STAR/3.24.000/linux64_2.4-absoft_9.0a-glibc_2.2.5-dso/bin/star: line 3928: 9407 Aborted $PNP_STARLOADER$PNP_EXE PNP: Shutdown When the number is smaller than about 600, there were no error message coming out, but the simulated result was not good. When the number is smaller than 600 and when I used different number, for instances, 100 or 200, for the same mornitoring cell and for the first sevral time steps, the simulated results were a little different, even the STAR-cd read the same experimental data from the same file and the configurations of the model are the same! I don't know whether the problems are caused by the STAR-Cd or the Fortran compiler of both of them together, are there any people to meet the similiar problem before or do you have any idea about the reason to cause the problem? Thank you very much for your regards and your patience to finish reading this long ask-for-help post! Lee |
|
June 7, 2005, 04:15 |
Re: Anyone met this strange problem?
|
#2 |
Guest
Posts: n/a
|
Sounds like a bug, we probably can't help you on this forum, but your star support people should be able to help.
|
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Strange problem | Steven | CFX | 2 | March 11, 2008 05:23 |
Please help see this strange problem | liugx212 | OpenFOAM Running, Solving & CFD | 3 | February 23, 2006 19:03 |
CHT strange problem | MatejK | CFX | 3 | September 1, 2005 06:32 |
A strange problem | Lee | Siemens | 0 | April 3, 2005 13:33 |
A STRANGE PROBLEM!!! | Fanadam | FLUENT | 7 | April 13, 2003 15:58 |