thanks for the questions! Looking at the code with more attention, to try to answer to your questions, I have realized why the solution I have suggested in my first post does not work, and hopefully I have found another solution.
The reason why my first solution does not work is because, when Radioactive Decay is used (as in QGSP_BIC_HP physics list), then the time threshold in G4NuclideTable - 1000.0ns - overwrites the time threshold in G4DeexPrecoParameters. In other words, whatever value we try to set in G4DeexPrecoParameters - e.g. 1.0ns - it is the value in G4NuclideTable which is used!
Regarding the new solution I would like to propose, this consists of setting 1.0*ns the time threshold in G4NuclideTable, which can be done via the following UI command (it should work both before initialization, but also after, i.e. before /run/beamOn):
/particle/nuclideTable/min_halflife 1.0 ns
Regarding your questions, the two time thresholds are independent, when Radioactive Decay is not used.
The time threshold in G4NuclideTable is used to create the set of isomers that can be used in a Geant4 application. As I said, the default is 1000 ns, and can be changed via UI command both before and after initialization.
The time threshold in G4DeexPrecoParameters, instead, is related to the isomers that can be created by the nuclear de-excitation. Note that the intranuclear cascade models of Geant4 - BERT, BIC, INCL - cannot create isomers. Only the de-excitation part - which can be invoked by BIC and INCL (but not by BERT, unless the variant BERP is considered) - can create isomers. The default value of this time threshold in G4DeexPrecoParameters has changed with the Geant4 version: in G4 10.4 (and any patch), 10.5 (and any patch), 10.6 and 10.6.p01 it was set to 1000 seconds; in G4 10.6.p02, 10.6.p03, 10.7 and 10.7.p01 it was set to 1000 ns; then, since 10.7.p02 (including therefore 10.7.p03, 11.0 and 11.0.p01) it is 1 ns. The reason why the time threshold in G4DeexPrecoParameters has been introduced (in G4 10.4), and its original high default value (1000 s), was simply to save CPU time for cases, like HEP, in which isomers are not important. In fact, only isomers with a mean lifetime above this threshold are created by de-excitation. Then, some unphysical results reported by NA61/SHINE, which uses FTFP_BERT physics list (so, without Radioactive Decay), has led us to decrease this time threshold, first to 1000 ns, then 1 ns. Note that this threshold can be changed only via C++ interface, and only before initialization. What happens when this time threshold is smaller than the time threshold of G4NuclideTable? It happens that the candidate isomer is not found in the list of existing isomers, and therefore the de-excitation considers the corresponding ground state (and, to conserve energy, it includes in the kinetic energy the excitation energy of the would-be isomer state).
What happens instead when the candidate isomer has an average lifetime which is above the threshold in G4NuclideTable, but below the time threshold in G4DeexPrecoParameters (as it happened when the latter was set to 1000 seconds)? In this case the isomer is not created (in the sense that it does not become a G4Track object, and therefore it is not transported by Geant4), but its decay is forced, producing secondaries at the same spatial position where the candidate isomer has been created, but with a time which is sampled from the exponential distribution. The unphysical results that NA61/SHINE reported was due to the fact that this decay happens in-the-flight, i.e. with a relatively high Lorentz boost, whereas in reality the isomer would loose energy by ionization very quickly, and would decay at rest, so its decay products would not receive any Lorentz boost…