Search that never ends

JCHEM 2.1





context : a table containing 10000 structures registered with JCHEM





A search on structure "C1=CC=CC=C1" never ends ....


It works fine with any other structure !





There is no Exception (jc.getException returns null)








here is my code :





try {





JChemSearch jc=new JChemSearch();


jc.setConnectionHandler(connectionHandler);


jc.setQueryStructure("C1=CC=CC=C1");


jc.setStructureTable("DAG.STRUCTURE");


jc.setStructureCaching(false);


jc.setSearchType(JChemSearch.EXACT);


jc.setWaitingForResult(false);


jc.setDeleteFilterTableWhenReady(true);


jc.run();





while(jc.isRunning()) {


if(jc.getException()!=null) {


jc.getException().printStackTrace();


break;


}


System.out.println("searching");


}





System.out.println("end searching");





} catch(Exception e) { e.printStackTrace() }








this code displays "searching" endlessly .....

I could not reproduce the error.





You code would probably also finish execution after a long time.





This is because your code is not very efficient.





1. You do not have to call getException() all the time, becuse on any error the search will end anyway.





2. Most of the processor time is spent on writing the string "searching".


You should only write it in every second or so.





Please try to modify your code this way:

Code:

while(jc.isRunning()) {     Thread.sleep(1000);     System.out.println("searching"); } System.out.println("end of search"); Throwable e=jc.getException(); if (e!=null) {     System.err.println("---Exception in search: -----");     e.printStackTrace(); }

POJ wrote:

JCHEM 2.1

It may be worthwile to try a more recent JChem version. We constantly added bugfixes and stability features throughout the past year, and since 2.1. we had two final releases. (2.2 and 2.2.1)

This is of course not my real code; it is just meant to make you understand the problem.





I can't use version after 2.1 since you added additional information at the end of cd_smiles ....

Well, maybe you should produce some test code, that can reproduce your "endless search" problem.


Your posted code was tested fine against the same version (2.1).





The cd_smiles column's primary role is to achieve efficient structure search, in some cases plain SMILES is not enough to store all relevant information.





Could you tell me why it causes a problem for you ?





For displaying the SMILES, you can always:


- truncate the cd_smiles at the first space


- create a Molecule from cd_structure, and use Molecule.toFormat





We will also have an import option, that will convert relative stereo structures to absolute ("|r|" will be omitted).


Of course if the structure contains MDL specific information (like enhanced stereo), this information will appear in cd_smiles to ensure correct search results with optimal performance.


The only other option would be to set the cd_smiles to NULL in these cases, but that would reduce performance.

There may be a structure in your database that causes this problem. It is very improbable that this bug still exists if that structure is correct.





In the coming release relative stereo flag (|r|) can be left out of cd_smiles.


We will upload a new test release soon that should solve both the |r| and the speed issues.

To be precised the problem arises with a substructure search not with an exact search





Yes, there may be a structure causing probem to JCHEM while searching ... but how to determine which structure among 10000 ?





These structures have been all registered with JCHEM 2.1

Thanks for the structure (buckminsterfullerene). Smiles:

Code:

c12c3c4c5c1c6c7c8c2c9c%10c3c%11c%12c4c%13c%14c5c%15c6c%16c7c%17c%18c8c9c%19c%20c%10c%11c%21c%22c%12c%13c%23c%24c%14c%15c%25c%16c%26c%17c%27c%18c%19c%28c%20c%21c%29c%22c%23c%30c%24c%25c%26c%31c%27c%28c%29c%30%31

Using the current prerelease version this substructure search takes 20


seconds on a 1.7GHz notebook. So I suggest to upgrade when we release


the next version. We will give you as much support as needed to make


the transition smooth.


Best regards,


Ferenc