Hotfixes to C96
Home Up C94.00 Other versions Revision history The future etcetera Acknowledgements Contacts, Mailing list Links Site map, search

 

Home
Up

 

These are small changes that will be incorporated in the next revision of the code, or ways to work around problems in the current version. These only apply to the current version of the code stored on this site. In the following, the corrections that should be made are indicated by line numbers within specific files.

These corrections where not present when the output from the downloaded test suite was created.  The tests should be run before these are applied.

Hot fixes to C96 beta 5

Hot fixes to C96 beta 4

A loop variable was misset and would cause the the punch gammas command to throw an exception.  Edit file punchdo.c, and change the code around line 1001 to read

for( j=0; j < yield.nyield[nelem][ion][ns]; j++ )
{
        fprintf( punch.ipPnunit[i], "%5.2f", yield.vyield[nelem][ion][ns][j] );
}

Be careful!  There are three changes of i into j on the line beginning with "for", and only one change on the line starting with "fprintf".  Change the last i, but not the first, on this line.  Thanks to Antonella Natta for pointing out this problem.  2002 June 12.

The print line sum command cannot be used in a grid or optimization run.  This will be fixed in the next release.  Thanks to Melekh Bohdan for finding this problem. 2003 Jan 23

The code can stop due to a negative hydrogen molecule abundance for some models.  An updated version of hmole.c is available here.  Replace the version in the distribution with this file.  Thanks to Andrey Kravtsov for discovering this problem.  2002 June 9.

The code can throw a false assert for some predominantly molecular models.  Edit routine prtcomment.c and delete line 1555, which reads

ASSERT( heat.power > 0. );

Thanks to Andrey Kravtsov for discovering this problem.  2002 June 10.

Hot Fixes to C96 beta 3

These are small changes that will be incorporated in the next revision of the code, or ways to work around problems in the current version. These only apply to the current version of the code stored on this site. In the following, the corrections that should be made are indicated by line numbers within specific files.

crash in cddrive.c on Suns

The code can crash on a Sun.  Several edits are required, and the repaired source for this routine is available here. Replace the original copy of this routine with the altered copy if you are using a Sun.

Thanks to Peter van Hoof for solving this problem.  2002 May 16.

NOTE:  The version of the source posted on 2002 March 14 has the following changes included.  Downloads after that date do not need to have these changes included, only those proceeding this notice.

crash in rtmakestat.c on Suns

The code can crash on a Sun due to the order in which certain terms in the photon pumping rate were calculated.  The solution is to force a particular order by imposing parenthesis.  Several edits are required, and the repaired source for this routine is available here (unix eol). Replace the original copy of this routine with the altered copy if you are using a Sun.

Thanks to Kevin Volk for discovering the problem, and to Peter van Hoof for its solution.  2002 March 14.

botched asserts in atomseqboron.c with gcc

The test for the values of some floating point numbers was too stringent, and could fail under some circumstances.  Edit atomseqboron.c and change lines 299 - 310 to read as follows:

assert( fabs(t10->gLo/2.-1.) < 10.*FLT_EPSILON);
assert( fabs(t10->gHi/4.-1.) < 10.*FLT_EPSILON);
assert( fabs(t20->gLo/2.-1.) < 10.*FLT_EPSILON);
assert( fabs(t20->gHi/2.-1.) < 10.*FLT_EPSILON);
assert( fabs(t30->gLo/2.-1.) < 10.*FLT_EPSILON);
assert( fabs(t30->gHi/4.-1.) < 10.*FLT_EPSILON);
assert( fabs(t21->gLo/4.-1.) < 10.*FLT_EPSILON);
assert( fabs(t21->gHi/2.-1.) < 10.*FLT_EPSILON);
assert( fabs(t31->gLo/4.-1.) < 10.*FLT_EPSILON);
assert( fabs(t31->gHi/4.-1.) < 10.*FLT_EPSILON);
assert( fabs(t41->gLo/4.-1.) < 10.*FLT_EPSILON);
assert( fabs(t41->gHi/6.-1.) < 10.*FLT_EPSILON);

That is, change all occurrences of FLT_MIN to FLT_EPSILON in this file.

Thanks to Bohdan Melekh for discovering the problem, and to Peter van Hoof for its solution. 2002 March 11.  This fix is included in source downloaded after 14 March 2002.

FeII atom could divide by zero for some models

In routine pop371.c, change line 943 to read as follows:

/* ratio of collisional (new) to pumped excitations */

/* >>chng 02 mar 04, add test MAX2 to prevent div by zero */

Fe2LevN[ipHi][ipLo].ColOvTot = (float)(Fe2Coll[ipLo][ipHi]*phycon.eden /

MAX2(SMALLFLOAT , Fe2Coll[ipLo][ipHi]*phycon.eden + Fe2CPump[ipLo][ipHi] + Fe2LPump[ipLo][ipHi] ) );

Thanks to Yumihiko Tsuzuki, Kevin Volk for finding this problem.  2002 March 07

Code to check that gcc 2.96 is not being used.

This version of gcc is broken and must not be used.  The following code was added following line 176 of cdinit.c:

/* check that we ARE NOT being compiled by gcc version 2.96 */

# if __GNUC__ == 2 && __GNUC_MINOR__ == 96

fprintf(ioQQQ,"You are compiling with gcc 2.96!\n");

fprintf(ioQQQ,"This version cannot compile Cloudy and must not be used!\n");

fprintf(ioQQQ,"Use kgcc or update gcc to a functional version.\n");

puts( "[Stop in cdInit]" );

cdEXIT(1);

# endif

This is already included in all downloads after 2002 Feb 27.

This code, provided by Peter van Hoof, checks that version 2.96 of gcc is not being used.  This version of gcc cannot compile the Linux kernel or Cloudy, but is included in many Linux distributions.  If you have version 2.96 of gcc then you probably also have the "kernel compiler", kgcc, which is an older version of gcc.  Use that instead.  This is discussed on the compiling Cloudy page of this web site.

Hot Fixes to C96 beta 2

These are small changes that will be incorporated in the next revision of the code, or ways to work around problems in the current version. These only apply to the current version of the code stored on this site. In the following, the corrections that should be made are indicated by line numbers within specific files.

Space allocated for grains was not returned when cdNoExec was used in a large grid of calculations.  The result is that the code will eventually use all memory in the system and fail.  This only happened when the code is used as a subroutine, and cdNoExec is called to test the grid without computing.  To fix, change line 105 of cloudy.c from

if( noexec.lgNoExec )
return(0);

to

/* this is an option to stop after printing header only */
if( noexec.lgNoExec )
{
     /* >>>chng 01 may 08, return memory allocated for grains, PvH */
     ReturnGrainBins();
     return(0);
}

Thanks to Kirk Korista for discovering the problem, and to Peter van Hoof for fixing it.  2001 May 08.

Hit Counter
Last changed 03/31/03.
Return to the Cloudy Home Page.
Copyright 1978-2003 Gary J. Ferland