Add a meson build system

[amontoison]

@dpo @nimgould @jfowkes

I take one hour tonight to start the Meson build system.

Nick, can you remove the sed command and add a proper way to compile in single and double precision?

[nimgould]

Hi Alexis, as I said before, sif files are hard coded in double precision, and I can't use preprocessor commands, it needs something like sed.

[nimgould]

Hi Alexs I have had a good look at how sifdecoder and cutest (are supposed to) work together. All is not well (in the single precision world). To set the scene, a SIF file contains a variety of nonlinear (element, group and external) functions and the glue that combines them to form an optimization function. The element and group definitions are written in a restricted form of fortran, and may themselves call private external functions, entirely written in fortran). When decoded, these form the elfuns.f90, groups.f90 and extern.f90 that you may have seen. The elfuns and groups routines have real arguments that may be single or double depending on whether the single or double decoder is used. However, the element and group definitions, and the external functions are not preprocessed, and thus always appear as double precision. This is generally ok if there are no external functions, and the SIF file's use of fortran is sufficiently restricted. But, as is the case with CAR2.SIF, the external function is always double precision, and thus may fail with single precision cutest. The only way I know to avoid this is via sed, c preprocessing is not available with SIF. I think I was aware of this, but not especially worried as many SIF examples actually need double precision for accuracy reasons. Our recommendation has always firmly to use the double version, and the 2500 papers that quote the cute evolution do precisely this as far as I know (or use the sed tool to produce single if they really must) It would be possible to use preprocessing within cutest, but a lot of work to make sure errors are not introduced; there are roughly 75 cutest functions, plus 50 interfaces to external solvers. Judging how long it took to translate GALAHAD (with roughly the same number of packages), this is three to four months work. I am not sure I have this time or energy, do you or the rest of the team? The work was justified for GALAHAD as this is a stand-alone solver. I am not sure it is for CUTEst. I would be interested to know the whole team's view. Nick

[jfowkes]

In light of what Nick has said, and in my experience with PyCUTEst where we only provide a double precision version, I don't think it makes sense to provide CUTEst (and by extension SIFDecode) in single precision. We should only provide double precision.

[amontoison]

I agree with Jari, I prefer to only keep the double precision version.
Let's support only what is working.
I remember that Dominique tried to use the single precision version in Julia and it was not working well (JuliaSmoothOptimizers/CUTEst.jl#179 and JuliaSmoothOptimizers/CUTEst.jl#177).

Having a Meson build system for CUTEst and being able to able a shared library seems way more relevant.

[nimgould]

I have investigated further. The sifdecoder program only needs to be in double, it can produce both single and double output elfuns (etc). The only issue was the possible external functions, and I have added a simple function that converts double to single for these. Thus to simplify, let's only generate the double version here, with a single meson (and for me makefile); the sed can go. Cutest is different. I can see some virtue in having both double and single codes, as a couple of supported solvers are only in single. Let me think about the work here, at the least it would be good to get meson builds for the cutest tools, not the solver interfaces. I probably overestimated the work to do this, it's likely quite mechanical Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Alexis Montoison ***@***.***> Sent: Monday, October 23, 2023 6:56:32 PM To: ralna/CUTEst ***@***.***> Cc: Gould, Nick (STFC,RAL,SC) ***@***.***>; Mention ***@***.***> Subject: Re: [ralna/CUTEst] Add a meson build system (PR #36) I agree with Jari, I prefer to only keep the double precision version. Let's support only what is working. I remember that Dominique tried to use the single precision version in Julia and it was not working well (JuliaSmoothOptimizers/CUTEst.jl#179<JuliaSmoothOptimizers/CUTEst.jl#179> and JuliaSmoothOptimizers/CUTEst.jl#177<JuliaSmoothOptimizers/CUTEst.jl#177>). Having a Meson build system for CUTEst and being able to able a shared library seems way more relevant. — Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACW4A6TSNWTUBELLOSR2YJTYA2VVBAVCNFSM6AAAAAA6KWRRH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZVG4ZDGNZRGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nimgould]

sifdecode 2.2 is now available (although I have no idea how to bump the version number!). This does not rely on sed, is only written in double precision, but can produce both single and double output files. Whether it needs meson ... well I leave that up to you, the make compilation is already very fast, but I suppose we probably need meson for the overall opttrove release

[amontoison]

Hi Alexis, as I said before, sif files are hard coded in double precision, and I can't use preprocessor commands, it needs something like sed.

Hi Nick, I think that you solve a different problem that what I have in mind.
When you compile libcutest_single.so or libcutest_double.so, you need to apply some sed commands (like replace MA27AD by MA27A).
I was just asking if we can have flags like -DCUTEST_SINGLE and -DCUTEST_DOUBLE for the compilation. It works well in GALAHAD.

[nimgould]

Hi Alexis, my plan is to branch cutest so that at least the tools are maintained by preprocessing commands (as in galahad) not via sed. This shouldn't be difficult, but will take time. There a number of things in the old sed system that are not needed (e.g, the ma27->ma57 substitutions).

I'll let you know when I have started, I am working on something else right at the moment (and recovering from a high-speed dog collision accident, standing at my terminal is difficult!)

[amontoison]

../include/cutest.h(60): error: identifier "__float128" is undefined
  typedef __float128   quadreal;

The old Intel compilers on Windows don't like __float128.

[nimgould]

I suppose that ths needs a CPP command to skip the definition for intel on windows. I don't know what the appropriate check is

[amontoison]

@nimgould
We need the following check:

#if defined(__INTEL_COMPILER) && defined(_WIN32)

[nimgould]

I've put the check you suggest along with _Quad in this case as this seems to be the Intel quad name. Let's see

[amontoison]

I've put the check you suggest along with _Quad in this case as this seems to be the Intel quad name. Let's see

@nimgould The issue is this line:
415d14a#diff-5497473d7bb58b3ec5a4f041d0a6b52df8b375909bb0d83e85b2dd2f0a763806R60

I updated cutest.h in this PR.

[amontoison]

../include/cutest.h(61): error: identifier "_Quad" is undefined
  typedef _Quad   quadreal;

We should drop the old Intel compilers for CI and say somewhere that only the new Intel compilers are supported on Windows.

[nimgould]

Google suggests we may need -lquamath for icc Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Alexis Montoison ***@***.***> Sent: Saturday, June 1, 2024 7:56:54 PM To: ralna/CUTEst ***@***.***> Cc: Gould, Nick (STFC,RAL,SC) ***@***.***>; Mention ***@***.***> Subject: Re: [ralna/CUTEst] Add a meson build system (PR #36) ../include/cutest.h(61): error: identifier "_Quad" is undefined typedef _Quad quadreal; We should drop the old Intel compilers for CI and say somewhere that only the new Intel compilers are supported on Windows. — Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACW4A6VRMNIRWA6TZHUAO7LZFIKPNAVCNFSM6AAAAAA6KWRRH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTGU2DSMRYGI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nimgould]

-lquadmath Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Gould, Nick (STFC,RAL,SC) ***@***.***> Sent: Saturday, June 1, 2024 8:55:46 PM To: ralna/CUTEst ***@***.***>; ralna/CUTEst ***@***.***> Cc: Mention ***@***.***> Subject: Re: [ralna/CUTEst] Add a meson build system (PR #36) Google suggests we may need -lquamath for icc Sent from Outlook for Android<https://aka.ms/AAb9ysg>

________________________________ From: Alexis Montoison ***@***.***> Sent: Saturday, June 1, 2024 7:56:54 PM To: ralna/CUTEst ***@***.***> Cc: Gould, Nick (STFC,RAL,SC) ***@***.***>; Mention ***@***.***> Subject: Re: [ralna/CUTEst] Add a meson build system (PR #36) ../include/cutest.h(61): error: identifier "_Quad" is undefined typedef _Quad quadreal; We should drop the old Intel compilers for CI and say somewhere that only the new Intel compilers are supported on Windows. — Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACW4A6VRMNIRWA6TZHUAO7LZFIKPNAVCNFSM6AAAAAA6KWRRH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBTGU2DSMRYGI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[nimgould]

or -Qoption,cpp,--extended_float_types . These intel flags are a mess!

[jfowkes]

We should drop the old Intel compilers for CI and say somewhere that only the new Intel compilers are supported on Windows.

Absolutely, there is little point testing on unsupported compilers that are increasingly more broken...