Adapt inputs and transfers to new MOOSE multiapp transfer syntax

[GiudGiud]

See idaholab/moose#19676

[moosebuild]

Job Test nekRS on f8d082b : invalidated by @aprilnovak

random nek failure

[GiudGiud]

there's real failures here as well I think, I ll address them soon

[aprilnovak]

Thanks for this update! A few of the errors looked like random Nek failures (complicated Stack + caching sometimes just aborts a Nek test), but the OpenMC fails are definitely real.

We'll also need to update the tutorials directory, which has a few tests.

[GiudGiud]

Did I break the openmc build? I m getting hdf5 compilation errors.
I rebased let's see

I updated the tutorials

[aprilnovak]

Not sure, nothing looks obvious to me. I just re-triggered the test suite in a separate PR (which previously passed) to see if something changed on CIVET.

[GiudGiud]

It passed on the other recipe.
Seems the libmesh + petsc update in between broke the openmc build ?

[aprilnovak]

Hmm, okay - well it looks like the errors could be related to HDF5. I think the HDF5 changed within MOOSE recently, right?

[GiudGiud]

we now build HDF5 with petsc
This could be it. Seems we need to change the Cardinal recipe in some way then.
The Nek build wasnt using our petsc module right? Should we just have both builds not use it?

[aprilnovak]

Correct, I believe that both builds are using the script-based approach with PETSc.

[GiudGiud]

Yes but seems there's an accomodation use_module = False in the Nek recipe.
Who created that recipe? @loganharbour ?

[aprilnovak]

Yes, @loganharbour created these recipes

[GiudGiud]

Ok this is on our radar. I d like to get the Cardinal VTB recipe running first.
We are still working on hdf5 things at the moment for MOOSE as well in parallel, so we should be in a good place to look at this next week

[moosebuild]

Job Test on 1d8593d wanted to post the following:

View the site here

This comment will be updated on new commits.

[loganharbour]

I believe that all we need now here is to update MOOSE again now that idaholab/moose#20793 has made its way in. We may need to regold whatever is failing in order to produce it via exodus w/o HDF5.

[aprilnovak]

Looks like this is now giving the string_view error that we were encountering before:

/data/civet1/cardinal/contrib/moose/libmesh/installed/include/libmesh/mesh_base.h:811:44: error: 'std::string_view' has not been declared
  811 |   unsigned int get_elem_integer_index(std::string_view name) const;

[aprilnovak]

@ahuxford, would you please update the NekRSStandaloneProblem documentation once this is merged to be sure to reflect the new syntax changes to the MultiApp transfers? i.e. update the multi_app and direction parameters in the various code snippets

[moosebuild]

Job Test nekRS on c2014a4 : invalidated by @aprilnovak

random nek failure

[aprilnovak]

I ended up just skipping the failing tests; they work for me locally, so there is just something about CIVET's environment that is having trouble with it. We need to get Cardinal updated ASAP so that others working on the Griffin-Nek coupling can move forward.

[moosebuild]

Job Test nekRS on e8c68af : invalidated by @aprilnovak

random nek failure

[moosebuild]

Job Coverage on 1d8593d wanted to post the following:

Coverage

	39ee95	#355 1d8593
	Total	Total	+/-	New
Rate	89.05%	88.99%	-0.05%	100.00%
Hits	5081	5078	-3	8
Misses	625	628	+3	0

Diff coverage report

Full coverage report

This comment will be updated on new commits.