Explicitly set coords in nimrod load to have units "1"

[stephenworsley]

This should fix one of the failing tests in #3731 which would change the behaviour of nimrod loading due to a change in default units upon coord creation.

[stephenworsley]

It may still be worth checking if units are always explicitly set on lines:

iris/lib/iris/fileformats/nimrod_load_rules.py

Lines 571 to 573 in a07800c

	new_coord = iris.coords.AuxCoord(
	coord_point, bounds=bounds, **coord_args
	)

and

iris/lib/iris/fileformats/nimrod_load_rules.py

Lines 821 to 823 in a07800c

	new_coord = iris.coords.AuxCoord(
	np.array(coord_val, dtype=np.float32), bounds=bounds, **coord_keys
	)

[pp-mo]

@stephenworsley may still be worth checking

Undestood.
Is this otherwise ready to go, do you think ?

[stephenworsley]

@pp-mo Yeah, I think this should be

[stephenworsley]

After looking through the code a bit more, I believe the two cases I mentioned before should always set explicit units. In the first case because the dictionary set here contains units for every value:

iris/lib/iris/fileformats/nimrod_load_rules.py

Lines 488 to 493 in a07800c

	vertical_codes = {
	0: {
	"standard_name": "height",
	"units": "m",
	"attributes": {"positive": "up"},
	},

and in the seond case because this logic ensures that a unit is always present in the arguments:

iris/lib/iris/fileformats/nimrod_load_rules.py

Lines 765 to 768 in a07800c

	if not coord_keys.get("units"):
	coord_keys["units"] = units_from_field_code.get(
	field.field_code, "unknown"
	)

[pp-mo]

@stephenworsley the two cases I mentioned before should always set explicit units.

Dead right, I had just come to the conclusion myself.

I also checked all the ".add_xxx_coord(" throughout, and I believe they all check out.
So I reckon this is all good + we are done here ! 👍