Are there any linked Issues or Pull Requests?
/issues/370, #205, MetOffice/jules/issues/41, MetOffice/jules/pull/42
Brief description
#205 & MetOffice/jules/pull/42 allows jules_pftparm namelist to be read at runtime and uses the same checking routine as JULES standalone. This issue tests the checking routines for robustness.
Further details of the issue.
This issue is not really an issue any more as there was an error on the LFRic core trunk, which meant that the configuration checker was exiting, but not raising an error code. Upgrading to the head of the LFRic core trunk now results in robust failure when running with an incorrect namelist. The following tests were run and output documented here:
Running with original namelist format duplicate=false
jules_pftparm should now have npft instances of the jules_pftparm namelist rather than one instance with arrays of size npft. Running with the latter, the configuration checker correctly fails with:
Cannot match namelist object name 0.650.0050.0050.10a_ws_io
Running with a duplicated name of instance
The configuration checker correctly fails with:
jules_pftparm namelist (brd_leaf), already allocated.
Incorrect number of instances of jules_pftparm
Exits with the runtime error:
ERROR: JULES_PFTPARM_INIT: Number of instances of jules_pftparm namelist (4) is not npft = 5
Running with unknown PFT
Exits with the runtime error:
ERROR: JULES_PFTPARM_INIT: PFT name not recognised: tree
Running with inconsistent jules_surface_types & jules_pftparm
Exits with the runtime error:
ERROR: JULES_PFTPARM_INIT: jules_pftparm and jules_surface_types inputs are inconsistent; brd_leaf_dec is not specified in jules_surface_types
Missing namelist entry
Exits with the runtime error:
INFO : CHECK_JULES_PFTPARM: No value for a_wl
ERROR: CHECK_JULES_PFTPARM: Variable(s) missing from namelist - see earlier message(s)
And similarly if there is a coding error where a variable has not been mapped in the code from config%jules_pftparm to jules_pftparm.
Are there any linked Issues or Pull Requests?
/issues/370, #205, MetOffice/jules/issues/41, MetOffice/jules/pull/42
Brief description
#205 & MetOffice/jules/pull/42 allows jules_pftparm namelist to be read at runtime and uses the same checking routine as JULES standalone. This issue tests the checking routines for robustness.
Further details of the issue.
This issue is not really an issue any more as there was an error on the LFRic core trunk, which meant that the configuration checker was exiting, but not raising an error code. Upgrading to the head of the LFRic core trunk now results in robust failure when running with an incorrect namelist. The following tests were run and output documented here:
Running with original namelist format
duplicate=falsejules_pftparmshould now havenpftinstances of thejules_pftparmnamelist rather than one instance with arrays of sizenpft. Running with the latter, the configuration checker correctly fails with:Running with a duplicated name of instance
The configuration checker correctly fails with:
Incorrect number of instances of jules_pftparm
Exits with the runtime error:
Running with unknown PFT
Exits with the runtime error:
Running with inconsistent jules_surface_types & jules_pftparm
Exits with the runtime error:
Missing namelist entry
Exits with the runtime error:
And similarly if there is a coding error where a variable has not been mapped in the code from
config%jules_pftparmtojules_pftparm.