negative longitude in domain file gives incorrect time offset

[swensosc]

Using domain file and surface data file in CLM5 in which both used negative longitudes (i.e. -180 to 180), the model ran without problem, but the history was incorrect. Specifically, it looks like the time offset isn't correct, such that solar forcing doesn't occur at the right time relative to local noon, and much of it is reflected b/c the model thinks that it is night. It seems like either datm should be able to handle this or it should exit w/ an error suggesting that the domain be corrected. Instead, it gives bad results but completes successfully.

[jedwards4b]

@swensosc please provide a description adequate to reproduce the problem.

[swensosc]

It requires a domain file (and surface data file) with negative longitudes. I've created some here:
/glade/scratch/swensosc/sfcdata/surfdata_0.9x1.25_78pfts_CMIP6_simyr1850_c170824.negative.longitude.nc
/glade/scratch/swensosc/sfcdata/domain.lnd.fv0.9x1.25_gx1v6.090309.negative.longitude.nc
An out of the box f09_g16 clm I case run for 1 month would show the affect.

[jedwards4b]

@ekluzek I did the following test: SMS_Ld1.f19_g17.I2000Clm50BgcCruGs.cheyenne_intel.clm-default and compared to the cesm2.0.1-beta baseline. I then replaced the ATM_DOMAIN_FILE with a file which specifies lat from -180 to 180. I got an immediate runtime error "(seq_domain_check_grid) ERROR: incompatible domain grid coordinates". I think that this issue is a ctsm and not a cime problem.

[jedwards4b]

If I also replace both the LND_DOMAIN_FILE and the clm fsurdat file I do reproduce the original problem.

[mvertens]

@jedwards4b - does this point to a data model problem?

…

On Mon, Aug 27, 2018 at 2:48 PM jedwards4b ***@***.***> wrote: If I also replace both the LND_DOMAIN_FILE and the clm fsurdat file I do reproduce the original problem. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2778 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlxE4Q4Kj3s1G3fLBXqnHjDqwrllyH0ks5uVFsZgaJpZM4WL9oz> .

[jedwards4b]

So the problem seems to be that if the longitudes are specified consistently but from -180 to 180 instead of from 0 to 360 then the computation for local noon is incorrect - but I think that the computation for local noon happens in ctsm - @ekluzek ?

[ekluzek]

@jedwards4b there is a computation for local noon that would just apply to ctsm. But, the original description is that solar is handled incorrectly so that the solar data read in by datm doesn't align with the models solar cycle. That's because the solar is using a solar zenith angle scaling mechanism that's part of cime/datm, and the forcing data for solar is 0 to 360. I think we either need a mechanism to say -- this file isn't 0-360 so we need to die. Or a mechanism in datm that handles the solar zenith angle scaling to say -- the model and data is so far out of whack in terms of night and day that it means something is wrong. Or both. I'll add a note on this to ctsm for it's calculation of local noon. I think the only thing that's wrong in cime/datm is the solar zenith angle scaling. It sounds like everything else is working as long as you have consistent domain and mapping files. And it would probably work if the solar forcing data was on a -180-180 grid the same as the domain file. I don't think we can easily check that (that domain and forcing data are on the same grid type for longitude), so it seems the best route is to just check that it's on 0-360 and die if it isn't.

[ekluzek]

In reviewing code in cime, I do see some code in place that allows either form to exist. shr_orb has a check that changes longitude (in order to calculate local time) to be between -pi and pi for example. seq_domain_mct has something similar as well. shr_map_mapSet_dest also has such a shift. Some grids in cesm are on -180-180 (cism greenland grids, and mosart for example).

So I'm going to verify that the solar is screwed up for a grid where the forcing is 0-360 and the domain is -180-180.

[ekluzek]

OK, I did more testing and had output every time step. The pattern for solar looks correct, and matches within roundoff of a case with non-negative longitudes. So I think cime is correct and there are just issues with ctsm. So closing for now...

[mvertens]

@erik Kluzek <erik@ucar.edu> thanks so much for your careful work on this.

…

On Sat, Sep 1, 2018 at 5:14 PM Erik Kluzek ***@***.***> wrote: OK, I did more testing and had output every time step. The pattern for solar looks correct, and matches within roundoff of a case with non-negative longitudes. So I think cime is correct and there are just issues with ctsm. So closing for now... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2778 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlxE3SswqD9NG8IDj61Jhr03n8iau_Oks5uWxS_gaJpZM4WL9oz> .

[jedwards4b]

@ekluzek Thank you for confirming.