This change here is consistent with the intent of the PR but it highlights something missing (I think)

Since you've changed the TYPE of ssnow%evapfbl you should also need to change the length of the associated MPI declarations (should be r2len not r1len) - I don't see these changes in the changeset.

Done

Just a check - does the blen(bidx) = r1len at line 2513 also need changing?

I believe the line 2513 you are referring to has been removed. It was for canopy%evapfbl that I removed. Line 2513 now has the MPI code for canopy%epot.

I can't find any reference to ssnow%evapfbl in mpimaster or mpiworker that is using r1len anymore.

This call to MPI_Type_Create_hvector seems to be creating something (types(bidx)?) based on bidx being an r1len variable at this point in the sequence - but that's no longer valid.

I think this must have been fine since the kind was not specified for canopy%evapfbl and defaulted to r1.

@SeanBryan51 But would it be fine with the PR's changes given that bidx is pointing (not in the sense of a POINTER) to ssnow%evapfbl which is now r_2?

@har917 , bidx is only used as an array index. types is an array and we add the information for evapfbl in vector form to that array (my guess is that it stores some kind of total length in bytes). The index used for types does not change depending on the type of the variable (r_2 or r_1). types contains INTEGERs, so I'd assume the integer for a r_2 array is bigger than for a r_1 array but it's still only 1 number that only needs to be stored in one place in the types array. So bidx (the index counter for the types array) is still incrementing by one. And we only need one element of the types array types(bidx) to store the information.

My concern isn't really bidx or types but blen(bidx) - this seems (e.g. line 5659) to be used when setting up how the workers-masters will communicate. So setting this up to have the length 1 or r1len when %evapfbl is an r2len double precision REAL seems ... odd.

However - some of the variables are clearly being dealt with differently - see line 1983 for veg%froot which also does the call to MPI_Type_Create_hvector then blen(bidx)=1 - so there is some consistency (even if I don't follow the why).

Perhaps what I'm really getting at here is that this probably needs a short MPI test of just the change in KIND on ssnow%evapfbl separated out from the rest of the science change (? - more work though).

@SeanBryan51 But would it be fine with the PR's changes given that bidx is pointing (not in the sense of a POINTER) to ssnow%evapfbl which is now r_2?

Yes I think so as long as worker_cable_params is consistent with how the blocks have been organised in master_cable_params (i.e. blen and bidx) there should be no issues, and this looks to be the case.