CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Phoenics

F(1) over-written error

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

Reply
 
LinkBack Thread Tools Display Modes
Old   July 13, 2005, 06:35
Default F(1) over-written error
  #1
Olof Liungman
Guest
 
Posts: n/a
Hi!

I've moved ground.f, main.f and q1 from one machine running PHOENICS 3.2 (where everything works fine) to another running PHOENICS 3.5. I've adjusted the non-user section at the top of ground.f and changed NFDIM in main.f. Compiling and linking to produce earexe works fine as well as running satexe to read in the grid, the q1 and produce the eardat file. When executing earexe the run starts, but fails as soon as the integration of the equations begins with following error (clipped from the tail end of the file result):

--- INTEGRATION OF EQUATIONS BEGINS ---

stop because F(1) over-written in aftgrx location= 19 indvar = 13 izstep = 1 isweep = 1 istep = 1 ithyd = 1

error stop

Any ideas anyone? //Olof
  Reply With Quote

Old   July 14, 2005, 03:57
Default Re: F(1) over-written error
  #2
Mick
Guest
 
Posts: n/a
Just two things, Firstly did you cut and paste your old code into a newer V3.5 ground.f If not it may be worth carefully checking the top of ground to see if anything has changed, such as the common blocks. Also use the newer V3.5 main.f, otherwise you will have to compare the two carefully for any changes.

Then I would binary chop with write statements, to see which line in ground.f, (assuming this is the faulty file), causes the overwrite.

What it is likely to be is that you have zero storage for one of your variables, therefore the L0F location is zero and hence any F(L0F+icell) statement is likely to be overwriting the start of the F-Array.

You mention ground.f and not ground.for, if you are using UNIX, it is possible that you are losing your L0F location between calls to ground. If this is the case make sure you are saveing the variable with a SAVE statement after the variable declarations.

Good luck, shouldn't be too difficult to track down.
  Reply With Quote

Old   July 14, 2005, 04:09
Default Re: F(1) over-written error
  #3
Olof Liungman
Guest
 
Posts: n/a
Hi, Mick!

We've stripped ground down to bare essentials, and then did the same with the q1-file. Everything worked until I introduced the buoyancy term in the k-eps model:

PATCH(KEBUOY,PHASEM,1,NX,1,NY,1,NZ,1,LSTEP) COVAL(KEBUOY,KE,GRND4,GRND4) COVAL(KEBUOY,EP,GRND4,GRND4)

Adding these lines in q1 produces the error I reported. This works in 3.2 but not in 3.5. Unfortunately I do not have a web browser on the Linux server where 3.5 is installed and I can't find POLIS on the CHAM web site anymore. Any ideas?

//Olof
  Reply With Quote

Old   July 14, 2005, 05:28
Default Re: F(1) over-written error
  #4
Olof Liungman
Guest
 
Posts: n/a
Hi again!

I've tried mostly everything, stripping away lines in q1 and user-coding in ground.f, but the only change that works is removing the buoyancy source for EP, i.e. removing the line

COVAL(KEBUOY,EP,GRND4,GRND4)

This is all that is required. I'm still using the k-eps model, with buoyancy, wind-induced surface sources, etc. All settings have been used by us for many years in different versions of PHOENICS. Strange, isn't it?

I am running PHOENICS 3.5 on a Linux RedHat server.

//Olof

  Reply With Quote

Old   July 20, 2005, 05:08
Default Re: F(1) over-written error
  #5
Mike
Guest
 
Posts: n/a
Olof, How are you? This may be cause of your problem:

DESCRIPTION OF PROBLEM: If KE buoyancy patches are active and EPKE is not stored, then a crash will occur from a F-array overwrite in gxgenk- sub gxkegb. This does not happen if KELIN=3, hence has remained unnoticed to date.

CAUSE OF THE PROBLEM TO BE FILLED IN WHEN KNOWN: In GRP 13 SCT 16 of GXKEBG, the following line will cause the problem.

IF(LBEPKE.EQ.0) F(L0EPKE+IJ) = GEPDK

As EPKE is not stored, writing to F(L0EPKE+IJ) will cause an F-array overwrite. The fix I have forwarded to the customer is to rewrite the line as

IF(LBEPKE.EQ.0)THEN

L0EPKE=L0F(LBEPKE)

F(L0EPKE+IJ)=GEPDK

ENDIF

ACTION: Cause known

PASSED TO DEVELOPMENT ON (date): 15.04.05

STATUS (ie corrected or outstanding): JCL 13.05.05 The analysis of the problem appears to be faulty. If LBEPKE=0, attempting to get an L0F of it will result in an error stop. The line higher up which allocates L0EPKE is protected by (IF(LBEPKE.NE.0). This is what should be used in group 13 as well.

I recommend that the erroneous line be replaced by

IF(LBEPKE.NE.0) F(L0EPKE+IJ) = GEPDK

A modifed GXGENK.HTM is placed in G:\D_36BUGS\EARTH\021\GXHENK.HTM.

Best regards, Mike
  Reply With Quote

Old   October 27, 2005, 13:52
Default Re: F(1) over-written error
  #6
PattiMichelle
Guest
 
Posts: n/a
I had gotten an F(1) overwritten error when trying to run CHEMKIN runs written for version 3.4 in version 3.6.0 (after adjusting for the different CKlinking files). One way I was able to get them to run was by re-writing the entire model from scratch in the VR-Editor. There may be parsing errors in the VR-Editor's interpreter - maybe the VR-Editor should also keep a binary file that the user can't modify?

  Reply With Quote

Reply

Thread Tools
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 On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
I HAVE WRITTEN A 2D EULER SOLVER prapanj Main CFD Forum 13 July 24, 2014 15:30
What information in written in phi henning OpenFOAM Running, Solving & CFD 1 October 9, 2008 14:03
FluentMeshToFoam no set written kian OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 2 May 25, 2007 12:04
Dictionaries written by FoamX Mattijs Janssens (Mattijs) OpenFOAM Pre-Processing 1 January 3, 2005 14:44
Where case files are written ereiss FLUENT 3 July 9, 2004 02:24


All times are GMT -4. The time now is 18:42.