Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Basic structure of pyFMS package #33

Merged
merged 19 commits into from
Apr 10, 2024

Conversation

fmalatino
Copy link
Contributor

@fmalatino fmalatino commented Apr 9, 2024

Description
This PR sets the basic layout of the pyFMS package. The pyFMS package allows for interoperability between some of the modules contained within the Flexible Modeling System and NDSL. Code contained within this PR is purely structural and cannot be used as of yet for true interoperability.

Use of the pyFMS package is as follows:

A shared object library, compiled from the source Fortran code containing the desired c-binded FMS modules must be made local to the installation of NDSL. The desired location for the file is within NDSL/external/FMS

Each c-binded FMS module will have an analogous python module contained within, which will contain functions which obfuscate the Fortran functionality, allowing for them to be used in a "pythonic" way. This can be seen in the subdirectories of pyFMS.

The pyFMS module makes use of the __init__.py module method for importing of the FMS functionality. For example to call the fms_func function the user would use the following format:

import ctypes as ct
import pyFMS

lib_fms = ct.cdll.LoadLibrary(lib_file)

pyFMS.fms_func(lib_fms, args)

How Has This Been Tested?
Tested via lint and currently implemented translate tests
OS: RHEL 8.9 Ootpa
Built conda environment using workflow in github action configurations

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • Any dependent changes have been merged and published in downstream modules
  • New check tests, if applicable, are included

@fmalatino fmalatino requested review from xyuan, bensonr and mlee03 April 9, 2024 16:20
Copy link
Collaborator

@xyuan xyuan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this pr looks good to me, have a few questions
1): assuming that the python files with "import ctypes" are python wrappers, not the ported python code, right?
2): should we add the python fms test to the pyFMS test directory instead of ndsl test directory?

@fmalatino
Copy link
Contributor Author

fmalatino commented Apr 10, 2024

@xyuan

  1. Yes, the files with import ctypes, such as pyFMS_block_control.py for example, will contain the python wrapper functions.

  2. I am impartial to where the tests will exist. I will gladly implement whatever the consensus decides.

@fmalatino fmalatino requested a review from xyuan April 10, 2024 13:57
@fmalatino fmalatino merged commit 67cd979 into NOAA-GFDL:feature/fms_port Apr 10, 2024
3 checks passed
@fmalatino fmalatino deleted the feature/fms_port branch August 20, 2024 18:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants