Closed penguian closed 3 years ago
@ccc561@nci.org.au commented
Changes for this ticket are in the branch: https://trac.nci.org.au/trac/cable/browser/branches/Users/ccc561/Metvar-lookup1
@ccc561@nci.org.au changed status from new
to assigned
@ccc561@nci.org.au changed owner from reporter
to ccc561
@ccc561@nci.org.au commented
Has been merged with trunk@8398.
Tested with GSWP3 and with site simulations from the CABLE benchmarking
@ccc561@nci.org.au set milestone to 2. Submission
@jxs599@nci.org.au changed status from assigned
to closed
@jxs599@nci.org.au set resolution to fixed
@jxs599@nci.org.au changed milestone from 2. Submission
to 1. Closed
@jxs599@nci.org.au commented
pushed to trunk@ e39c27d0cd41e5bba8db374a43ababbfd7fceebb
@ccc561@nci.org.au _changed keywords from met_forcing, input
to met_forcing, input nogit
_
keyword_input_nogit
keyword_met_forcing
owner:ccc561@nci.org.au
resolution_fixed
type_model improvement
| by ccc561This change is labeled as major as it is required to get the CABLE benchmarking/evaluation tool to work.
The code to read the variables in the met. file is using a lot of IF/ELSE statements to find the correct variable name in the met. file.
Those IF statements are linked to the source for the met. file (GSWP, ACCESS etc). It means if one wants to get inputs from a different met. file, one has to go and add a lot of IF/ELSE statements in the cable_input.F90 file.
I don't see why the variable names should be linked to the source of the met. file as it doesn't matter to CABLE. I propose to:
This change should simplify the adding a new source for met. forcing in CABLE, at least for the part of the code that finds and reads in the forcing variables. One would just need to check the lookup tables (all defined in one module) and add the correct names appropriately.
Issue migrated from trac:300 at 2023-11-27 11:38:04 +1100