contamination of types_mod with other module data
Nobody has claimed this yet.
- Dominant language
- Fortran
- Stars
- 263
- Forks
- 182
- Avg merge
- 11d 12h
- Merged PRs (30d)
- 7
Description
Note for refactoring:
Data from other modules has crept into types_mod. I can't really justify the footprint of correcting this for its own sake, but this note is to keep track of this issue for any future refactoring.
State structure and filenames_io(?)
https://github.com/NCAR/DART/blob/16595cad595b6349605c9bc8e021c7ecc2c2391a/assimilation_code/modules/utilities/types_mod.f90#L22
These parameters should also go home to their respective modules:
https://github.com/NCAR/DART/blob/16595cad595b6349605c9bc8e021c7ecc2c2391a/assimilation_code/modules/utilities/types_mod.f90#L24-L33
Also a bunch of physical constants, probably should be in a physical_constants_mod and/or model specific:
https://github.com/NCAR/DART/blob/16595cad595b6349605c9bc8e021c7ecc2c2391a/assimilation_code/modules/utilities/types_mod.f90#L100-L103
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with assimilation_code/modules/utilities/types_mod.f90, especially lines 22, 24-33, 100-103, and 117-126. Read the surrounding module dependencies and identify where the state structure, filenames_io parameters, and physical constants belong. Done means the unrelated data has been moved to appropriate modules without breaking module users.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- fortran
- Domain
- data
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100