There was confusion from someone defining a perturbation. They got this error:
assertion failed: forcing_parse_field: wrong number of fields in perturbation definition, should be 5.
even though the perturbation definition seemed fine:
{
"filename": "INPUT/RYF.rlds.1990_1991.nc",
"fieldname": "rlds",
"cname": "lwfld_ai",
"perturbations": [
{
"type": "offset",
"dimension": "temporal",
"value": "INPUT/RYF.rlds.1990_1991_wcwc10.nc",
"calendar": "experiment"
}
]
},
The issue was a missing comment field, which is now mandatory, but the check for the comment is after this section
|
call self%core%get(perturbation_jv_ptr, "comment", & |
|
comment, found) |
|
call assert(found, 'forcing_parse_field: perturbation missing "comment" field') |
so never gets flagged, and the user does not know why their perturbation definition is incorrect.
I believe moving the assert block which checks for a comment to the beginning of the loop (say line 194) makes sense, and the rest of the logic can remain as-is.
There was confusion from someone defining a perturbation. They got this error:
even though the perturbation definition seemed fine:
{ "filename": "INPUT/RYF.rlds.1990_1991.nc", "fieldname": "rlds", "cname": "lwfld_ai", "perturbations": [ { "type": "offset", "dimension": "temporal", "value": "INPUT/RYF.rlds.1990_1991_wcwc10.nc", "calendar": "experiment" } ] },The issue was a missing
commentfield, which is now mandatory, but the check for the comment is after this sectionlibaccessom2/libforcing/src/forcing_config.F90
Lines 331 to 333 in a227a61
so never gets flagged, and the user does not know why their perturbation definition is incorrect.
I believe moving the
assertblock which checks for a comment to the beginning of the loop (say line 194) makes sense, and the rest of the logic can remain as-is.