Repository navigation
Move FMS_RemoveDead to SelectionModule? #71
Description
After thinking a bit about the issues encountered in #66 I think it might be a good idea to move the FMS_RemoveDead into the Selection Module, as its main driver is called directly before. Also note that FMS_RemoveDead uses functionality that is already implemented in the Selection module, strengthening the argument for moving it there. @danielhollas WDYT?
Activity
danielhollas commentedon Jul 9, 2026
I think the main problem here is that currently it would create a cyclical dependency between SelectionModule and SpawnModule.
Also, RemoveDead is also called even when stochastic selection is not active so not sure it philosophically belongs there.
That said, if there are pieces of the code which we could extract into smaller functions, that could then be moved to one of those modules I think that would help.
danielhollas commentedon Jul 20, 2026
@yoricklassmann thanks for opening #73, it is useful to see what it would take. I am still not convinced we should move it to SelectionModule, for the reasons stated above. Some of the cleanup you did (e.g. reusing the
FMS_ConvergeCoupledcan be done without moving the code).In any case, and more importantly, before touching the code in remove_dead.F90, I think we need a lot more tests for it (either end-to-end or unit tests). For example, when I tried to comment out the construction of the
Coupledmatrix, none of the tests failed.yoricklassmann commentedon Jul 20, 2026
Yes that's a very good point, let's do that first. I think the easiest way would be to set ignore state to the ground state and make the deadtime as small as possible.