MolSearchOptions

What is the relationship between methods like setExactFragment, setSubgraphSearch, setSuperstructureSearch etc on the one hand and setSearchType on the other: doesn't, e.g., setSearchType(SUPERSTRUCTURE) render setSuperstructureSearch unnecessary?





Generally speaking, assuming a JChemSearch search engine was set up in xyz fashion, how should a MolSearchOptions object be set up so that if it is passed to HitDisplayTool the latter will flag the same subgraph that JChemSearch had recognized and not something else? I see that JChemSearch has a handy getSearchOptions method but unfortunately it returns a JChemSearchOptions, which extends SearchOptions directly, not MolSearchOptions. Will it be enough to do:

Code:

JChemSearch jcs = ...;    MolSearchOptions mso = new MolSearchOptions();    mso.clonecopy(jcs.getSearchOptions());    // use mso

Or should I use JChemSearch.getHitsAsMolecules instead, to obviate these difficulties?





Thanks

Quote:

What is the relationship between methods like setExactFragment, setSubgraphSearch, setSuperstructureSearch etc on the one hand and setSearchType on the other: doesn't, e.g., setSearchType(SUPERSTRUCTURE) render setSuperstructureSearch unnecessary?

Think of the main search methods as a pre-set combination of more fine-grained options.


Please see the table displaying their relations in the Query Guide:


http://www.chemaxon.com/jchem/doc/user/Query.html#otherSearchTypes


So it's enough to set the search type (unless you want to "tweak" that search mode).





Yes, you can use clonecopy() in a similar fashion to create a MolSearchOptions object, the clonecopy() method works the other way than it's used in your code (see the API documentation).


Probably this is what you want instead:

Code:

jcs.getSearchOptions().clonecopy(mso);

Quote:

Or should I use JChemSearch.getHitsAsMolecules instead, to obviate these difficulties?

I suggest this as the most straightforward solution if the hits are the result of a database search.


Otherwise you have to take care to fetch the target, use the proper standardization (the same that is set for the table) and so on, all this hassle can be spared by using this method after the search.





Best regards,





Szilard

Thanks. I will try do as you suggest.

If I use getHitsAsMolecules, what will it do in the case of multiple matches in the same target molecule?

Quote:

If I use getHitsAsMolecules, what will it do in the case of multiple matches in the same target molecule?

It will display (color) the first hit it finds in the target.





(To be more precise if the alignment mode is ALIGNMENT_ROTATE, it tries a few hits and chooses the one that looks "nicer" when aligned.)





Best regards,





Szilard

If you have multiple matches, I don't think showing just the first one (and for a rather arbitrary definition of "first") is what users would want but I am no chemist. Would they?

Quote:

If you have multiple matches, I don't think showing just the first one (and for a rather arbitrary definition of "first") is what users would want but I am no chemist. Would they?

We have been supporting hit coloring and alignment for several years now, and there has been no request to color multiple hits in a target so far that I'm aware of. If it's important for some client(s) we may add an option for this in the future.





Szilard

OK. Maybe the query molecules for which you get multiple matches are so generic that in practice no chemist would formulate such a query and I am over-complicating things. But of course such simple query molecules are just the ones a programmer would be tempted to use in testing, esp. if he is no chemist himself ;-)





In short, you think it's an academic issue, correct?

Yes, I think you have summarized the situation correctly.


It could also be confusing if hits overlap or if alignment it also used (you can only align to one hit).





Best regards,





Szilard