You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something that has been bothering me since the very first day I touched the code is the extensive use of hardcoded parameters and variables. Some are at least located in an own module (cmn_parameters.f90) which is not an optimal solution, but still much better. The problem that arises from this is, that different values may be used in different modules of the model. Differing names make it hard to track the variables by greping.
On short-terms: Constants and variables should be tracked and but into cmn_paramerters.f90.
Updates: References should be checked and constants updated if there had been recent updates.
=> Well, this may actually raise follow-up issue... testing.
On the long run: I would like to see the implement an xml-based solution (or something similar).
The text was updated successfully, but these errors were encountered:
One step closer towards de-hardcodification:
All hardcoded paths to tables are now read from .inp.
The corresponding variables have been placed in cmn_chem.f90 or cmn_fjx.f90, respectively.
A dummy tracerlist has been created in which the hardcoded paths are substituted by $CICERO and $CTM3_INPUT and $CTM3_USR_INPUT, respectively. Those are replaced using "sed" in the updated job submission scripts (see examples). The current $CTM3_USR_INPUT (astra storage on abel) will become obsolete in the before December 1 since all date will be reunited there. The variable can be used by users to introduce their own forcings.
PLEASE: UPDATE your own inp-files AND job submission scripts accordingly!
Something that has been bothering me since the very first day I touched the code is the extensive use of hardcoded parameters and variables. Some are at least located in an own module (cmn_parameters.f90) which is not an optimal solution, but still much better. The problem that arises from this is, that different values may be used in different modules of the model. Differing names make it hard to track the variables by greping.
=> Well, this may actually raise follow-up issue... testing.
The text was updated successfully, but these errors were encountered: