Fix longitude coord in cmorizers utilities.py

[flicj191]

Description

• Closes fix_coords is not fixing the bounds of the longitude coordinate #3910
• Link to documentation:

---

Before you get started

• ☝ Create an issue to discuss what you are going to do

Checklist

It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

• 🛠 This pull request has a descriptive title
• 🛠 Code is written according to the code quality guidelines
• 🛠 Documentation is available
• 🛠 Tests run successfully
• 🛠 The list of authors is up to date
• 🛠 Any changed dependencies have been added or removed correctly
• 🛠 All checks below this pull request were successful

New or updated data reformatting script

• 🛠 Documentation is available
• 🛠 The dataset has been added to the CMOR check recipe
• 🛠 The dataset has been added to the shared data pools of DKRZ and Jasmin by the @ESMValGroup/OBS-maintainers team
• 🧪 Numbers and units of the data look physically meaningful

---

To help with the number of pull requests:

• 🙏 We kindly ask you to review two other open pull requests in this repository

[valeriupredoi]

thanks for tackling this @flicj191 - we have to be careful here what of the two conditionals is stopping the call to fix_bounds: either overwrite_lat_bounds is False or cube.coord('latitude').has_bounds() is True - in which case no fixing is needed, though overwrite_lat_bounds is a bit of a loose constraint, maybe they do need fixing, and that was set to False by mistake?

[flicj191]

Thanks V!
hmm, no, overwrite_lat_bounds would be True, I was calling fix_coords() with the defaults. the output didn't have longitude bounds and the initial cube didn't have bounds either. The fix_coords() call when I used it to help CMORize fixed the depth, time and latitude coordinates but not the longitude.
I'll do a few more checks but I think it just got lost when getting parsed through fix_bounds()
ie. latitude is done like line 229:

if overwrite_lat_bounds or not cube.coord('latitude').has_bounds():
   fix_bounds(cube, cube.coord('latitude'))

whereas longitude here :

if overwrite_lon_bounds or not cube_coord.has_bounds():
    fix_bounds(cube, cube_coord)

I'll have another look and see

[valeriupredoi]

just be sure that cube_coord is indeed the "longitude" one - you never know with those raw datasets, maybe it's called "ducks" 🦆 (am not even joking, the amount of weird stuff I've seen in raw outputs, ducks may be even CMOR-like 😁 )

[flicj191]

yep so i'm proposing to replace cube_coord with cube.coord('longitude')
I haven't had a chance to test it all, will soon

[schlunma]

I am a little bit confused as to why this fix is necessary. Shouldn't cube_coord and cube.coord("longitude") be the same since the coordinate names are updated before running this code? If they are in fact different, are there two different longitude coordinates? To me this would indicate another problem with the data.

I also noticed that the metadata that is set during fix_dim_coordnames is different to the one expected by CMIP6, but this is probably something for another PR...

[flicj191]

Thanks, yes they should be the same, I was just finding that fix_coords did the other coords and not longitude on my dataset, could be strange behaviour so might not need this fix.
I'll check the fix_dim_coordnames if that needs to be fixed