NDLAr Specific Additions (Included in latest MicroProd)

[alexbooth92]

A couple of commits that featured in the latest NDLAr MicroProds introducing two things. Want to bring these into develop.

• We only want to create a trigger packet when we have a new event, not necessary a new batch. Logic introduced applies when not running in mod2mod_variation mode. The reason being you don't want to set your "trigger module" to minus 1. See logic at line 860 of simulate_pixels.
• A temporary solution to run in "light trigger mode" without the need to simulate the light (which we haven't tried for NDLAr).

[mjkramer]

LGTM, but if I understand correctly, you've uncovered a bug that also affects the mod2mod_variation (i.e. 2x2) case. Namely, if we sub-batch a batch that belongs to the trig_module, then we'll write out multiple copies of the light triggers. Would a more general fix be as simple as doing the following?

if is_new_event and (light.LIGHT_TRIG_MODE == 0 or light.LIGHT_TRIG_MODE == 1) and (i_mod == trig_module or i_mod == -1)

[YifanC]

Hi @alexbooth92 @mjkramer,
Yes, I think Alex caught a bug that we could introduce multiple triggers in the batching. I added a version of correction in the MR6 production version, see here. Please let me know if I missed anything.
I also thought Kazu would start to play with nd label making so I also added the light trigger mode in the ndlar config and it's currently in develop.
Hope it's not causing terrible confusions.

[alexbooth92]

Thanks for the explanation @YifanC - I must say that I was a little confused when I was sorting out the merge conflicts. I haven't tested your fix but from a brief look I think it does the trick. I have remove any trace of my version of the fix and the "duplicate" LIGHT_TRIGGER_MODE line in the ndlar config. The other stuff related to light trigger mode needs to stay otherwise you can't run with the light sim "turned off".

[alexbooth92]

If I have understood all of the above correctly, @mjkramer / @YifanC please merge this if things look OK. I can merge after 24 hours otherwise if no further comments.

[YifanC]

@alexbooth92 The current develop support light_simulated=False if you set the light_trigger_mode, which I think you would need for the trigger packet from the larpix simulation. Could you check again?
The two remaining changes:

1. Disable light triggers from the simulated light data when the light simulation is off. I think either way is fine. Happy to have it merged though.
2. The addition after "except keyerror", it seems to be a copy of these two lines. Would it make more sense to set LIGHT_TRIG_MODE = 1 directly if it gets there? Otherwise I think it will makes no difference?

[alexbooth92]

@alexbooth92 The current develop support light_simulated=False if you set the light_trigger_mode, which I think you would need for the trigger packet from the larpix simulation. Could you check again? The two remaining changes:

1. Disable light triggers from the simulated light data when the light simulation is off. I think either way is fine. Happy to have it merged though.
2. The addition after "except keyerror", it seems to be a copy of these two lines. Would it make more sense to set LIGHT_TRIG_MODE = 1 directly if it gets there? Otherwise I think it will makes no difference?

Thank you for looking! You absolutely need the except key error as I have it to be able to run with light_simulated=False because if not you have to provide all of the light inputs anyway in the config that you pass to simulate_pixels which doesn't make any sense if you are just running a charge simulation. Sorry I should have made that clearer.

So yes, in develop it might support light_simulated=False but you have to provide all the light configs and waste time loading it all. With this set up you don't have to :)