Update MetaPhysicL

[lindsayad]

This update includes a major version change so there will likely be a decent amount of work in MOOSE at least to allow testing on this PR to be green. I already have a MOOSE fully compatible with the MetaPhysicL changes but the trick is that I'll need to make a MOOSE that is compatible with both old and new MetaPhysicL in order to allow us to have CI green all the way through this update process

[lindsayad]

I believe idaholab/moose#31813 will enable this to pass once it makes its way to MOOSE master

[roystgnr]

Well, I was expecting to need the swath of using std::foo; and s/std::foo/foo downstream, but what's up with:

ADRealForward.h:13:10: fatal error: metaphysicl/metaphysicl_version.h: No such file or directory ???

Double checking my own make install I see metaphysicl_version.h right where it should be, and ... oh, but this is interesting, from one of the "passing" recipes:

checking for MetaPhysicL NumberArray support... no
>>> Metaphysicl not found, you may need to run 'git submodule update --init' first <<<

Did one of us screw up something basic that's causing the simple NumberArray instantiation in libmesh_metaphysicl.m4 to fail? Maybe when I juggled include directives I missed something that numberarray.h needed, but we still passed MetaPhysicL recipes because all the tests there include more than just that one header?

[moosebuild]

Job Coverage, step Generate coverage on d899143 wanted to post the following:

Coverage

	af134b	#4300 d89914
	Total	Total	+/-	New
Rate	65.00%	65.01%	+0.00%	56.00%
Hits	76964	76966	+2	14
Misses	41434	41432	-2	11

Diff coverage report

Full coverage report

Warnings

• New new line coverage rate 56.00% is less than the suggested 90.0%

This comment will be updated on new commits.

[roystgnr]

Oh, of course that was it. We may even have to test for something blander like metaphysicl_exceptions.h in the long run, if we want a robust solution to the chicken-and-egg problem of figuring out whether we can configure with MetaPhysicL before we've configured MetaPhysicL; I could imagine a config dependency slipping into raw_type.h eventually.

[roystgnr]

Let's wait for the MOOSE compatibility to be merged and those tests to pass before we merge, of course.

An, as long as we have to kick the PR later anyway, I'd say let's do so by reordering the commits here so the intermediate git hashes will build+pass with MetaPhysicL too, but either way I'm happy with this.

[lindsayad]

idaholab/moose#31813 passed so that's promising

[lindsayad]

Oops now we're seeing the ad fparser issues

[moosebuild]

Job Test MOOSE on d899143 : invalidated by @lindsayad

[moosebuild]

Job Test MOOSE debug on d899143 : invalidated by @lindsayad

[lindsayad]

@roystgnr since you approved, I added a non-trivial commit 91779e7. Could you give that a look and see if you're ok with it? If you are ok, let's get this in and get a submodule update going before we inevitably get some more std:: additions in MOOSE and downstream apps 😆

[jwpeterson]

So, what's the plan with regard to backporting a metaphysicl update to past releases? I suppose I could try updating the metaphysicl submodule hash in 1.9.x and see what happens...

[roystgnr]

Hmm... I'd say we should hold off until we have an official MetaPhysicL 2.0 tag, and that should wait until we've had a chance to shake out this big swath of changes in MOOSE.

[roystgnr]

We're breaking the "Test No MPI/No PETSc" recipe (in devel->master, though I just noticed it in #4283) since merging this.

[roystgnr]

I'll see what I can make of it.

[lindsayad]

I'm happy to look into it too. I'll wait to hear back from you though before doing so

[roystgnr]

Wait, did you already tag v2.0.0? A little optimistic, in hindsight. ;-) The "who needs a release-candidate branch" MetaPhysicL philosophy never bit us too badly in the past, but I guess bumping the major version number was just too much hubris.

[lindsayad]

You can always delete a tag 😆