Trilinos 13 4 superlu dist 8 patch

[jwillenbring]

@balay @masterleinad @balos1

Motivation

The xSDK 0.8 release is potentially going to include Trilinos 13.4 as Trilinos 14.0 is delayed. Some other xSDK packages are not ready to use a newer version of Trilinos. However, some packages require superlu_dist version 8, which is not supported by Trilinos 13.4. This patch applies superlu_dist 8 support, which was previously added to the develop branch, to the 13.4 branch.

Stakeholder Feedback

There is some relevant conversation in this issue:

https://github.com/xsdk-project/xsdk-issues/issues/177

Testing

This would be tested as part of the xSDK 0.8.0 release testing. It would also go through Trilinos PR testing if there are sufficient resources to do so.

[trilinos-autotester]

Status Flag 'Pre-Test Inspection' - Auto Inspected - Inspection Is Not Necessary for this Pull Request.

[trilinos-autotester]

Status Flag 'Pull Request AutoTester' - Failure: Job Trilinos_pullrequest_gcc_8.3.0 on Jenkins server at https://ascic-jenkins.sandia.gov Not Enabled

• Other jobs have been previously started - We must stop them...

[jhux2]

@trilinos/amesos2 @srajama1 @iyamazaki

[iyamazaki]

I think for SuperLU, Amesos2 just adds new arguments for new versions, e.g.,

      extern void
      sgstrf (SLU::superlu_options_t*, SLU::SuperMatrix*,
              int, int, int*, void *, int, int *, int *,
              SLU::SuperMatrix *, SLU::SuperMatrix *, 
#ifdef HAVE_AMESOS2_SUPERLU5_API
              SLU::GlobalLU_t*,
#endif
              SLU::SuperLUStat_t*, int *);

But, these changes look fine to me (I could build and pass with SuperLU_Dist 6 or 8). Thank you @jwillenbring.

[ndellingwood]

Does a matching patch need to be applied to the develop branch (so these changes aren't clobbered by 14.0 release)?

[balay]

Does a matching patch need to be applied to the develop branch (so these changes aren't clobbered by 14.0 release)?

These commits are already in develop so there should not be any such conflict. However I do see a minor conflict with current develop branch wrt trilinos-release-13-4-branch - that needs to be resolved.

balay@p1 /home/balay/git-repo/github/trilinos (develop =)
$ git merge origin/trilinos-release-13-4-branch
Auto-merging Version.cmake
CONFLICT (content): Merge conflict in Version.cmake
CONFLICT (modify/delete): cmake/std/PullRequestLinuxIntel17.0.1TestingSettings.cmake deleted in HEAD and modified in origin/trilinos-release-13-4-branch.  Version origin/trilinos-release-13-4-branch of cmake/std/PullRequestLinuxIntel17.0.1TestingSettings.cmake left in tree.
Automatic merge failed; fix conflicts and then commit the result.
balay@p1 /home/balay/git-repo/github/trilinos (develop *+=|MERGING)
$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	both modified:   Version.cmake
	deleted by us:   cmake/std/PullRequestLinuxIntel17.0.1TestingSettings.cmake

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	Version.cmake.orig

no changes added to commit (use "git add" and/or "git commit -a")

Once this conflict is resolved - there is no conflict with the PR commits

balay@p1 /home/balay/git-repo/github/trilinos (develop >)
$ git fetch -q https://github.com/jwillenbring/Trilinos trilinos-13-4-superlu-dist-8-patch
balay@p1 /home/balay/git-repo/github/trilinos (develop >)
$ git merge FETCH_HEAD 
Merge made by the 'ort' strategy.
balay@p1 /home/balay/git-repo/github/trilinos (develop >)
$ 

So perhaps this PR is ready-for-merge?

[balay]

Ping again! Can this be merged?

[balay]

Reminder, could this PR be merged in?

Hoping to get this fix into spack as-well via https://github.com/spack/spack/pull/33533

[balay]

Checking again. It would be good to get this merged in so that the spack PR can also be merged in for xsdk.

Or should we get that spack PR merged in before this @sethrj ?

[jwillenbring]

@balay Sorry, I've been on travel the last couple weeks. I will look into this and report back.

[jwillenbring]

After consultation with the @trilinos/framework team, given some current branch testing issues and the fact that the PR testing won't actually test this change because we don't test with a new version of SuperLU_Dist, as well as the fact that this has been tested by the xSDK team, I am going to go ahead and merge this.

[balay]

Thanks @jwillenbring !

[jwillenbring]

I have a PR up for incrementing the version number. Then I can provide a new tag. If you want, you could go with the branch for now, but I plan to also produce a tag.

https://github.com/trilinos/Trilinos/pull/11252/files

[balay]

@jwillenbring - Since you are creating 13.4.1 release - will use that.