Finite-Difference Mode: New Documentation and User Interface Revamp

[feathern]

This PR revises the finite-difference interface such that:

1. It is easier to specify a nonuniform grid directly through main_input.
2. It is possible to specify a custom mesh in Python that can subsequently be passed to Rayleigh through a grid-specification file.

I've also added documentation for these features. It can be found in the 'User Guide / Setting up a Model / Grid Setup' section. The new main_input keywords that have been added are also defined in the quick reference section that describes the namelist inputs.

-Nick

[feathern]

I'm a little perplexed as to why the build is failing. It looks as though MPI_Bcast isn't being called correctly, but I'm unsure why. This compiles fine on my machine. If possible, could someone(s) start reviewing this while I dig a little more deeply in what's wrong here? It's probably an issue with the MPI datatypes vs. me just using an integer (though that's not what the documentation for Bcast says...).

[tukss]

Edit: I was too quick. This seems to be a different, possibly related issue.

I think that's the usual problem we get with certain MPI implementations and newer versions of gfortran. Because the F90 MPI API doesn't have a way to specify a generic type for the buffer, gfortran guesses the type from the first call and then compains if you call the same function with a different type later. This can be fixed in a few ways.

• Add the -fallow-argument-mismatch to gfortran.
• Use the F77 MPI interface by passing -mpi-f77 to configure. No type checking is performed in this case.
• Switch to the F08 MPI interface. We don't support that yet, but I was playing with it a while back. Should be a separate PR, of course.

[tukss]

Ah, it's easy actually. You're passing the whole communicator type into MPI_Bcast instead of just the %comm element, that's integer that MPI wants. My gfortran was a bit more descriptive in its error message.

[feathern]

Thanks @tukss ! Good catch. Now I'm puzzled as to why my local compiler didn't complain + the code appeared to be broadcasting the correct information too. OK, this is ready for review now.

[tukss]

Now I'm puzzled as to why my local compiler didn't complain + the code appeared to be broadcasting the correct information too. OK, this is ready for review now.

Even though it's not guaranteed by the Fortran standard, passing a reference to the whole object is likely to be identical to a reference to the first element. So it's quite possible that the code ran correctly. I guess your compiler just wasn't doing any type checking for some reason.

[tukss]

@rpvin can you have a look at this? You're the main user of this feature at the moment.

[feathern]

Has anyone had a chance to look at this yet?

[rpvin]

Hi,

Unfortunately, not yet. I will try to do this by the end of next week.

Cheers, Rathish

On Thu, Mar 21, 2024 at 7:18 PM Nick Featherstone @.***> wrote:

Has anyone had a chance to look at this yet?

— Reply to this email directly, view it on GitHub https://github.com/geodynamics/Rayleigh/pull/496#issuecomment-2013406935, or unsubscribe https://github.com/notifications/unsubscribe-auth/A4B2HVREUE2IWM27BPQ5ZBTYZMXAFAVCNFSM6AAAAABCR2OWESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJTGQYDMOJTGU . You are receiving this because you were mentioned.Message ID: @.***>

-- Cheers, Rathish Previn Ratnasingam PhD Applied Mathematics (Newcastle University) MSc Theoretical Physics(University of Edinburgh) BSc Physics(Imperial College London)

[feathern]

I'm going to go ahead and merge this. I tested it quite a bit before the initial commit 3 months ago. I would really like to get this wrapped into the code for a spring, pre-workshop release. We can address bugs, if any, at the workshop.