Seeding problem for mpi division in time

[mj-gomes]

I was running a simulation with the non linearity module, using 4 detectors and 10 MPI tasks, dividing the simulation in time blocks (not in detector blocks). So all of the MPI tasks work on the 4 detectors, but on a different bunch of time for each of them.

Doing this, I realized that the g_one_over_k value sampled for each detector was different in each MPI task, while it should remain the same (there should be a single value of g for a given detector).

It seems like the seeding process implemented last year assumes that we divide the observation into parallel detector blocks and for now does not work in the case were the division is done in time.

I will look into this, meanwhile if someone has a quick fix, feel free to step in.

[mj-gomes]

Okay, I think this is actually a bigger issue than I thought and may require refurbishing again the way we deal with seeding of systematics, since the whole method we currently have is based on generating a tree in which the first layer sets a different random number generator per MPI task which already means that it will not work for the case I mentioned (or for a case where we divide both in detectors and in time, basically every time multiple MPI tasks share the same detector).

We should probably set a RNG per detector, instead of per MPI task, and then each MPI task will use the RNG corresponding to each of detectors it is working on.

But I did not work on the seeding module, so please tell me if this has an obvious solution or if there is already a way of doing it @ggalloni @anand-avinash @ziotom78 @paganol .

Cheers,
Miguel

[anand-avinash]

Hi @mj-gomes! I think the only practical scenario where you would need the same random generator for a given detector on all MPI processes is when you need to generate just one random number per detector. If that is indeed the case, wouldn't it be more appropriate to change the function signature in the non-linearity module to simply accept a detector-specific seed to generate the random number?

Minor comments: seems like det_name argument here is not needed anymore, and the docstring here is bit outdated.

[mj-gomes]

Hi @anand-avinash, I am in fact facing the case in which I need a detector-specific seed, as the g factor from the detector non linearity is detector specific and should not change for a given detector. Your suggestion works, of course, and if in all other cases we don't care about having a detector-specific seed, than I agree that that is the way to go, and we should only change the non linearity module. But I was assuming, perhaps naively, that other cases exist in which we want detector-specific seeds.