After discussion with the Met Office, it seems that v5.9 of JULES would be a good place to start the refactoring of JULES to be compliant with the framework. All of the USE of modules have been removed, so all the information for the science subroutines should be passed through arguments of the subroutines. This should make it possible to isolate the science subroutines into the three framework components surfacelayer/subsurface/openwater.
On the JULES roadmap, there are also plans to use objects (i.e. Fortran derived types) to reduce the number of arguments in the subroutine calls, but this may not be done soon enough. These changes will also have impacts on JULES interfacing with our framework, and f2py is only able to exchange numpy arrays and scalars. This could be dealt with in a Fortran wrapper that would instantiate the derived types from the arrays/scalars that f2py is sending to the Fortran library.
After discussion with the Met Office, it seems that v5.9 of JULES would be a good place to start the refactoring of JULES to be compliant with the framework. All of the USE of modules have been removed, so all the information for the science subroutines should be passed through arguments of the subroutines. This should make it possible to isolate the science subroutines into the three framework components surfacelayer/subsurface/openwater.
On the JULES roadmap, there are also plans to use objects (i.e. Fortran derived types) to reduce the number of arguments in the subroutine calls, but this may not be done soon enough. These changes will also have impacts on JULES interfacing with our framework, and f2py is only able to exchange numpy arrays and scalars. This could be dealt with in a Fortran wrapper that would instantiate the derived types from the arrays/scalars that f2py is sending to the Fortran library.