Mixed mode FMS discussion

[MinsukJi-NOAA]

Related codes are here: https://github.com/MinsukJi-NOAA/FMS_tests

If any one can take a look at the above repository and comment, it would be helpful for me.

Thanks!

[junwang-noaa]

Comparing approach1 and approach2, I think approach1 is cleaner.
Comparing the data types in my_data1 and my_data2, the data types in my_data1 may be more convenient. But it has impact on the top level code that uses data type grid. We need to change those type(grid) to class(*). While for data type in my_data2, we may not need to change the type definition (e.g. type(grid_all) :: mygrid), but have to modify the code to use the proper variables mygrid%x_r4. etc.

[junwang-noaa]

Is this simple example for the horiz_interp_type in horiz_interp_type.F90?

[MinsukJi-NOAA]

This example was based off of diag_grid.F90.

[junwang-noaa]

@bensonr @thomas-robinson which approach and data type update do you prefer?

[thomas-robinson]

I added a PR MinsukJi-NOAA/FMS_tests#1 to the repository. It uses the class(grid_base) instead of class(*) because the variable/pointer grid is always going to be one of the extended types from grid_base.

I also added a nullify for the pointer in approach2.

I agree that approach1 is cleaner. I don't think I see an advantage to using approach2, unless you just really like working with the pointer. We have started moving away from pointers as much as possible in the FMS code, but in this case it seems like it's being used in a correct manner. There used to be an _ALLOCATABLE macro that would get filled in with either pointer or allocatable to support old and new Fortran, but we got rid of that and replaced it with allocatable. With that in mind, I would prefer approach1.

If you pulled the type definitions into the module using it, then you wouldn't have to make grid_base public like I had to. I don't know if that's an option for the real code though.

@GFDL-Eric do you have anything to add?

[MinsukJi-NOAA]

Thanks for making the changes. Your PR was merged. I also realize that class(grid_base), allocatable, target :: grid in approach1 does not need to have the target attribute.

[MinsukJi-NOAA]

Thank you for the feedback @junwang-noaa and @thomas-robinson. I also prefer approach 1. As Jun mentioned, all of them need some kind of modifications upstream, but I think changing to class(grid_base) is easier than changing to x_r4 and x_r8 -- occurs in less number of places. Another advantage is that for the subroutine do_something_with_grid, which does not have any class(*) dummy argument, it is easier to select between r4 and r8 version, because we can just do select type(grid).

[MinsukJi-NOAA]

Another possible approach that is not in https://github.com/MinsukJi-NOAA/FMS_tests is to do something like this:

type :: grid_all
   integer :: i, j
   class(*), pointer :: x, y
end type grid

type(grid_all) :: grid

with a constructor assigning class(*), pointer components to either real(4) or real(8).

But I have yet to come up with a non-messy way to do this... One issue was that select type (grid%x) does not work.

[junwang-noaa]

I won't recommend this approach as there could be many variables x,y,..., checking the data type for those variables could make the code really messy.

…

On Fri, Sep 10, 2021 at 9:05 AM Minsuk Ji ***@***.***> wrote: Another possible approach that is not in https://github.com/MinsukJi-NOAA/FMS_tests is to do something like this: type :: grid_all integer :: i, j class(*), pointer :: x, y end type grid type(grid_all) :: grid with a constructor assigning class(*), pointer components to either real(4) or real(8). But I have yet to come up with a non-messy way to do this... One issue was that select type (grid%x) does not work. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#814 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TNIB2SCCOH6ZH26Q7TUBH7AVANCNFSM5DX4AXSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[thomas-robinson]

I agree with @junwang-noaa especially because you have them all as either r4 or r8, so extending the gird_all type makes more sense.

If x could be r4 and y could be r8, then this class(*) :: x,y might make more sense.

[GFDL-Eric]

If we're operating under the assumption that all subcomponents of the grid type are the same kind (r4 or r8), and I believe we are, then I prefer approach 1.

…

On Fri, Sep 10, 2021 at 10:02 AM Tom Robinson ***@***.***> wrote: I agree with @junwang-noaa <https://github.com/junwang-noaa> especially because you have them all as either r4 or r8, so extending the gird_all type makes more sense. If x could be r4 and y could be r8, then this class(*) :: x,y might make more sense. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#814 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3MSXMRGBRZJOHA4R4QLTTUBIFWJANCNFSM5DX4AXSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[MinsukJi-NOAA]

@thomas-robinson @GFDL-Eric Do you know where I can find some documentation on how to build and run unit tests on NOAA R&D platforms (e.g. Hera)?

[bensonr]

@MinsukJi-NOAA - If you are asking about how to run the existing FMS unit tests, here is how I do it on hera:

set up an environment

module purge
module load intel/2020.2
module load impi/2020.2
module load netcdf/4.7.0
module load hdf5/1.10.6
setenv FC mpiifort
setenv F77 mpiifort
setenv CC mpiicc
setenv CXX mpiicpc
setenv CFLAGS "-O0 -g -traceback -ftrapuv -I${NETCDF}/include/"
setenv FCFLAGS "-O0 -g -traceback -check all -check noarg_temp_created -check nopointer -nowarn -ftz -auto -safe-cray-ptr -ftrapuv -I${NETCDF}/include/"
setenv LDFLAGS "-O0 -g -traceback -L${NETCDF}/lib"

build the FMS library

cd FMS ; mkdir build ; cd build ; autoreconf -i ../configure.ac ; ../configure ; make

build/run the various CI tests (you must be on a batch node for this part)

salloc --nodes=1 --time=00:30:00

• set the environment as above

make -k check