Looks good, not a blocker but sometimes when you need to pass many variables around it can be useful to encapsulate them in a private inner class (e.g. ALogPDescriptor.State).

I still maintain the correct way to parallelise descriptors is you just have copies of the descriptors for each thread :-). What does your parallelisation look like - it might be good idea to integrate a parallel mode into the descriptor engine class.

Looks good, not a blocker but sometimes when you need to pass many variables around it can be useful to encapsulate them in a private inner class (e.g. ALogPDescriptor.State).

Thanks for the tip, should have thought about it, sorry.

I still maintain the correct way to parallelise descriptors is you just have copies of the descriptors for each thread :-).

We did that and it is the fastest way, so far, as it seems (if you are not under any memory constraints). Now, we would like to check whether we can still gain some speed when the descriptor instances are shared between the threads.

What does your parallelisation look like - it might be good idea to integrate a parallel mode into the descriptor engine class.

Our two parallelisation strategies are 1) Distribute the molecules onto threads (one per mol) and have them access shared descriptor classes and 2) Distribute the descriptors onto threads (one per desc) and have them access the shared molecules (hence my recent "fix" of the LargestPiSystemDescriptor that changed flags in the mol but did not make a copy first like others).

We are basically working on a "parallelised descriptor engine" that we would also present to you for CDK integration when it's complete. If you want to already have a look (we are still actively working on it):
https://github.com/JonasSchaub/CDK-Descriptor-Calculation/blob/dev-manuel/src/main/java/de/unijena/cheminf/clustering/desccalc/Descriptor.java

Parallelisation method 1) is not really there yet because these three descriptors are not ready for it yet. Instead, we experimented with synchronizing the shared descriptor instance and creating a new instance each time (like you suggested).

The main point of our library is to generate a large float matrix of descriptor values for a given set of molecules that can, e.g., be used for clustering.

Our two parallelisation strategies are 1) Distribute the molecules onto threads (one per mol) and have them access shared descriptor classes and 2) Distribute the descriptors onto threads (one per desc) and have them access the shared molecules (hence my recent "fix" of the LargestPiSystemDescriptor that changed flags in the mol but did not make a copy first like others).

OK the best strategy as actually to chunk your input and give those to each thread. Depends on timings but something like 4096 molecules per chunk - keep them in the input format (e.g. SMILES) as long as possible. You want to minimise the synchronisation points as much as possible - this is particularly important on higher core counts.