local_smart does not allow for conditions with an OR in the species field about kmos HOT 3 OPEN

Hi, yeah

I am actually not sure it is so useful. It sure is sweet syntactic sugar but I think reintroducing it back into local_smart is quite intricate because local_smart is quite intricate. I think in many cases it would be easier to generate two processes for each case or use a Bystander in combination with your OTF backend. I think that is a more general approach and quite powerful, too! Right now I see more use-cases if we really iron-out your OTF backend and generate conditions like the one you mention on they way. Do you have a different viewpoint on this?

Best,
Max.

from kmos.

I do think is more interesting to go on an improve otf. However, there are models in which local_smart is faster than either local_smart or otf (at least in it's current state). I suspect that allowing checks of several possible species right in case(spec1,spec2,...) in the search tree will be faster than configuring (potentally very many) extra processes...
I also expected it not to be so difficult to put in. But maybe the risk of breaking something outweighs this relatively small advantage...

from kmos.

Ok, for you concern of breaking the backend I should put in some runtime tests for model using the existing syntax without OR. Give me a couple of days.

from kmos.