Changes to lift the dependence of turb on star_data #739
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While making some enhancements to the thermohaline code (which is part of the turb module), I discovered a bad code smell: the turb module depends on the star_data module. This doesn't make architectural sense; turb handles macrophysics, and shouldn't know anything about stars.
The dependency comes through turb/private/tdc_support.f90; the convert() and unconvert() functions need to know how many variables are stored in auto_diff_real_star_order1%d1Array. This number is currently stored in the auto_diff_star_num_vars parameter defined in star_data/public/star_data_def.inc.
A functionally equivalent way to do this, which also fixes the architectural sense, is to use the actual declared length of auto_diff_real_star_order1%d1Array rather than auto_diff_star_num_vars.
This PR makes this change, plus a few others that accompany it:
I'd appreciate a quick turnaround on the PR, as it's needed in order for the new thermohaline stuff to work.