Implement a Fortran version of the shell script sifdecoder

[amontoison]

I got some feedbacks from Windows users. The script sifdecoder in the bin folder is a Shell script and can't be easily used on some platforms like Windows.

We should think about doing a Fortran version such we can include it in the library libsifdecode.

cc @nimgould

[nimgould]

I am not sure I understand. This is already a fortran program, and all the script does is check that data is present and correct, and listemed to options that the user has provided.

[amontoison]

@jfowkes This is related to our conversation in the car as we were heading to Mont Saint Grégoire for our hike.

[jfowkes]

@nimgould the issue here is that sifdecoder is not a Fortran program but a shell script and shell scripts do not work on Windows, making it unusable for Windows users. The discussion we had with @amontoison is that the shell script functionality would be best implemented using a Fortran 90 program similar to what spral/driver/spral_ssids.F90 does. Fortran now has the get_command_argument functionality which would be quite useful for this.

[nimgould]

OK, why don't one of you write the prototype? To be useful, it would need to take in the name of the problem to be decoded as an argument, and to have other optional arguments so that it is fully compliant with all of the options supported by the script. The hardest is likely to be overriding the default parameter values (a vital part of the SIF format) which is much used in the script. Indeed, the script itself uses grep, awk and sed to preprocess the SIF file!!

So something like

  subroutine sifdecoder( name, precision, start, auto, pack, output_level, check, show, param )
  character ( len = * ), intent( in ) :: name ! name of sif file
 integer, optional :: start ! start point used (1-3,default =1) 
 integer, optional :: precision !  btytes for output reals (4, 8, 16, defaut=8) 
 character ( len = 1 ), optional : auto ! f for forward AD, b for backward, default=""
  integer, optional :: pack ! intended package, 1=lancelot,2=baria,3=cutest (default)
  integer, optional :: output_level ! 0=none(default),-ve verbose, >0 debug
  logical, optional :: check ! check derivatives if true (default false)
 logical, optional :: show ! display parameters if true (default false)
 character ( len = * ), optional :: param ! list of non-default parameter values, comma separated
 end subroutine sifdecoder

[nimgould]

Just to follow up, I am still unconvinced of the need for this. Not one of the 2000 papers that quote CUTE/r/st results uses native Windows (they couldn't!). Of course, maybe there would be 5000 papers if this was possible, but only a handfull of Windows users has ever asked me (and even then, seemed happy to use mingw or a virtual linux when advised).

[amontoison]

Well, it just depends on whether you want to evolve with the world and modernize your code to still be easily usable by users. 🙂

Why do we work on libHSL, a new build system for GALAHAD, SPRAL, CUTEst, SIFDecode, HSL, developed Julia and Python interfaces for these packages, and added continuous integration? We now have more platforms, more architectures, younger users with limited knowledge of compilation. Thirty years ago, nobody used Windows for doing research, nobody needed shared libraries, and people were still buying Fortran compilers!

If it was not needed, why did one of the original developer of CUTE/r/st (Philippe) recode a SIF decoder in Matlab?

Another example that comes to mind is that on Mac, the new default terminal relies on zsh, and I don't know if your shell script is working.

[nimgould]

Fair points. I guess I'll just end up doing the coding as usual ... sigh. It's a shame as tools like sed and awk will do things natively far better than I ever will.

As for writing a new decoder, I still don't know why Philippe did this, except that he has claimed that fortran is dead for the past decade (and that is why I think he his dropped out of the GALAHAD project). Of course this is news to me; I installed the latest (free) versions of four major fortran compilers in the last few days (gfortran, ifx, nvfortran and flang), so clearly some developers see a future for modern (not just legacy) fortran - by the way, I've been using free fortran compilers since the late 1980s.

I'm sure Jari knows more about zsh, but at least the blurb I read says that it is a superset reimplementation of bash that avoids the GPL restrictions. I am assuming that, just like gcc, there are still homebrew versions of bash out there.

And don't get me going on shared libraries, the biggest dead end that ever happened, and one that many linux developers hate with a passion, e.g., Linus Torvalds: "Shared libraries are not a good thing in general". Amen to that, the man talks out of the right end of his body.

I'll write the SIF parameter value code when I get a chance, no promises as I am just getting back to research after these years of endless software tweaking. This might well be better written in C (and there may be C components specifically to emulate sed and awk), but that's not my expertise.

[nimgould]

A question for you Windows people, at least those who aren't using mingw or wsl (and thus don't have bash). The fortrany way to interact with the command line is through the standard COMMAND_ARGUMENT_COUNT/GET_COMMAND_ARGUMENT functions/subroutines. However, the fortran standard doesn't rquire that these work, only that if this isn't supported on the OS, they return a value to say so. So what are these non-mingw/wsl compilers that you want us to support. Do we know that these support the above commands?

I have written a sifdecoder_standalone (bash-free) and it is fine under Linux. But have I wasted my time?

[amontoison]

We just want to support gfortran (and ifx if possible) on Windows. What we would like is to call the binary sifdecoder from Julia or Python to decode a problem.

[nimgould]

Done

Compile and then

sifdecoder_standalone --help

tells you everything. There are a couple of features from the script version that have not been implemented, but these are for debugging (derivatives and memory leak checks)

I'll leave it to you to describe to your Windows community, and to see if this works with the meson build (it is ok for all my Linux compilers with the make build)

[nimgould]

We just want to support gfortran (and ifx if possible) on Windows. What we would like is to call the binary sifdecoder from Julia or Python to decode a problem.

I have no idea what gfortran supports on Windows. As I said, the language will only support command line input if the compiler writer and OS work together to enable it. You should get one of your Windows target audience to give it a try, I haven't the first idea about Windows.

[amontoison]

Thanks Nick! I plan to use it in the Julia interface CUTEst.jl. Before that I tag a new release of SIFDecode, can you have a look of the CI errors? It seems that Intel compilers have an issue with a WRITE. (Meson builds) For the ArchDefs builds, they complain that the folders objects and modules are not here anymore. We probably need an mkdir -p instead of mkdir.

[nimgould]

OK, I'll have to code around the intel #6898 error, it seems to be a compiler (or actually a translator) bug as it is valid fortran according to gfortran, nagfor and nvfortran.

Now done, poor work intel. The mkdir issue is definitely my fault!

[amontoison]

Thanks @nimgould! :100: I will create a new release 2.5.0 and close this isssue.

Note that we have the same mkdir issue in the GitHub repository of CUTEst.

[nimgould]

Is this a meson thing? Or are you using the sifdecode install script. I added -p to that, and it didn't make any difference

[amontoison]

It seems to be an archdefs thing: https://github.com/ralna/SIFDecode/commit/70b2ad9d616a9ce11b9d98f2a65d2e9659d637ae#commitcomment-145335914

[nimgould]

The debug -vx flags were ignored ....

[amontoison]

Tomorrow is another day, as we say. Don't be late for the beer!

[amontoison]

@nimgould Just an example of why your work is useful: https://github.com/JuliaPackaging/Yggdrasil/pull/404#issuecomment-576958966

We no longer need hacks to use a bash shell in the Julia terminal and re-inject some environment variables to be able to decode the problem. It could also be useful for Jari in Python interface of CUTEst.

cc @jfowkes

[nimgould]

Glad this was useful :)