These should probably become expression columns in the next step if they are accessed more than once

consider Non-static member initialization instead

We will build a dictionary for this class in the next step and expose the data members as configurable

Please don't add trailing white spaces ;-)

I would prefer to keep the modification of the FastJet-related cmake stuff to a separate PR (#4514), mostly to keep track of what's going on and potentially react in case of issues.

Sorry yes i forgot to make it separate. Would you like to push it and then I can remove it from this pull request

this is now removed, so if you could add it to your pull request that would be great

I am not convinced this should be in the header. Instead, I'd prefer to have the implementation in a separate cxx file, which then is build and also pulls in the required libs (FastJet + contrib), which now needs to happen in every task including JetFinder.h (even if nothing of contrib is used by that task).

Do we want/need to support jet finding without FJcontrib?

yes I also agree, i left it all in the header now as we decided to do a bit of reshuffling in the next stage but we can move everything to an appropriate .cxx
I think we can potentially support the jet finding without contrib for the cases were certain subtractions are not used if it makes a difference to compile time. although i guess this should be minimal

The question is more if an installation of FastJet without contrib should be supported?

Ah I see. In my opinion there isnt much need for this as anyone who decides to build with fastjet wont mind and perhaps in most cases will even require the contrib packages. We just might need some flexibility with managing different versions of fastjet and the contrib but i guess this should be ok to do

What is this needed for? Shouldn't this just be once-off initialization?

What's the reason to do this for every call of the actual jet finding? Isn't it sufficient to have the settings initialized once?

the reason for the param initialisation is that thee user may wish to change certain variables after initialising an instance of the class (for example etaMax for run5 studies). If the params are not initialised again then the corresponding selectors and other variables like the jet radius which depend on such parameters would not be updated. I have added eta and phi options directly in the constructor but this holds for example for any of the other variables going into the selectors. That was the logic but perhaps there is a more elegant way to achieve this

I can see that you would want to change the parameters after initialising the class, but not between running the jet finding. In case you want jet finding with different settings in the same event, wouldn't it be more logical to setup two instances of the jet finding class? Maybe I am missing something here?

well there can be cases of jet correlations with a trigger object where the phi might want to be changed each time in accordance with the recoil window from the trigger. This can of course also be done after the jet finding too but can also be done via the selector options.