smash-transport / smash-analysis Goto Github PK

As can be seen on the website with the plots, for example for protons for 7.7 GeV in the mT-spectra, no experimenal data is plotted although experimental data is available. This is related to a wrong parsing of the file names of files which were created from STAR data.

Reading the old results for detailed balance currently requires reading unicode strings in 'txt_io.py':

if 'detailed_balance' in path:
    # Unicode strings in first column. Data type needs to be specified.
    array = genfromtxt(f, missing_values='-', dtype='unicode', encoding='utf-8')

This is however only supported from numpy version 1.14.0 upwards, which is not preinstalled on Kronos and other machines. Hence, the build of the analysis suite fails as the installed version is too old and it needs to be updated manually. It would be nice to find a different representation for those unicode strings such that reading them in is also possible with an older version of numpy and users would not need to update their numpy version when attempting to run the analysis suite.

Would be good for users to have a list of possible targets, possibly via make help.

Calculate the density in different setups and check if it has changed.
Setups to considere:

• 2d density plot in the box
• Density in the central cell in AuAu collisions

Support for Python 2 is running out by the end of this year, so we should migrate to Python 3. @janusw worked on this before (see https://pm.fias.science/issues/1147), but there were serious performance regressions.

The afterburner target uses curl to download exernal input (https://github.com/smash-transport/smash-analysis/blob/main/test/afterburner/CMakeLists.txt line 19). Inside the latest rc container, this fails because the of the error:

bash: curl: command not found

outside the container, this works fine.

We merged the creation of the results with the stochastic rates early to change master (#22) . Now, only the plotting have to be extended to include them.

Most available data for LHC energies are pT spectra. For better comparison it would be good to also include a pT spectra tab to the energy scan target.

In principle the following issue should apply to all cases in which the user has a permanent SMASH installation with dedicated system wide environment variables, but it is much more likely that it is found when using Singularity containers, e.g. in the Virgo Cluster.

When running the analyses, the SMASH executable is found by the cmake find_program command, which first searches in the default system directories and then in the additional directories in SMASH_PATH.
See: https://cmake.org/cmake/help/latest/command/find_program.html
So, when using a container, the pre-compiled SMASH version shipped with the container will be find first and used.
This is a problem when somebody wants to test a different SMASH branch, not the default stable one.

The first solution, which has been tested by Anna and me, is:

• add the flag NO_DEFAULT_PATH in CMakeLists.txt when calling find_program : find_program(SMASH smash PATHS ${SMASH_PATH} NO_DEFAULT_PATH) and then, in the script run by SLURM, set and export the SMASH_PATH variable:

export SMASH_PATH=$smash_dir
cmake -DSMASH_PATH=$build_dir -DEXP_DATA=$EXP_DATA_DIR -B$output_dir -H$analysis_dir 

Another solution, that worked for me, but maybe not for Anna, is to prepend the path of the chosen non default SMASH installation to the PATH variable in the script run by SLURM, e.g.:

export PATH=$smash_dir:$PATH
cmake -DSMASH_PATH=$build_dir -DEXP_DATA=$EXP_DATA_DIR -B$output_dir -H$analysis_dir

without modifying CMakeLists.txt.

Exporting the updated PATH variable before starting the container does not work, because, as written in the Singularity documentation https://sylabs.io/guides/3.6/user-guide/environment_and_metadata.html, all environment variables are transmitted to the container, except PATH , PS1 (for the shell prompt) and LD_LIBRARY_PATH (for the location of the shared libraries), which are reset by the container. So, PATH must be set when already running the container. However, if needed, it is possible to override the default values by calling singularity with the --env option, but this solution looks more complicated than the others.

This issue applies also to the smash-analyis-extra repository, but I don't see the need to open a duplicated issue there. Once we have decided how to deal with this stuff, we can apply the same solution to the other repo.
@akschaefer @elfnerhannah @stdnmr

The function returning the version of the SMASH analysis uses git describeto determine the version. This command is however only valid if there are existing tags. The latter is the case if the repository is cloned, however not if the source files are downloaded as the download contains no history. Consequently, the analysis suite cannot be run if not cloned.

Since SMASH-2.0 allows regular running at LHC energies, it would be good to enhance the data points for our energy scan target as much as possible.

During the review for PR #52 , we noticed that the scaling of the old results of pT-spectra is off in the energy scan target. These plots are not used for the report, but it should still be fixed. This is most likely a trivial fix.

Getting this error reading newest SMASH output:
Fatal error: unknown format version = 7

Hi!
While work with output-file (.root), generated with config option "Only_Final: No", it seems that it is impossible to distinguish final particles and not-final in this case. This situation could be fixed if there was some flag in output files that can separate final and intermedium particles, something like "Is Final". Is it possible to add this feature in the future SMASH release?

The reason is they are indistinguishable, so they contribute to the same SMASH spectra.

... therefore the old results extraction script has to be slightly changed. Old filename was just scatrate_vs_SETUP.txt. New filename is scatrate_vs_SETUP-geometric.txt (or stochastic).

Refs #1

The annihilation cross-section should be also checked regularly against experimental data.

The center panel of the detailed balance plots looks a bit messy and wobbles around a lot. They should be cleaned up by - for example - reducing the number of bins to make it smoother.

Currently not all rho and omega origin for rho/omega dilepton decays are recognised by the analysis due to the addtition of the mesonic resonances and some heavy baryonic resoances. At least the baryonic resonances should be added and the mesonic resonances should at least be counted as a single contribution. Right now, all of them fall into the other category not allowing any distinction.

Starting from the report of SMASH-1.6, the angular distribution plots do not include the first bin, whereas for the old results, the first bin is plotted. This bug can be seen for example here.

Currently the default plotting produces weird/bad things, such as

(y-axis limits could be smaller on the latter)

I noticed this for the cross section targets, but we should check everything, so probably this has to be fixed in a case-by-case way. Also some plots would benefit from a log-scale either in x or y, or change the x variable from $\sqrt{s}$ to $p_\mathrm{lab}$ .

When running generate_html.py on a folder with plots, I get the following error:

Traceback (most recent call last):
  File "/home/steinberg/src/smash-analysis-new/test/report/generate_html.py", line 660, in <module>
    tree = reorder_tree(tree, source_dir.split('/')[-2])
IndexError: list index out of range

Apparently, the code makes some assumptions about the folder structure. However, they seem to be undocumented, so I don't know how invoke the script correctly.

Ideally, I think the code should be more robust and not make those assumptions.

I have tried using the energy scan for non-default targets (π⁻C and π⁻W), by commenting out the other run_one_energy commands in test/energy_scan/CMakeLists.txt. The runs and analysis work fine, but currently the plotter requires that:

1. There is a target for pp at sqrt(s) = 2.695 GeV [lines 132/147 in the CMakeLists.txt]
2. Any AuAu/PbPb target is present (doesn't matter which, but I did not find out why yet)

Also, when these conditions are met, the plotter works but doesn't use different colors for each new target, which is undesirable. For instance (nevermind the few targets and small statistics):

Furthermore, it would be interesting to make plotting targets for each individual system, rather than one make energy_scan_plots which demands runs for all present targets.

The FOPI target fails during plotting:

[100%] Built target FOPI_pions_sims
Analyzing data for FOPI_pions.
Plotting data for FOPI_pions.
3.0
Traceback (most recent call last):
  File "/lustre/hyihp/ngoetz/smash-analysis/test/FOPI_pions/plot.py", line 42, in <module>
    smash_data = np.loadtxt(data_file, unpack=True)
  File "/usr/lib/python3/dist-packages/numpy/lib/npyio.py", line 1148, in loadtxt
    for x in read_data(_loadtxt_chunksize):
  File "/usr/lib/python3/dist-packages/numpy/lib/npyio.py", line 995, in read_data
    raise ValueError("Wrong number of columns at line %d"
ValueError: Wrong number of columns at line 3
make[3]: *** [test/FOPI_pions/CMakeFiles/FOPI_pions_plots.dir/build.make:74: test/FOPI_pions/FOPI_pions.pdf] Error 1
make[2]: *** [CMakeFiles/Makefile2:4919: test/FOPI_pions/CMakeFiles/FOPI_pions_plots.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:4926: test/FOPI_pions/CMakeFiles/FOPI_pions_plots.dir/rule] Error 2
make: *** [Makefile:2217: FOPI_pions_plots] Error 2

I assume that it could be related to the binary reader, though I am not sure. I assign this to @Hendrik1704 for now, but if you find that it is not related, you can also assign someone else.

Hey guys,
I got the following error running "Detailed balance KN_KDelta sims"

I remember implementing this exception to prevent SMASH from running into an infinite loop. Has anybody encountered some problems with this particular run before?

The plot for the reconstruction of the p+p+eta cross section is broken. See for example here.

It cannot simply be solved by removing the eta from the list of unstable particles. In this case some assertion that the cross section is greater than 0 fails.

@stdnmr @vks

With the upcoming option to run smash completely silent, it is not necessary to redirect the output anymore. This will also be helpful for debugging the targets that use the redirection

/cc @akschaefer

With increased performance of SMASH at high energies, the energy scan target can now also be run efficiently at higher energies. Therefore, we want to include energies up to 5.02 TeV.

I think it would be useful to include two smooth hypersurface files for 200 GeV AuAu at RHIC and 5.02 TeV PbPb at LHC to run a SMASH afterburner to ensure that nothing changes there. This is a use case of many external groups, therefore I think it would be beneficial to keep track of changes.
@akschaefer and @thegarzo might have comments.

In multiple plotting scripts of the analysis suite, nonposy keyword is used. This is not supported anymore in the latest versions of this library and should be updated. It has been replaced by nonpositve, which apparently does the same.

While building smash-analysis I get an error from cmake. It seems to origin from FloatMath.

This is the error:

CMake Error at test/FOPI_pions/CMakeLists.txt:46 (run_one_energy):
  run_one_energy Function invoked with incorrect arguments for function
  named: run_one_energy

My system:

-Apple M1 Chip
-cmake version: 3.22.0

I used modified detailed balance targets a lot for debugging of the multi-particle reactions and it is straight-forward and probably helpful to add them.

PR #22 is already a start, although I think I will replace it with one large PR including all the new targets.

I ran into minor things running the analysis suite on the goethe cluster for the first time:

The required module named yaml is the python module pyyaml, I think.

Further, one could add the required version to the error message when the module is not found at all. It's helpful to know which one to install.

I could quickly take care of that if you agree @akschaefer.