BFC options: picoWrite option adds the trigger simulator maker to the chain

[klendathu2k]

The picoWrite option adds the trgSimu option to the big full chain. Our data output formats should write the data that is produced, not drive the choice of which datasets are being produced. (e.g. the MuDst maker should not / does not require that track reconstruction is performed... but only outputs tracks if they were created).

1. Trigger simulator should be moved from its current 'utilities' director to a proper maker directory
2. Trigger simulator should output its data to StEvent and MuDst
3. Pico DST should be picking up the trigger results from StEvent/StMuDst

[genevb]

Hi. I believe @zlchang maintains StTriggerUtilities, so he should be included in the discussion of concerns.

[jdbrice]

just adding my two cents: this is also very annoying for the fwd development, because I cannot use the picowrite chain option (unless I manually add all the dependencies for the trigsimu, e.g. eemcDb...), instead I have to make a .C script and add the PicoDst manually. It runs fine in write mode without the trigsimu - so in my opinion we should just change the BFC option to remove the trigsimu

[zlchang]

Hi guys, a few years ago picoDst files were needed to save the information from the trigger simulator so the trigger simulator was added to the picoWrite chain. I'm responsible to maintain the trigger simulator code, but I'm not sure how to remove the trigger simulator from the production chain. I guess you could also create a new chain label that doesn't call the trigger simulator.