unitarity constraint in the s->inf limit

[wkotlarski]

I've decided to split implementation of unitarity constraints for $s \to \infty$ from #524 into a separate PR.

@Expander, how should we present results? Should we implement

Block TREELEVELUNITARITY
   0    1.00000000E+00 # Tree-level unitarity limits fulfilled or not
   1    7.32883464E+00 # Maximal scattering eigenvalue

like SARAH (see Sec. 4.2.3 in here)

TODO:

• decide at which scale should unitarity be computed
• max_scattering_eigenvalue_infinite_s function should return the entire matrix of eigenvalues for testing
• write tests
• shift indices to C++ convention at the level of expression
• indent generated code
• move set_unitarity_infinite_s from templates/slha_io.cpp.in to src/slha_io.cpp
• mathlink interface

Validation:

• SM
• SSM
• MSSM?

[Expander]

@Expander, how should we present results? Should we implement

Block TREELEVELUNITARITY
   0    1.00000000E+00 # Tree-level unitarity limits fulfilled or not
   1    7.32883464E+00 # Maximal scattering eigenvalue

like SARAH (see Sec. 4.2.3 in here)

This would have the benefit of being compatible with SARAH. However, it would have the disadvantage that a user cannot easily use FS and SARAH together, because the block may be overwritten by one of the programs.

An alternative form could be:

Block FlexibleSUSYUnitarity # or FlexibleUnitarity
   0    1.00000000E+00 # Tree-level unitarity limits fulfilled or not
   1    7.32883464E+00 # Maximal scattering tree-level eigenvalue
   2    1.00000000E+00 # 1-loop level unitarity limits fulfilled or not
   3    7.32883464E+00 # Maximal scattering 1-loop level eigenvalue

which would allow us to add further fields to the block (like 1-loop unitarity limits etc.). Would this make sense?

[wkotlarski]

I've implemented it as follows

Block FlexibleSUSYUnitarity Q= 1.73340000E+02
     0     1.00000000E+00   # Tree-level unitarity limits fulfilled or not
     1     1.00121998E-02   # max(|re(a0)|)

Unitarity in the $s\to\infty$ limit is always computed at a fixed scale so I've also added it to the output.

[wkotlarski]

Should we implement the mathlink part as a new handle, e.g. FS<model>CalculateUnitarity (and later also FS<model>CalculateUnitaritywTrilinears)?

[Expander]

Should we implement the mathlink part as a new handle, e.g. FS<model>CalculateUnitarity (and later also FS<model>CalculateUnitaritywTrilinears)?

Do you mean that these functions should return a new handle? Or do you mean to just have separate (new) functions?

[wkotlarski]

I meant that since we don't implement unitarity as an observable we should not return it from FS<model>CalculateObservables[handle] but probably create a new function, e.g. FS<model>CalculateUnitarity.

[wkotlarski]

Is there a way to control precision of numbers returned by mathlink interface? Or is it always single precision float?

[Expander]

I think it is not restricted to single-precision floating point numbers. in <model>_librarylink.cpp we use MTensor for passing (n-dimensional arrays) numbers. There we check if the elements are of type MType_Real, which stands for double.

[Expander]

Please see the following code snippet:

DLLEXPORT int FSCMSSMOpenHandle(
   WolframLibraryData libData, mint Argc, MArgument* Args, MArgument Res)
{
   using namespace flexiblesusy;
   using namespace flexiblesusy::CMSSM_librarylink;

   if (Argc != 1)
      return LIBRARY_TYPE_ERROR;

   MTensor pars = MArgument_getMTensor(Args[0]);

   if (libData->MTensor_getType(pars) != MType_Real ||
       libData->MTensor_getRank(pars) != 1)
      return LIBRARY_TYPE_ERROR;

   try {
      auto data = make_data(make_dynamic_array_view(
                          libData->MTensor_getRealData(pars),
                          libData->MTensor_getDimensions(pars)[0]));

      const auto hid = get_new_handle();

      handles.insert(std::make_pair(hid, std::move(data)));

      MArgument_setInteger(Res, hid);
   } catch (const flexiblesusy::Error& e) {
      std::cerr << e.what_detailed() << std::endl;
      return LIBRARY_FUNCTION_ERROR;
   }

   return LIBRARY_NO_ERROR;
}

[wkotlarski]

Sorry. My bad. It's actually funny. make test/test_CMSSM_unitarity.m.xml prints with a different precision than wolframscript -f test/test_CMSSM_unitarity.m. So at least this is fixed.