calendar/4D error

[mee067]

I have changed the way I process grib2 data to use nc format (converted using cdo) for forecasting purposes. I am getting a weird error message with the temperature variable (from RDPS) when I tried to run MESH:

 READING: basin_temperature.nc
   Checking the spatial reference of the file.
   WARNING: A CRS projection 'crs' was not found in the file (Code -49).
   ERROR: An error occurred reading information about the 'calendar' attribute (Code: -43).
   ERROR: The 't' variable contains an incompatible number of dimensions for the time dimension (3). The variable must contain only one dimension.

It managed to read shortwave, longwave, and precipitation. Temperature is the next variable (the nc file is attached) and it was originally 4D, but I did remove the additional height dimension (different methods but same issue). The calendar was "proleptic_gregorian" but I changed it to "gregorian" for MESH to stop some warnings. This applies to all forcing files, so I do not understand the error with temperature.

basin_temperature.zip

I remember learning from Dan that the 4D variable issue was resolved but I could not find a confirmation.

[dprincz]

Hi Mohamed, Can you try reading the unmodified 4D file, since it doesn't have issue reading the other unmodified files?

[mee067]

I tried. It gave the same result, unfortunately. I am using MESH 1.5.7 btw.

…

________________________________ From: Daniel Princz (Dan) ***@***.***> Sent: Monday, March 30, 2026 5:12 PM To: MESH-Model/MESH-Dev ***@***.***> Cc: Mohamed Elshamy ***@***.***>; Author ***@***.***> Subject: Re: [MESH-Model/MESH-Dev] calendar/4D error (Issue #127) You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: External to WSA. Verify sender and exercise caution opening links and attachments. [https://avatars.githubusercontent.com/u/17090685?s=20&v=4]dprincz left a comment (MESH-Model/MESH-Dev#127)<#127 (comment)> Hi Mohamed, Can you try reading the unmodified 4D file, since it doesn't have issue reading the other unmodified files? — Reply to this email directly, view it on GitHub<#127?email_source=notifications&email_token=AKMDLVRTNPJV6YLZNUPUCPD4TL5MJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJVHA3TCNJWHA22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4158715685>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKMDLVULKXEU6GJJSOWPJGT4TL5MJAVCNFSM6AAAAACXG4TRZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNJYG4YTKNRYGU>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[dprincz]

It's interpreting the variable t as time (i.e., akin to lat as y, etc..). You'll need to rename the data variable to something else.

Not related to this, you might not need to remove the fourth dimension if the size of that dimension is 1.

Is that the name of the variable from the grib2 file now? Usually they might use something like ta or tas. I'm not sure t is a common name by the usual standards, so let me know if that's the case so I can mention it to the Datamart/GeoMet people.

[mee067]

yes, RDPS variable names in Grib files are not standard by any means. for example, shortwave and longwave radiation are called ssrd and strd ... Not FB and FI as in CaSR nor rsds and rlds as in CanRCM. same for all variables. Maybe this needs to be relayed to the producers! I have not checked what they say in the documentation. This info is extracted directly from the downloads.

[dprincz]

I'm pretty sure the documentation for the grib2 files will still say it's called TMP... I find it's not up-to-date, especially since the variables were renamed to use descriptive names more recently (you probably saw this in the polar stereographic versus rotated lat/lon files and filenames). I'll relay the information, though I'm not sure if anything will come of it.

Time, in particular, is a special field. However, you might also run into this problem with variables named the same as common coordinates x, y and t, when they don't represent x-space/longitude, y-space/latitude or time, respectively.

I don't think you should hit problems with other dimension names.

[mee067]

they put the "short-name" and long-name attributes for most variables but the variable names themselves are not standard. even Z-dimension (usually level) is called height - so things like cdo sellevel,... did not work.

[mee067]

I have a related question to the data processing which I may have asked before (forgive my memory): CaPA is 6-hourly accumulation. I guess the 6Z is accumulation from 00:01 to 06:00 and so on. I mean it is registered at the end of the time step.

Although hourly, RDPS is for precip and radiation are accumulated in the same manner, I suppose.