How are cuts from run_card written to cuts.f?

Asked by Zachary Marshall

Hi,

We have a user with a rather strange problem. In MG 2.5.3, running an NLO process, the cuts.f card appears corrupted, as though the file width is not set correctly. The template looks like:

C Cuts from the run_card.dat
C***************************************************************
C***************************************************************
c
c CHARGED LEPTON CUTS
c
c find the charged leptons (also used in the photon isolation cuts below)

and the user's version looks like:

C Cuts from the run_card.dat
C***************************************************************
C***************************************************************
c
c CHARGED LEPTON CUTS
c
c find the charged leptons (also used in the photon isolation cuts
below)

Technically, this line does go beyond the 70 character limit (to 73 characters) of the ancient fortran standard. I was guessing there is some editor setting that is creating this automatic line breaking, but I don't know how to debug further unless I know how these lines are being modified according to the run card settings. Could you give me a hint, or have you run into this sort of a problem before?

Thanks,
Zach

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Zachary Marshall
Solved:
Last query:
Last reply:
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#1

Hi Zach,

This is indeed rather strange.
I have actually no clue of what is happening
Indeed
1) in my case the two files are 100% identical
2) I have check all the files that we write/modify with our FortranWriter class. And (as I expected) this one is not inside it.

So here, I am as puzzle as you on the problem.
Did you succeed to reproduce it?
My guess is that the user is doing special.

Cheers,

Olivier

> On 31 May 2017, at 10:33, Zachary Marshall <email address hidden> wrote:
>
> New question #637771 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/637771
>
> Hi,
>
> We have a user with a rather strange problem. In MG 2.5.3, running an NLO process, the cuts.f card appears corrupted, as though the file width is not set correctly. The template looks like:
>
> C Cuts from the run_card.dat
> C***************************************************************
> C***************************************************************
> c
> c CHARGED LEPTON CUTS
> c
> c find the charged leptons (also used in the photon isolation cuts below)
>
> and the user's version looks like:
>
> C Cuts from the run_card.dat
> C***************************************************************
> C***************************************************************
> c
> c CHARGED LEPTON CUTS
> c
> c find the charged leptons (also used in the photon isolation cuts
> below)
>
> Technically, this line does go beyond the 70 character limit (to 73 characters) of the ancient fortran standard. I was guessing there is some editor setting that is creating this automatic line breaking, but I don't know how to debug further unless I know how these lines are being modified according to the run card settings. Could you give me a hint, or have you run into this sort of a problem before?
>
> Thanks,
> Zach
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Zachary Marshall (zach-marshall) said :
#2

Hi Olivier,

If the cuts.f file is being written by the FortranWriter class, then I think the split lines are actually expected? The line length (L188 of the file_writers module) is specified as 71, and indeed this line is longer than 71 characters (it is 73 characters). The same is true of the other lines that get split (e.g. L246 of the template, Template/NLO/SubProcesses/cuts.f) -- they are over 70 characters, and if FortranWriter is writing them, they should be split. I'm starting to think the right answer is actually to fix the template to make sure that it doesn't run over the limit of the FortranWriter, no?

Best,
Zach

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#3

Hi Zach,

> If the cuts.f file is being written by the FortranWriter class, then I
> think the split lines are actually expected?

But cuts.f is NOT written by that class.

Even if it was, I have check that the splitting of the line is done correctly. In this case, the converted output is
C find the charged leptons (also used in the photon isolation cuts
C below)

(Which also proves that we do not call that class for cuts.f)

> I'm starting to
> think the right answer is actually to fix the template to make sure that
> it doesn't run over the limit of the FortranWriter, no?

Well the first point to understand is how that user can face such type of problem.
The above point is in principle save but I would still be worried about the fact that such user is modifying
core file in a way that he should not.

Cheers,

Olivier

> On 31 May 2017, at 22:04, Zachary Marshall <email address hidden> wrote:
>
> Question #637771 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/637771
>
> Status: Answered => Open
>
> Zachary Marshall is still having a problem:
> Hi Olivier,
>
> If the cuts.f file is being written by the FortranWriter class, then I
> think the split lines are actually expected? The line length (L188 of
> the file_writers module) is specified as 71, and indeed this line is
> longer than 71 characters (it is 73 characters). The same is true of
> the other lines that get split (e.g. L246 of the template,
> Template/NLO/SubProcesses/cuts.f) -- they are over 70 characters, and if
> FortranWriter is writing them, they should be split. I'm starting to
> think the right answer is actually to fix the template to make sure that
> it doesn't run over the limit of the FortranWriter, no?
>
> Best,
> Zach
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
rohin (rohin-tn) said :
#4

Hi

May be I can comment a bit here since I had this problem. The issue can be reproduced (in an ATLAS environment) by unpacking and running the setup script in the following tarball /afs/cern.ch/user/n/narayan/public/compile.tgz. I know this sounds very strange, but I have had two others who could reproduce the issue by from the tarball above

Cheers

Rohin

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#5

Hi Rohin,

Unfortunately, I do not have access to such script. Can you put it in a public space (and/or send it to me on my uclouvain account)

My feeling here is that ATLAS is modifying automatically the cuts.f in some way via some method. In that case what can I do? Since this is out of my control.

I can obviously modify cuts.f such that no comment line are above the 70 threshold but this would be a very weak fix of the problem.
(As soon as one of the developper will edit that template file, we will face such problem again.)

So I have two questions:
1) why do you need to modify cuts.f? (I can try to convince other author to include such change in the default code --if appropriate--)
2) How do you modify cuts.f? Clearly you are not using "our" fortranwriter class. One solution is actually to use it.

Cheers,

Olivier

> On 1 Jun 2017, at 00:09, rohin <email address hidden> wrote:
>
> Question #637771 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/637771
>
> rohin posted a new comment:
> Hi
>
> May be I can comment a bit here since I had this problem. The issue can
> be reproduced (in an ATLAS environment) by unpacking and running the
> setup script in the following tarball
> /afs/cern.ch/user/n/narayan/public/compile.tgz. I know this sounds very
> strange, but I have had two others who could reproduce the issue by from
> the tarball above
>
> Cheers
>
> Rohin
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Zachary Marshall (zach-marshall) said :
#6

Solved -- does look like pilot error.