-
Notifications
You must be signed in to change notification settings - Fork 18
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
Feature/pnorris/#1915 all MAPL orbital parameters now encapsulated in Sun_Mod in MAPL_sun_uc.F90 #1920
Feature/pnorris/#1915 all MAPL orbital parameters now encapsulated in Sun_Mod in MAPL_sun_uc.F90 #1920
Conversation
…rameters-encapsulated-in-Sun_Mod
Can we added a function MAPL_SunOrbitCreateDefault ? Sometimes users may not have access to Config. |
@weiyuan-jiang The interface on |
@tclune Tom, Thanks, I pushed your recommended changes. Re the ESMF_GetConfigAttribute(), yes, we dropped trying the MAPL_GetResource() because it still involved a circular reference to the latter's definition in MAPL_Generic(). |
Tested and zero-diff. |
Description
Changed call to MAPL_SunOrbitCreate() inside MAPL_Generic.F90 to new MAPL_SunOrbitCreateFromConfig(). The latter gets the orbital parameters from the MAPL state's Config. In this way no default orbital parameter values need appear in MAPL_Generic.F90. Rather, these default values are encapsulated where they belong in Sun_Mod in base/MAPL_sun_uc.F90 and are now explicitly named and commented on at the head of the module.
Related Issue
issue #1915
Motivation and Context
It cleans up the code so hardwired orbital parameter default values no longer appear in MAPL_Generic. It was decided it would be better to place them directly in Sun_Mod. This makes the code more encapsulated. To expose them instead in a Physical Constants file would be both incorrect (they are epoch relevant values, not constants) and might expose them more easily to inappropriate changes.
How Has This Been Tested?
Tested to be zero-diff.
Types of changes
Checklist: