For MadSTR, the cleanest is likely that MadSTR plugin adds those parameters as
expected parameters that allows madstr to define a default value, a type and ensure that the parameters is always defined, ...
I will discuss this with Marco.
> This is a lot of work that you've done, thank you Olivier! I think some
> of the added functionality is very interesting, and could become quite
> useful in the future.
I hope it will.
Cheers,
Olivier
> On 8 Jan 2023, at 21:03, Zachary Marshall <email address hidden> wrote:
>
> This is a lot of work that you've done, thank you Olivier! I think some
> of the added functionality is very interesting, and could become quite
> useful in the future. I agree with what you say about enforcing better
> naming conventions for additional parameters as well (these particular
> ones came from the MadSTR plugin). I understand your concern about
> adding this development to 2.9.9, and I'm happy with having this all
> sorted out in the development version.
>
> Best,
> Zach
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/2001583
>
> Title:
> Unknown parameter f77 formatting issue
>
> Status in MadGraph5_aMC@NLO:
> Fix Committed
>
> Bug description:
> Hello authors, and happy new year!
>
> We've identified certain situations when parameters are included in a
> run card but are not known in banner.py. When the translation is done
> from run_card.dat into run_card.inc, these parameters have type
> internal.banner.UnknownType, and the automatic fortran formatting
> decides that they are strings almost independent of their value.
> Here's an example of the issue:
>
> STR_INCLUDE_PDF = 'True '
> STR_INCLUDE_FLUX = 'True '
>
> while the correctly generated code is:
>
> STR_INCLUDE_PDF = .TRUE.
> STR_INCLUDE_FLUX = .TRUE.
>
> A small patch to banner.py is sufficient to solve this problem for us:
>
> 2642,2643d2641
> < if value.strip() in ['1','T','.true.','True','0','F','.false','False']:
> < formatv = 'bool'
> 2651c2649
> < if str(value).strip() in ['1','T','.true.','True']:
> ---
>> if str(value) in ['1','T','.true.','True']:
>
> Notice the addition of strip, since frequently 'value' picks up white
> space. I've mirrored the values used for True as possible values for
> False here. This particular patch is against 2.9.9; in the current
> trunk of MG the equivalent patch would be L2998 and 3006 of banner.py.
>
> Would you be so kind as to include this in the two branches going
> forward?
>
> Thank you for your help,
> Zach
>
> PS - Thanks to Daniele Zanzi for the original report, and to Marco
> Zaro for helping with some of the debugging.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/2001583/+subscriptions
>
For MadSTR, the cleanest is likely that MadSTR plugin adds those parameters as
expected parameters that allows madstr to define a default value, a type and ensure that the parameters is always defined, ...
I will discuss this with Marco.
> This is a lot of work that you've done, thank you Olivier! I think some
> of the added functionality is very interesting, and could become quite
> useful in the future.
I hope it will.
Cheers,
Olivier
> On 8 Jan 2023, at 21:03, Zachary Marshall <email address hidden> wrote: /bugs.launchpad .net/bugs/ 2001583 banner. UnknownType, and the automatic fortran formatting ,'.true. ','True' ,'0','F' ,'.false' ,'False' ]: ,'.true. ','True' ]: ,'.true. ','True' ]: /bugs.launchpad .net/mg5amcnlo/ +bug/2001583/ +subscriptions
>
> This is a lot of work that you've done, thank you Olivier! I think some
> of the added functionality is very interesting, and could become quite
> useful in the future. I agree with what you say about enforcing better
> naming conventions for additional parameters as well (these particular
> ones came from the MadSTR plugin). I understand your concern about
> adding this development to 2.9.9, and I'm happy with having this all
> sorted out in the development version.
>
> Best,
> Zach
>
> --
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https:/
>
> Title:
> Unknown parameter f77 formatting issue
>
> Status in MadGraph5_aMC@NLO:
> Fix Committed
>
> Bug description:
> Hello authors, and happy new year!
>
> We've identified certain situations when parameters are included in a
> run card but are not known in banner.py. When the translation is done
> from run_card.dat into run_card.inc, these parameters have type
> internal.
> decides that they are strings almost independent of their value.
> Here's an example of the issue:
>
> STR_INCLUDE_PDF = 'True '
> STR_INCLUDE_FLUX = 'True '
>
> while the correctly generated code is:
>
> STR_INCLUDE_PDF = .TRUE.
> STR_INCLUDE_FLUX = .TRUE.
>
> A small patch to banner.py is sufficient to solve this problem for us:
>
> 2642,2643d2641
> < if value.strip() in ['1','T'
> < formatv = 'bool'
> 2651c2649
> < if str(value).strip() in ['1','T'
> ---
>> if str(value) in ['1','T'
>
> Notice the addition of strip, since frequently 'value' picks up white
> space. I've mirrored the values used for True as possible values for
> False here. This particular patch is against 2.9.9; in the current
> trunk of MG the equivalent patch would be L2998 and 3006 of banner.py.
>
> Would you be so kind as to include this in the two branches going
> forward?
>
> Thank you for your help,
> Zach
>
> PS - Thanks to Daniele Zanzi for the original report, and to Marco
> Zaro for helping with some of the debugging.
>
> To manage notifications about this bug go to:
> https:/
>