Heat Transfer Example: MPI Datatype

[ax3l]

Replace the MPI_REAL8 datatype, which is optional in the MPI standard and not always available, with MPI_DOUBLE. The latter is always available and corresponds to the data sent around.

First seen as an OpenMPI compile error on a user's machine:
openPMD/openPMD-api#1424 (comment)

I found no further examples that use the same MPI type and would need an update.

[eisenhauer]

@vicentebolea What is your preferred protocol for maintaining 2.9 and master branches currently? I've submitted some things (like the DAOS engine) to master because we clearly don't want them in a release any time soon. Others, like PR #3591 are clear bug fixes related to new things in the release (default to BP5) and probably need to be in the release (and backported to master). Is this PR similar? Or more generally should most everything go to release_29 and be tagged for backporting to master? I.E. every kind of "normal" fix that isn't a feature that we don't want in 2.9 (which I guess is most every PR).

[vicentebolea]

What is your preferred protocol for maintaining 2.9 and master branches currently?

We should aim to keep the release_XY branches API/ABI compatible with very counted exceptions, this is, only bugfixes should go to the release branch and they should be carefully chosen so that they dont change either the API (ABI). The rationale of being strict with it is that downstream they expect it to be like this. They expect not to recompile when changing the patch version of adios2.

This PR, for instance looks fine, change the function call of mpi procedures no change in our API/ABI.

#3591 is a bigger change a deeper analysis is needed. There is a high chance of failure doing this manually, so I think that in the future we would want to add automated test for checking that API/ABI compatibility maybe something like running/building ADIOS2 tests from the X.Y.0 version using the source code of the new PR (API) or just linking with the new binaries (ABI) of the pull-request.

On the other hand we will have one more release before the end of September.

Vicente

[vicentebolea]

Also this branch can be rebased to release_29 for easier backporting.

[eisenhauer]

#3591 is a bigger change a deeper analysis is needed. There is a high chance of failure doing this manually, so I think that in the future we would want to add automated test for checking that API/ABI compatibility maybe something like running/building ADIOS2 tests from the X.Y.0 version using the source code of the new PR (API) or just linking with the new binaries (ABI) of the pull-request.

Thanks Vicente. I'll followup in #3591.

[anagainaru]

I assume this was not approved because it's not rebased on release_29?

[eisenhauer]

I assume this was not approved because it's not rebased on release_29?

Yeah, at least on my end. @ax3l, can you rebase and retarget to the release_29 branch?

[vicentebolea]

Alternatively, we can merge to master this and I can backport it later to release. @ax3l is a good long time contributor but not a core developer, so we can give him a hand on this :). @anagainaru if you approve Ill follow up the backport.

[ax3l]

Thanks for the help!

Sorry for being a bit slow, extended proposal season and deadlines kept me busy.

Thanks for the help backporting. Otherwise, if a simple rebase helps, please do not hesitate to rebase my PRs and force push on it :)

I admit my own project's backports are usually cherry-picked, your workflow is more elaborate and I sometimes forget that :)