CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > ANSYS > CFX

CFX error code 24

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 17, 2012, 06:37
Default CFX error code 24
  #1
New Member
 
Join Date: Oct 2010
Posts: 29
Rep Power: 15
Silmaril is on a distinguished road
Hi,

I'm studying the coupling between a thermal-hydraulic 1D-code and CFX.

I wrote some junction box routines in order to transfer data between the code every time step. The transfer seems to work correctly and the coupling procedes through the time steps, unfortunately I get a "random error":

In different runs, without any change in both the junction box program in or the case setup (both CFX and 1D code), I get the following error at different time steps (in a random way...).

_______________________________ERROR______________ _______________

...

File E:\Work\Work_CFX\hk2b\JunctionBox_02\InletVelocity _27.txt opened
LOCDAT VEL_IN (CRESLT):GOOD
LOCDAT VEL_IN (CDTYPE):REAL
LOCDAT VEL_IN (ISIZE): 1
LOCDAT VEL_IN (JADRES): 255424
Check before read VEL_IN

+--------------------------------------------------------------------+
| An error has occurred in cfx5solve: |
| |
| The ANSYS CFX solver exited with return code 24. No results file |
| has been created. |
+--------------------------------------------------------------------+
__________________________________________________ _______________


With some print debugging of the junction box results (that in part can be seen above) I found that the error comes during the READ of a value (written in the "E:\Work\Work_CFX\hk2b\Prova_JunctionBox_02\InletV elocity_27.txt" text file into a previosly defined MEMORY DATA AREA=VEL_IN (which is checked for existence with the LOCDAT function whose result are printed).

I don't know what kind of error the "code 24" is and how can this come in a random way (at different and not predictable time steps)

Thanks in advance

Lorenzo
Silmaril is offline   Reply With Quote

Old   July 17, 2012, 20:23
Default
  #2
Super Moderator
 
Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 17,665
Rep Power: 143
ghorrocks is just really niceghorrocks is just really niceghorrocks is just really niceghorrocks is just really nice
The CFX error numbers are not defined and I don't know why they use them. It is a bit silly really.

Have you checked that you are not read or writing the file while the other package is reading or writing? This could cause random failures. You need a good handshaking technique to avoid this.
ghorrocks is offline   Reply With Quote

Old   July 18, 2012, 04:05
Default
  #3
New Member
 
Join Date: Oct 2010
Posts: 29
Rep Power: 15
Silmaril is on a distinguished road
Actually the file to be written (and read by the CFX) is very short, in this case just a real number. I checked that the other code write the file and close it. I tried to set a little delay before reading the file from CFX, even if this could cause quite a dead time in long transients, but the random error keep coming...

Is it possible that somehow the memory area VEL_IN is corrupted or changed in position by other programs? If this is possible, how can I protect those areas? I cannot immagine other ways that can bring to this random error....

If anything else works, maybe the next step is to go from Windows to Linux....

I write below the part of the fortran routine where the CFX stops (more or less the part of the code that produces the output I posted before)

___________________PART OF JUNCTION BOX ROUTINE_____________________

...
C Read data from file.
C
ICHANNEL=79
OPEN(ICHANNEL,FILE=INPUT_FILE)
C
C Send any diagnostic messages via master process.
CALL MESAGE('WRITE','File '//INPUT_FILE//' opened')
C
C Locates the DATA AREA 'VEL_IN' if exists and gives information
CALL LOCDAT('VEL_IN',CDTYPE,'SKIP',ISIZE,JADRES,CRESLT)
C
C Send any diagnostic messages via master process.
CALL MESAGE('WRITE','LOCDAT VEL_IN (CRESLT):'//CRESLT)
C
IF (CRESLT .EQ. 'GOOD') THEN
CALL MESAGE('WRITE','LOCDAT VEL_IN (CDTYPE):'//CDTYPE)
CALL MESAGE('WRITE','LOCDAT VEL_IN (ISIZE):'//CFROMI(ISIZE))
CALL MESAGE('WRITE','LOCDAT VEL_IN (JADRES):'//CFROMI(JADRES))
ELSE
C
C Create space for VEL_IN
CALL MAKDAT('VEL_IN','REAL','STOP',1,pV, CRESLT)
C
C Send any diagnostic messages via master process.
CALL MESAGE('WRITE','CRESLT (MAKDAT): '//CRESLT)
CALL MESAGE('WRITE','Creating Data Areas VEL_IN: OK!')
END IF
C
C Little delay to be sure that file to be read is ready.
I=0
DO WHILE (I .LE. 10000)
I=I+1
END DO
C
CALL MESAGE('WRITE','Check before read VEL_IN')
C
C Read data in VEL_IN (Where probably things goes wrong, checking the output file)
READ (ICHANNEL,*) VEL_IN
CALL POKER('VEL_IN',1,VEL_IN,'STOP',CRESLT,RZ)
C
CALL MESAGE('WRITE','CRESLT (POKER): '//CRESLT)
CALL MESAGE('WRITE','VEL_IN:'//CFROMR(VEL_IN))
C
CLOSE(ICHANNEL)
C
CALL MESAGE('WRITE','CLOSE: OK!')
__________________________________________________ __________________

Thank you very much for your help

Lorenzo

Last edited by Silmaril; July 18, 2012 at 04:27.
Silmaril is offline   Reply With Quote

Old   July 18, 2012, 06:19
Default
  #4
Senior Member
 
Join Date: Jul 2011
Location: Berlin, Germany
Posts: 173
Rep Power: 14
monkey1 is on a distinguished road
How is your input file you want to read and save into VEL_IN looking like (first line will be enough).
Why I am asking...as far as I can remember FORTRAN only reads one value at a time. So if you have several values in one line it can cause a problem. Even so if in the first line of the file you have a "Header"
Nevertheless your "READ (ICHANNEL,*) VEL_IN" will only read one single value. VEL_IN certainly is a scalar variable (?!?) if not the increments for a vector are missing and the read command will be executed only once....

Meaning you open the file
read the first value
close the file

as far as I can see in your code.
monkey1 is offline   Reply With Quote

Old   July 18, 2012, 06:39
Default
  #5
New Member
 
Join Date: Oct 2010
Posts: 29
Rep Power: 15
Silmaril is on a distinguished road
Actually the file contain at the first (and only) line, just one single real value
(say 2.097373E+00, that I've copied from the actual file that returns the error).

The VEL_IN memory area is defined as a single REAL data (not a vector) as written in the MAKDAT part of the code (that I repeat below)

__________________________________________________ _______

...
C Create space for VEL_IN
CALL MAKDAT('VEL_IN','REAL','STOP',1,pV, CRESLT)
...
__________________________________________________ ________

Also, the strange thing is that if the error was in the definition of the data area or in the value written in the file, the CFX should stop at the first call (first time step, @User Input), and not in some random time step later....

I also checked that the same data that in one run cause the crush, in a different call doesn't cause any problem.....

Don't know how to deal with this random error....

Thanks for helping

Lorenzo
Silmaril is offline   Reply With Quote

Old   July 18, 2012, 07:03
Default
  #6
Senior Member
 
Join Date: Jul 2011
Location: Berlin, Germany
Posts: 173
Rep Power: 14
monkey1 is on a distinguished road
Hmm...is the value in the file being changed troughout your calculation run?
Meaning, can it be that at some point there is no or wrong data in the file???
monkey1 is offline   Reply With Quote

Old   July 18, 2012, 09:26
Default
  #7
New Member
 
Join Date: Oct 2010
Posts: 29
Rep Power: 15
Silmaril is on a distinguished road
The value is changed every time step, actually a new file is created every time step, where the CFX should read the value to be used as boundary condition. After the CFX error I also checked for existence of the file and its contents, and value seems right: only 1 line, only one REAL value, exponential notation and no strange characters....
Silmaril is offline   Reply With Quote

Old   July 18, 2012, 09:58
Default
  #8
Senior Member
 
Join Date: Jul 2011
Location: Berlin, Germany
Posts: 173
Rep Power: 14
monkey1 is on a distinguished road
Strange...
Are we looking at wrong location maybe?
Do you print out the VEL_IN variable each time (write (*,*) VEL_IN)? Maybe you can see then what happens before the crash...Maybe there is a point in the simulation were suddenly there isn't a number anymore...???
monkey1 is offline   Reply With Quote

Old   July 18, 2012, 10:10
Default
  #9
New Member
 
Join Date: Oct 2010
Posts: 29
Rep Power: 15
Silmaril is on a distinguished road
Will try this too....

I think the problem rises somewhere between the file creation and the read....

I tried to do the same simulations without the external coupling but putting directly the same files (already created and written by me manually) in the working folder. In this way the problem seems to vanish......
Silmaril is offline   Reply With Quote

Old   July 18, 2012, 10:48
Default
  #10
Senior Member
 
Join Date: Jul 2011
Location: Berlin, Germany
Posts: 173
Rep Power: 14
monkey1 is on a distinguished road
definitly seems as if there is smth strange happening during the calculation leading to a situation where u suddenly have smth in the file that does not correspond to the expected value anymore...
Could only guess that there might be an error (?) in the routine with which u recalculated VEL_IN before writing it to file.
monkey1 is offline   Reply With Quote

Old   July 18, 2012, 11:11
Default
  #11
New Member
 
Join Date: Oct 2010
Posts: 29
Rep Power: 15
Silmaril is on a distinguished road
Can be, but why the error happens randomly....?
I don't know what to search that can cause the randomness of the crush.
Silmaril is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
CFX Treatment of Laminar and Turbulent Flows Jade M CFX 18 September 15, 2022 08:08
High Resolution (CFX) vs 2nd Order Upwind (Fluent) gravis ANSYS 3 March 24, 2011 03:43
CFX pressure in Simulations problem nasdak CFX 1 April 14, 2010 14:22
PhD using CFX Rui CFX 9 May 28, 2007 06:59
FSI using CFX and ANSYS Bi Chang CFX 2 May 10, 2005 05:47


All times are GMT -4. The time now is 04:06.