Aliases trigger regeneration of MEs

[dwiesler]

Having aliases in the initial or final state triggers a new generation of the corresponding ME with O'Mega each time Whizard is called, wether it was built before or not.

This is especially annoying, when e.g. the analysis setup is changed for many finalstate particles in the MSSM, where the build process usually takes quit long.

The attached sindarin file demonstrates this with two simple examples.

I circumvented this by using the '--recompile' option, but this is clearly not the intended way...

[dwiesler]

samples illustrating the described behaviour

[Juergen Reuter]

This is indeed a MD5 sum mismatch. Now I have to find out triggered by what exactly?

[Juergen Reuter]

OK, this is a design error: When WHIZARD generates the code it calculates the MD5 sum from the alias expressions given in the SINDARIN file. Afterwards it compares it with the md5sum from the file, but then computes the MD5 sum from the flavor table in the process file. But here, forbidden and redundant configurations have been eliminated. So there cannot be a match!!!

[Juergen Reuter]

Well: there are two solutions I can come up with. 1st: read the string of particles from the comment line at the beginning of the code file. This has not been done for the MD5 sum either, so I guess it is not a good solution. 2nd: write a routine which contains the string of the particles analogous to the function md5sum (). Wolfgang, as the designer of the MD5 sums you have to decide how to do this.

[kilian]

It actually was a sort-of bug. When reading a precompiled library, the MD5 sum stored in the file should just be used, instead of recomputing it from the particle data stored in the code. As JR correctly pointed out, O'Mega can reshuffle the latter, but this should NOT be the target of the MD5 check.

Fixed (hopefully) in r2174.

[Juergen Reuter]

Milestone v2.0-rc4 deleted