When SPheno reads a matrix, it expect to always have a comment (or something) at the end of the line. That is, it expects:
and the following will fails:
This is because when it reads the matrix, it has
and if there is no comment, read_line globs in the next index.

Yes. These are the SLHA conventions. So, it's not a bug.

Cheers
Florian

Hmm, that's not quite how I read it. In particular, the passage (from arXiv:hep-ph/0311123) reads:

Comments and/or descriptions added after the data values, e.g. “ ... # comment”, should always be added, to increase readability of the file for human readers

It uses "should" which (according to RFC2119) means that this is to be expected in most cases but is not a strict requirement. In particular, if it were a strict requirement, they would have used "must". The additional statement that this is "to increase readability of the file for human readers" also implies to me that a comment should not actually be expected every single time. For example, if a block has a single parameter and the block title is self-explanatory, the comment could be seen as redundant and therefore could be omitted.

The input format for matrices is defined in SLHA2: http://arxiv.org/abs/0801.0045

Again, it mentions that the formatting follows that of SLHA1 and when they do actually provide a formatting string, they use the word "should". I know I might sound pedantic, but as this is meant to be a format specification, the words "should" and "must" have a specific meaning. I've adapted my code so that every line always has a '#' included, but I just wanted to let you know and also other people can be aware of this as well.

1) Page 15 of SLHA2:

They will be given in the new blocks MSQ2IN, MSU2IN, MSD2IN, MSL2IN, MSE2IN, with
the FORTRAN format

Code: Select all

(1x,I2,1x,I2,3x,1P,E16.8,0P,3x,’#’,1x,A).

I don't see any 'should' here.

2) Anyway, I don't consider this is as bug. The SPheno reading routine are very cooperative compared to other codes which even demand the correct number of spaces and a comment to be there.

3) I understood already that you are pedantic. However, I'm too busy at the moment to deal with that, i.e. I'm won't be able to take care of these 'cosmetical issues'. As long as the physics results are not affected, you'll have to live with that or fix it privately.

No harm meant!
Florian

As I said, I'm mostly raising the issue in case other people have the same error. I agree completely that this is a minor issue and a fix can easily wait (or it could even go without a fix I guess).

I just ran into this issue and honestly, I consider it to be very dangerous that the SPheno version generated by SARAH silently reads incorrect values from the SLHA input files if not every line follows the format “index, value, comment”, especially since this isn’t documented anywhere! This does not just affect matrices (like “BLOCK YUKAWA”), but every block, such as SPhenoInput. I just spent several days wondering why my settings in SPhenoInput didn’t work. The dangerous part is that every third index/value is swallowed “at random” so that arbitrary entries are set to arbitrary values, potentially messing up important settings like conventions for other tools. If you’re unlucky, the results calculated in the end may be completely meaningless!

Note that as of version 4.0.3, SPheno itself (src/InputOutput.F90) does not have this issue. For example, in the subroutine Read_SPhenoInput (line 2092), there is while in the SARAH-generated version, there is The additional “read_line” is commented out in src/InputOutput.F90, which leads to the correct behavior, while its presence in the SARAH version causes the problems explained above. The same goes for all the other subroutines in that file. So all I’m asking here is that the behavior of SARAH-generated SPheno versions should align with the current original SPheno.

One can easily get bitten by this problem when using other tools (such as pySLHA) to process the SLHA files, which often strip or don’t insert any comments in the file.