"no implicite type" error in SPheno

[BjHerrmann]

Dear Forum,

I am currently trying to compile SPheno for a rather simple non-supersymmetric model (essentially a one-generation version of the scotogenic model), and I am facing the following issue.
Basically, the generation of the SPheno source code seems fine, as I do not get any errors etc. on that side.
However, when compiling the model, I run into this:

~/Tools/SPheno/4.0.3> make Model=SimpleLFV
cd SimpleLFV ; /Applications/Xcode.app/Contents/Developer/usr/bin/make F90=gfortran version=400.00
cd ../src ; /Applications/Xcode.app/Contents/Developer/usr/bin/make F90=gfortran
gfortran -o SPheno -O SPheno4.o ../lib/../lib/libSPheno.a
mv SPheno ../bin
/Applications/Xcode.app/Contents/Developer/usr/bin/make F90=gfortran ../lib/libSPhenoSimpleLFV.a
gfortran -c -g -ffree-line-length-none -J../include -I../include Settings.f90
ar -ruc ../lib/libSPhenoSimpleLFV.a Settings.o
rm -f Settings.o
gfortran -c -g -ffree-line-length-none -J../include -I../include Model_Data_SimpleLFV.f90
Model_Data_SimpleLFV.f9034:

Real(dp) :: MA0,MA02,MAh,MAh2,MChi,MChi2,MFd(3),MFd2(3),MFe(3),MFe2(3),MFu(3),MFu2(3), &
1
Error: Symbol 'mchi' at (1) already has basic type of COMPLEX
Model_Data_SimpleLFV.f9030:

Complex(dp) :: ratioGG,ratioPP
1

[...]

Error: Symbol 'zpn' at (1) has no IMPLICIT type
Model_Data_SimpleLFV.f902:

ZZ = 0._dp
1
Error: Symbol 'zz' at (1) has no IMPLICIT type
make[2]: *** [../lib/libSPhenoSimpleLFV.a(Model_Data_SimpleLFV.o)] Error 1
make[1]: *** [bin/SPhenoSimpleLFV] Error 2
make: *** [bin/SPheno] Error 2

where the dots in the middle mean that this list of "no implicite type" errors is rather long.
Looking into the file Model_Data_SimpleLFV.f90, it seems to me that all of these variables are declared. So I am a bit confused about that.

Any ideas on this?
I am using SARAH 4.14.0 and SPheno 4.0.3.
I am attaching my model files and the obtained Model_Data_SimpleLFV.f90 (had to rename the latter to *.txt, *.f90 not accepted).

Thanks for your help, best regards,
Björn

[Avelino]

Hi Björn, I can have a look tomorrow. But in the meantime: that error appears when these variables are declared twice. You can fix the SPheno code by removing the second declaration. However, of course, it also means that there is something fishy in the SARAH implentation...

[BjHerrmann]

Hi Avelino,
good catch! Indeed I had overlooked this. I will try if taking out the second declaration solves the issue.
Thanks and have a good sunday,
Björn

[FStaub]

Hi,

I think the crucial line is:

Error: Symbol 'mchi' at (1) already has basic type of COMPLEX

Because of the, the declaration of the other parameters fails. So, you should check if you have a parameter in your model which called 'mchi' in your Fortran code. Note , Fortran is not case sensitive!

Cheers
Florian

[BjHerrmann]

Hi Florian,

I agree that it must have to do with the double declaration of e.g. Mchi, but also other parameters.
I just went through my model files and I only use MChi (in this precise spelling) in the model files.
It seemed to be declared once as complex, and then once as real...

Any idea about what might be the origin of this?
I am attaching a new version of my model files, where I explicitely define the parameters as reals, but the issue of the double declaration of e.g. MChi seems to persist. Now it is declared as real two times...

Cheers,
Björn

[FStaub]

The second mchi is the name of a mass, because it's always called "m+field".

[BjHerrmann]

OK, thanks to this information. Does this mean I should change the Output name, like

{Mchi, {Real -> True,
LaTeX -> "M_{\\chi}",
LesHouches -> MChi,
OutputName-> MChiXY }},

or sth in that style ?
I am a bit confused about SPheno will then make the identification with the parameter given in the Lagrangian (in my case: Mchi chi.chi)...

Thanks again for your help,
Cheers from Annecy,
Björn

[BjHerrmann]

Hi all,

I am still confused about this double declaration issue. The fermion mass, now called MX, is still declared twice...

I attach once more my now up-to-date model files.

The problems I get now are as follows:
1) I get some errors when running MakeSPheno[]:

Write I/O routines

Writing input routines

Writing output routines

StringJoin::string: String expected at position 2 in W<>None.

ToExpression::notstrbox: W<>None is not a string or a box. ToExpression can only interpret strings or boxes as Wolfram Language input.

StringJoin::string: String expected at position 2 in W<>None.

ToExpression::notstrbox: W<>None is not a string or a box. ToExpression can only interpret strings or boxes as Wolfram Language input.

2) If I take out the second declaration of MX, the compilation of SPheno stops now saying:

gfortran -c -g -ffree-line-length-none -J../include -I../include Couplings_SimpleLFV.f90
Couplings_SimpleLFV.f90:10637.65:

& cplPchcPchVPVZ,cplcVWpVPVWpVZ1,cplcVWpVPVWpVZ2,cplcVWpVPVWpVZ3)
1
Error: Duplicate symbol 'cplchifva0l' in formal argument list at (1)
Couplings_SimpleLFV.f90:10639.14:

Implicit None
1
Error: Unexpected IMPLICIT NONE statement in CONTAINS section at (1)
Couplings_SimpleLFV.f90:10641.13:

& v,lam2,lam1
1
Error: Unexpected data declaration statement in CONTAINS section at (1)
Couplings_SimpleLFV.f90:10643.112:

R(3,3),ZEL(3,3),UV(3,3),Yd(3,3),ZDL(3,3),ZDR(3,3),Yu(3,3),ZUL(3,3),ZUR(3,3)
1
Error: Unexpected data declaration statement in CONTAINS section at (1)

[... plus a couple of more errors in that style ...]

This seems to be independent of the used version of gfortran (I checked 4.4 and 8).

Any ideas about this?
Avelino, Florian, do you think you might be able to look into my model ?
Or, Avelino, do you happen to have a SARAH/SPheno version of the scotogenic model or sth similar (I believe that you have worked on this) which I might cross-check against my implementation? The two models are quite similar (mine only has 1 generation of new fermions).

Cheers,
Björn

[Avelino]

I just tried this implementation of the Scotogenic model with SARAH-4.13.0 and SPheno-4.0.3. The SPheno code is generated correctly, and I only get some warnings...

Code: Select all

Non-zero result for {etI,etp,conj(Hp)} vertex which violates charge. (This might just be a problem with simplifying the vertex, but could also point towards a mistake in the implementation.)

... which, I believe, are OK. Finally, it compiles correctly and runs without any problem (I include a LesHouches input file as example). Does this help to understand the origin of your problems?

[BjHerrmann]

Hola Avelino,
I also get such warning, but I checked in my case as well, and I believe that this is not a problem (and not related to the issues I experience).
Thanks for sending the scotogenic model, I will try tomorrow, and report here what the outcome is regarding my implementation.
Thanks a lot, cheers,
Björn