4.51 Bugs You Should Know About

BUG: Thordbfix451 #1


Thordbfix451 (actually its auxilliary script, thordbfix451_rebuild) complains that it cannot open the thorserverXXXXX.log file, then thorchange fails to connect. However, the specified log file is indeed present.

The Cause:

The Thorserver may take several seconds to start up and create the log file on a busy system. The log file is not created in time for the script to read it.

The Fix:

A slight change forces thordbfix451_rebuild to wait until the Thorserver log file is created before proceeding. Download this new version here:

thordbfix451_rebuild (Revised 20-May-1997)

Install by replacing $DY_ROOT/bin/thordbfix451_rebuild with this file.

BUG: Thordbfix451 #2


John Bradshaw from GlaxoWelcome has discovered...

44* versions allowed the indirect datatype to be defined as

_V<Indirect reference>
_B<Indir Ref>
_S<Indirect reference for solvents, footnotes, citations, error levels,

whereas it should be

_S<Indirect key (used internally)>
_D<Indirect key, used in the indirect-data database>

When you run thordbfix451 the shell has no way of knowing that there are
insufficient fields defined and the load stops.

We may be odd in having a fair number of legacy databases but the
following works as a fix *before* running thordbfix451, script1.

This works for all databases with the same executive password. As we have
over 250 to convert then it is worth doing this. I accept it arises from
bad database management on our part, many came from the VAX, however there
may be others who have had similar problems. Having had problems with
users redefining the FP datatypes I have encouraged them to leave the
standard ones alone. Unfortunately the $I datatypes was never upgraded in
our standard set. BTW an equivalent shell fixes the fp datatype, script2.

BUG: Thordbfix451 #3

Please note that all database-passwords must be removed before using Thordbfix451.

BUG: Linking Toolkit Programs on IRIX 6.4


An error results when trying to link to the default Daylight toolkit libraries (in $DY_ROOT/lib).

The error message will resemble:

ld32: FATAL 112: cannot link old 32-bit object with -n32 link:

The Cause:

The default cc options on IRIX 6.4 include "-n32" which specify the use of "new-format" 32-bit objects. The 4.51 libraries in $DY_ROOT/lib are linked on IRIX 5.3, and are "old-format" 32-bit objects.

The Fix:

Set the environment variable SGI_ABI to "-32" (Application Binary Interface) as follows:

setenv SGI_ABI "-32"   (csh)

export SGI_ABI

BUG: FP Datatype incorrect in some databases


Similarity searching doesn't work in some databases. You'll get an error message:

ERROR: This database has no fingerprints, can't do similarity search (dy_mp_similar_setup)

although this is not exactly true, they're just not loaded.

Another symptom is that sub- and super-structure searching are slow with these databases, since they're not using fingerprints.

This is known to be true for the following databases:

  1. ic97_datatypes
The Cause:

The "FP" (Fingerprint) datatype is defined incorrectly. The _P specification does not instruct the Merlinserver to load the bitmap (first field).

The Fix:

Change the _P<> dataitem in the $D<FP> datatype definition TDT to: _P<*;*;*;*;*;> One simple way to do this is to overwrite the entire FP datatype. Save the following to a file, say "FP.tdt":

_V<"Fingerprint;Orig nbits;Orig nbits set;Nbits;Nbits set;Version;ID">
_S<"Fingerprint of molecule, used for high-speed screening and similarity;Original size;Original number of bits set;Folded size;Number of bitsset">
_D<"Bitmap of structural features for screening;Number of bits in bitmap before folding;Number of 1's in bitmap before folding;Number of bits in folded bitmap;Number of 1's in folded bitmap">
_O<Daylight Chemical Information Systems, Inc.>

For your downloading convenience, here's a hyperlink to a separate file FP.tdt.

The correct FP datatype can also be found in the file $DY_ROOT/data/datatypes/std_datatypes.dcis.tdt.

Next, load this datatype and overwrite the incorrect FP datatype:

thorload -merge FALSE -overwrite TRUE ic97_datatypes < FP.tdt

Finally, reload the Merlin pool so the FPs can be correctly loaded.

BUG: ClogP output missing measured LogP values


ClogP calculations are missing LogP-star values (P1 data).


The file "logpstar97.smi" was not included in $DY_ROOT/data. This file contains 9853 high confidence "LogP-star" values which should be output for their associated SMILES with the ClogP calculation. This will not be true with 4.51 as released.


Download the text file logpstar97.smi (330K) and install it in the directory v451/data. ClogP should now work correctly. Test it with a SMILES in the file such as "CCO". The P1 value -0.31 should be output with the ClogP.

BUG: CX_ROOT definition incorrect


The Ruby test program (http:/dayhtml/test-ruby.html) does not work.


The file $DY_ROOT/daycgi/dcgi_env.sh incorrectly defines CX_ROOT. Change this line to:


(i.e., put the exotic back in cex).

BUG: Thorserver may corrupt databases on write

Thorserver Patch Available

A Thorserver bug was discovered which can corrupt a database when writing to it. Corruption occurs when a newly added record is subsequently reduced in size by more than 32 bytes. One fortunate fact is that no data is lost due to this bug. The corrupt portion of the .DP file is separate from the correctly overwritten TDT, and thordump skips these corrupt bytes successfully. Thus, a database can be rebuilt without loss with a thordump/thormake/thorload procedure. Corruption in the database is indicated by inability to load the database with the Merlinserver, and errors reported by thordump.

A fix has been made to the Thorserver which corrects this bug. This fixed Thorserver should be installed and replace the 4.51 Thorserver as a patch.

To obtain this new thorserver:

    % ftp daylight.daylight.com                 <<--- Or:
    Name (...): anonymous                       <<--- log in as "anonymous"
    Password:                                   <<--- Use your email address
    ftp> cd outgoing/tp22                       <<--- Note: dir isn't readable!
    ftp> bin                                    <<--- Don't forget this step!!
    ftp> get thorserver.sun5.patch.gz           <<--- ...or...
    ftp> get thorserver.sgi5.patch.gz
    ftp> quit

Thank you to WRAIR, Novartis, and Roche for showing us this.

BUG: CLOGP Fragment Database "Full"


The file $DY_ROOT/data/fragdb451.dat contains 607 fragments. However, "clogp +PCMODELS_DUMPFRAGDB" only dumps definitions for 600 fragments. Any fragments put in a fragdb.del file or appended to the end of fragdb451.dat are ignored.


Clogp (a Fortran program) only allocates space for 600 fragment definitions in the 4.51 version. This will be fixed in 4.52.


Since there can only be 600 fragments, if you wish to add fragments to the fragment database, some other fragments must be removed or placed at the end of fragdb451.dat.

BUG: Nearneighbors semaphore handling errors


When writing the output from nearneighbors to standard output, it is possible for semaphores to not be available. The semaphore key is incorrectly calculated to be (-1) in all cases, which can cause collisions. Nearneighbors will typically default to single-process mode when semaphores are not available.

Another possible symptom is truncated or corrupted output files when one nearneighbors (or another) job interferes with another by using the same semaphore (-1).


This is fixed for 4.52.


The work-around for 4.4 and 4.51 is to always specify the output filename for nearneighbors (rather than directing stdout with the '>' character). It is also recommended to always use the -NUM_PROCESSES option (with 1 or greater).

For example, use:

nearneighbors -NUM_PROCESSES 2 foobar.tdt foobar.nn.tdt
and NOT
nearneighbors -NUM_PROCESSES 2 foobar.tdt > foobar.nn.tdt