Upgrade MUMPS_jll.jl to v5.7.3

[amontoison]

No description provided.

[amontoison]

@hochunlin
Do you know what changed in the main MUMPS structure for the releases 5.7.x?

[hochunlin]

@amontoison
I believe that mumps_struc.jl and mumps_types.jl should be modified. Back to 6 months ago, I was able to utilize MUMPS 5.7.x through Julia. I think here can make similar change:

complexphoton/MESTI.jl@fcb2a20#diff-ce4da8a0316b9e221d80dc8a06ce816a6b73afe917d4b3df5b635239d9ad8041R56

complexphoton/MESTI.jl@fcb2a20#diff-123280c300904ad0c7af6365e86436acd1ed506e2a67cee7fb5bd461fe614421R32

What I did was just track what changes in the MUMPS source code files, xmumps_c.h, and xmumps_struc.h, between 5.6.x and 5.7.x. Then, I made the corresponding change in my mumps3_types.jl and mumps3_struc.jl.

I may be able to look into it and make another PR, but since I am in the industry now, I am not sure when I would be available.

[amontoison]

Thanks for your help @hochunlin!
I will be able to update the interface with what you shared.

Alwo, why are you not direclty using MUMPS.jl in MESTI.jl?
MUMPS is already precompiled as a JLL here and the user doesn't need to compile anything.

[hochunlin]

@amontoison, I am glad that it helps.

I thought back to then; my advisor knows the developer of MUMPS3.jl, so we just followed what was done in MUMPS3.jl. Precompiled MUMPS as a JLL is a more convenient way. We did not notice that.

Also, as with my previous PR, could you help me change size_schur::MUMPS_INT back to size_schur::MUMPS_INT8? It would be helpful for me to do some current tests utilized MUMPS.jl. Thank you!

[amontoison]

@hochunlin The issue is that size_schur is a MUMPS_INT in the C header of MUMPS 5.7.3. If we change it, it will cause a misalignment of the C structure.
Is it a mistake in the C header?

/*
 * Definition of the (simplified) MUMPS C structure.
 * NB: ZMUMPS_COMPLEX are REAL types in s and d arithmetics.
 */
typedef struct {

    MUMPS_INT      sym, par, job;
    MUMPS_INT      comm_fortran;    /* Fortran communicator */
    MUMPS_INT      icntl[60];
    MUMPS_INT      keep[500];
    ZMUMPS_REAL    cntl[15];
    ZMUMPS_REAL    dkeep[230];
    MUMPS_INT8     keep8[150];
    MUMPS_INT      n;
    MUMPS_INT      nblk;

    MUMPS_INT      nz_alloc; /* used in matlab interface to decide if we
                                free + malloc when we have large variation */

    /* Assembled entry */
    MUMPS_INT      nz;
    MUMPS_INT8     nnz;
    MUMPS_INT      *irn;
    MUMPS_INT      *jcn;
    ZMUMPS_COMPLEX *a;

    /* Distributed entry */
    MUMPS_INT      nz_loc;
    MUMPS_INT8     nnz_loc;
    MUMPS_INT      *irn_loc;
    MUMPS_INT      *jcn_loc;
    ZMUMPS_COMPLEX *a_loc;

    /* Element entry */
    MUMPS_INT      nelt;
    MUMPS_INT      *eltptr;
    MUMPS_INT      *eltvar;
    ZMUMPS_COMPLEX *a_elt;

    /* Matrix by blocks */
    MUMPS_INT      *blkptr;
    MUMPS_INT      *blkvar;

    /* Ordering, if given by user */
    MUMPS_INT      *perm_in;

    /* Orderings returned to user */
    MUMPS_INT      *sym_perm;    /* symmetric permutation */
    MUMPS_INT      *uns_perm;    /* column permutation */

    /* Scaling (inout but complicated) */
    ZMUMPS_REAL    *colsca;
    ZMUMPS_REAL    *rowsca;
    MUMPS_INT colsca_from_mumps;
    MUMPS_INT rowsca_from_mumps;

    /* Distributed scaling(out) */
    ZMUMPS_REAL    *colsca_loc;
    ZMUMPS_REAL    *rowsca_loc;

    /* Info after facto */
    MUMPS_INT      *rowind;
    MUMPS_INT      *colind;
    ZMUMPS_COMPLEX *pivots;

    /* RHS, solution, ouptput data and statistics */
    ZMUMPS_COMPLEX *rhs, *redrhs, *rhs_sparse, *sol_loc, *rhs_loc, *rhsintr;
    MUMPS_INT      *irhs_sparse, *irhs_ptr, *isol_loc, *irhs_loc, *glob2loc_rhs, *glob2loc_sol;
    MUMPS_INT      nrhs, lrhs, lredrhs, nz_rhs, lsol_loc, nloc_rhs, lrhs_loc, nsol_loc;
    MUMPS_INT      schur_mloc, schur_nloc, schur_lld;
    MUMPS_INT      mblock, nblock, nprow, npcol;
    MUMPS_INT      ld_rhsintr;
    MUMPS_INT      info[80],infog[80];
    ZMUMPS_REAL    rinfo[40], rinfog[40];

    /* Null space */
    MUMPS_INT      deficiency;
    MUMPS_INT      *pivnul_list;
    MUMPS_INT      *mapping;
    ZMUMPS_REAL    *singular_values;

    /* Schur */
    MUMPS_INT      size_schur;
    MUMPS_INT      *listvar_schur;
    ZMUMPS_COMPLEX *schur;

    /* user workspace */
    ZMUMPS_COMPLEX *wk_user;

    /* Version number: length=30 in FORTRAN + 1 for final \0 + 1 for alignment */
    char version_number[MUMPS_VERSION_MAX_LEN + 1 + 1];
    /* For out-of-core */
    char ooc_tmpdir[1024];
    char ooc_prefix[256];
    /* To save the matrix in matrix market format */
    char write_problem[1024];
    MUMPS_INT      lwk_user;
    /* For save/restore feature */
    char save_dir[1024];
    char save_prefix[256];

    /* Metis options */
    MUMPS_INT metis_options[40];

    /* Internal parameters */
    MUMPS_INT      instance_number;
} ZMUMPS_STRUC_C;

[hochunlin]

@amontoison, I do not think that it is a mistake in the C header. Just the C header decides to use single precision for size_schur.

It did not throw an error when I changed this in v5.6.x. However, it is safe for me to change it in my branch and test them for now, since it is a specific need on my end.

[amontoison]

The C routines will just fill the bits in the structure after size_schur with chunks if you do that.
It's fine for me to change it to a MUMPS_INT8 if I understand why it's working on the C / Fortran side.
But from what I understand, only the first 32 bits of size_schur will be correct if we change the type.
I already got this issue in the past for QRMumps.jl.