Users should have the option to only preserve/generate the minimum amount of intermediate files. By default we keep a lot of files, in order to keep track of the process, but an experienced user should be able to use a more lustre friendly execution mode.

To keep the test log file "clean" we got the habit to suppress standard error of function calls which are expected to fail.

However, by now, I found myself many times uncommenting the suppression to see what that output was and, reviewing PR, I realised that some problems which were not noticed could have been if that output was not suppressed.

It might be cool and convenient to get rid of all these failures. Clearly, this would then clutter the log file so much, that a test failure would not be visible any more. One could do the following then:

• Use a different logger level (like Print_Attention) to print tests failures, while waiting that the BashLogger developer (😅) adds a way to customise the logger with new levels.
• Since going through all tests is already painful, this should be done only once and I'd delegate the standard pattern

  if [ $? -ne 0 ]]; then
      Print_Error '...'
      return 1
  fi

  to a function, which would then use a different level. Sometimes we test for unexpected success and this new function should have an interface like Expect_Success $? 'message to be printed' 'even split' 'over lines' with possible siblings Expect_Failure with the same interface and Expect_Given_Failure which also take the expected exit code. These functions in tests should be called with a trailing || return 1 to fail the test.

Another nice improvement would be to make the runner call the Clean_Tests_Environment_For_Following_Test__* only if the test passed. At the moment we kind of do not implement these functions so much because we want files in case of failure, but then we leave them also for those tests which pass. Another alternative approach would be to make the runner remove the test dedicated folder if the test pass (of course, unless the user gave -k). This makes again the Clean* functions rarely needed, which is actually good IMO as it is less work for the developer. I'd go this way.

After smash-transport/new-hybrid-era#106 has been merged, this issue can be tackled.

At the moment only a list of values can be specified, but different handier ways should be offered.

• Add a way to specify parameter range and number of points (maybe with a bool to include or exclude range boundaries)
• Add a way to specify parameter range and a delta (I guess the left point is the first point in this case)
• Complete documentation with examples
• Add functional tests to run the handler in the prepare-scan mode

This is to provide a set of parameters suitable for collisions at all energies which are not specifically hard-coded.

It might become necessary for the user to add a command line option for some software. For now, this is not possible because we have fixed the way the handler runs the various software. An option to offer to the user more freedom would be to accept in the config of the handler a new key per software whose value are command line options to be forwarded by the handler to the software when running it.

All python scripts should be updated to python3 in the near future.

I leave this issue as open possibility. If in the future we want to have autocompletion on the command line (e.g. press TAB twice to get all valid options displayed) as kind of help and implicit documentation for the user, we might implement it. This implies that the user has to sort a file e.g. in their ~/.bashrc file.

Hydro crashes at LHC energies since the number of particles is Hardcoded to be NP=10000 in the vhlle icPartSmash.h source file. The solution is to increase it. However, since some people may not need this, and this increases the memory need, I suggest including a warning. Or maybe including a note in the README

The current version of the smash-vHLLE-hybrid is meant to be directly run on a cluster to get appropriate statistics. It might however be useful to include a test setup for trial purposes and to see if all installations were successful. A setup that could even be run on a desktop computer.

SMASH as IC stage allows to use custom nucleus data which are loaded from a file. To do so, the IC config needs to include the keys File_Directory and File_Name which looks then like this:

Modi:
    Collider:
        Projectile:
            Particles: {2212: 44, 2112: 52}  # Ru
            Custom:
                File_Directory: "/path/to/nucleus_file/directory
                File_Name: "nucleus_filename.dat"
        Target:
            Particles: {2212: 44, 2112: 52}
            Custom:
                File_Directory: "/path/to/nucleus_file/directory"
                File_Name: "nucleus_filename.dat"

        Fermi_Motion: frozen
        Impact:
            Value: 5.8

However, the hybrid handler does not allow to add new keys. In order to run with custom nucleus files the hybrid handler should have an option to add these keys, such that one single IC base config file is enough to have.

At some point it will be time to take a decision about this aspect. It might be worth implementing an internal setup mechanism for the handler to let the user run a setup and provide information that is stored somewhere. For example, I can imagine that the handler on a super computer will always be used with the same executable and one might not be willing always have this information in the configuration file. On the other hand, if such an information is not that much, the effort of having a new execution mode and a somewhat complex mechanism (the setup should be re-runnable at any time to change stuff) might be avoided.

To track future changes, a CHANGELOG is required. Ideally, it follows the established style used by other SMASH projects.

We should decide on how we run the software and overwrite already existing results. E.g. in smash one can run the code with the option -f to force overwriting. In vhlle or in the sampler I don't know how this is done.
In the current cmake structure if the output already exists, one cannot re-run code to the same output directory.
A solution could be to add an option to the HybridHandler that allows for overwriting but for now I suggest to exit the handler if the output already exists.

PbPb at 2760.0 GeV and 5020.0 GeV are to be included as targets. The parameter files have to be tuned and the performance of the different modules at these energies have to be tested.

Future versions should have the ability to run the initial condition many times, in order to select a range from x% to y% of the most energy rich initial conditions as an approximation of centrality classes. The rest of the workflow would only be initialized with the chosen initial conditions.

I get following error during execution of the test target:

File "/lustre/hyihp/ngoetz/smash-vhlle-hybrid/python_scripts/create_vhlle_config.py", line 37, in <module>
  File "/lustre/hyihp/ngoetz/smash-vhlle-hybrid/python_scripts/create_vhlle_config.py", line 37, in <module>
Traceback (most recent call last):
  File "/lustre/hyihp/ngoetz/smash-vhlle-hybrid/python_scripts/create_vhlle_config.py", line 37, in <module>
Traceback (most recent call last):
  File "/lustre/hyihp/ngoetz/smash-vhlle-hybrid/python_scripts/create_vhlle_config.py", line 37, in <module>
    if float(args.energy) >= float(key): energy = key
    if float(args.energy) >= float(key): energy = key
TypeError: float() argument must be a string or a real number, not 'NoneType'
TypeError: float() argument must be a string or a real number, not 'NoneType'
    if float(args.energy) >= float(key): energy = key
TypeError: float() argument must be a string or a real number, not 'NoneType'
    if float(args.energy) >= float(key): energy = key
TypeError: float() argument must be a string or a real number, not 'NoneType'
make[3]: *** [CMakeFiles/test_hydro.dir/build.make:107: Hybrid_Results/test/3/Hydro/vhlle_config] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [CMakeFiles/test_hydro.dir/build.make:112: Hybrid_Results/test/4/Hydro/vhlle_config] Error 1
make[3]: *** [CMakeFiles/test_hydro.dir/build.make:102: Hybrid_Results/test/2/Hydro/vhlle_config] Error 1
make[3]: *** [CMakeFiles/test_hydro.dir/build.make:97: Hybrid_Results/test/1/Hydro/vhlle_config] Error 1
make[2]: *** [CMakeFiles/Makefile2:5135: CMakeFiles/test_hydro.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:5142: CMakeFiles/test_hydro.dir/rule] Error 2
make: *** [Makefile:2464: test_hydro] Error 2

It would be convenient to add another target that allows running the hybrid from an arbitrary SMASH config file, independent of the already existent collision systems and energies.

/cc @NGoetz @elfnerhannah @JanHammelmann