Smash stuck in infinite loop in run_time_evolution_timestepless() function

[ponsang2024]

When I use smash as an afterburner process for hydrodynamic models, some events smash runs successfully and some eventssamsh gets stuck.And no errors were reported.

When I debugged the stuck event with GDB, I found that smash kept looping at smash:.Experimentsmash::listModus:run time evolution timestepless( ) and couldn't reach the condition to jump out of the loop.

I run the $O+O$ colisions system.The samsh version used is 3.0. The zip file contains the particle data mc_particle_list0 and config_0.yaml that makes samsh stuck.When I try to enter them to run smash, I get stuck at the first event.Do you know what is going on?
Thanks a lot for taking the time for the proroblem.

[AxelKrypton]

We'll definitely have a look into the problem. However, to do so, it would be very valuable to have the needed files to reproduce the problem. As you mentioned a zip file, I guess you wanted to attach some files, but I do not see them. 🤔 Could you please provide us with the following information?

• The configuration file
• The file with the list of particles if you run in the List modus (which I guess you do)
• Just to be sure: You use the default particles.txt and decaymodes.txt files, don't you?

[ponsang2024]

before.zip
Sorry, I forgot to attach the zip file.The input particle data file is in the form of a txt file.One more thing I'd like to fix I'm using smash 3.1.Thank you for your reply.

[AxelKrypton]

I just ran SMASH-3.1 with your input file on my laptop and the run went through. Here

In your configuration file you set the Randomseed key to -1 and this means that SMASH uses a random one. In my case it was 4570370138295758425 as you can see in the screenshot above.

It might well be that the problem does not always arise. While some of my colleagues has a look whether your configuration file is accurate from the physics perspective, I'd suggest the following:

1. Could you try to repeat the run with the same random seed as above, e.g. setting Randomseed: 4570370138295758425 in your configuration file, and see if your run finishes?
2. Could you, please, provide us with the random seed of the run in which SMASH got stuck at the first event? We can investigate the problem only if we can reproduce it. 🤞

[ponsang2024]

When I set the random seed : 4570370138295758425,samsh still gets stuck and reports no errors.

I set the random seed back to -1 and tried multiple times. But each time samsh didn't run successfully, e.g. random seeds: 8312112714334853019, 4999807955478612713, 8979790425147389199.
So, is it possible that it's because I made a mistake installing samsh? This is mycamkeconfiguration. My camke version is 3.16.3.

[AxelKrypton]

Thanks for sharing the CMake output. From it I can see that you run on a Linux machine and I now tried to run there. Even if I use GNU 13.2.0 compiler instead of 11.4.0 I can reproduce that, indeed, SMASH seems to get stuck with your setup. I will now coordinate with my colleagues and try to understand why. As soon as we understood what it is going on, I will report here.

[ponsang2024]

Thank you for taking the time to do this. I’m looking forward to your reply.😊😊

[AxelKrypton]

@ponsang2024 After some days of work I can happily announce you that (1) we understood the problem and (2) SMASH will behave in a way more user friendly way in the upcoming release SMASH-3.2 (early next year). 🚀 Here the main points:

• SMASH is getting stuck because in some events in your particles list file you have more than 2 particles with the same identical position. Because of how SMASH internally works, this is not guaranteed to work. In particular, roughly speaking, pairs of those particles might be selected to interact and after an interaction is performed new interactions might be selected and so on. As time "is not elapsing" then the number of interactions simply increases and SMASH gets stuck.
• If only two particles are at the same 4-positions is not a problem because once they interacted it is prohibited for them to interact again (otherwise the same problem might occur as well).
• All in all, it is basically a numerical problem rather than a physical one (a small difference e.g. on the last decimal digit in one component of the spatial position already cures the problem). However, we decided that SMASH cannot really take action about this, because we do not (and cannot) know what the user would like to do. The only thing we can do on our side is to validate user input in a more user-friendly way. From SMASH-3.2 on, running SMASH with your input file will produce an error like in the following screenshot (that's preliminary and might change) and the documentation of the list modus has been improved to explain this potential issue.

In your case, you should understand why do those particle have the same identical position and what could be an acceptable way of cure the problem. Maybe randomly shifting them by a very small amount is acceptable, maybe you prefer a different approach. In any case you should now know what to do.

I will leave this issue open for a while. Feel free to ask us more if you need it or to close the issue yourself if you are happy with our explanation. 😊

[ponsang2024]

Thank you for your work, it is very helpful.Originally, I was modifying the code in SMASH so that when the number of interactions in therun_time_evolution_timestepless() function becomes too high, the evolution of the current event is exited.

• As you mentioned, simply altering the last decimal digit in one component of the spatial position can resolve the issue.However, not all inputs with more than two particles having the same 4-position will cause SMASH to get stuck. In the previous , only would cause SMASH to get stuck. In my attempts, if I manually modify the 4-position values of some particles to create events with more than two particles having the same 4-position, some can run through, while others will get stuck.mc_particle_list0``event0
• I will try to understand why these particles end up with the same position and what might be an acceptable solution to the problem.

Thank you again for your help. Regards.😊😊

[AxelKrypton]

However, not all inputs with more than two particles having the same 4-position will cause SMASH to get stuck.

Yes, that's correct and we are aware of that. That's why I wrote "is not guaranteed to work". Basically, it depends on the other particles present in the event and it can happen that another particle first interacts with one of the 3 at the same position e.g. inelastically and than only 2 particles at the same position remain, which is not a problem. However, since this cannot be foreseen in advance, we preferred to let SMASH simply report and exit in the future versions.

If in the future more users wish to have SMASH handle this in some way, we might consider implement some optional behaviour, but at the moment it is not in our plans.

I also forgot to mention that the the Version key is deprecated and will be removed in the upcoming SMASH-3.2 version. You can simply remove it in your input file when using recent versions, as it is plainly ignored. You also might want to checkout the Filename key of the list modus, which is handy if all your events are in a single file. Using it allows you to call your file as you wish without the need of having the trailing 0.

[ponsang2024]

Thank you for your patient explanation, it was helpful to me.