Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FATES output time mismatch with metadata #1939

Open
serbinsh opened this issue May 18, 2018 · 4 comments
Open

FATES output time mismatch with metadata #1939

serbinsh opened this issue May 18, 2018 · 4 comments
Labels
Status: Stale

Comments

@serbinsh
Copy link
Member

Describe the bug
Presently in the FATES pecan standard output we define the time variable as something like:

double time(time) ;
		time:units = "days since 1995-01-01 00:00:00" ;
		time:long_name = "time" ;
		time:calendar = "standard" ;

However the time variable data we use from FATES output actually counts up continuously from the start year, e.g. :

[sserbin@modex SA-median]$ ncdump -h case.clm2.h0.1995-01-01-00000.nc | grep time
	time = UNLIMITED ; // (8760 currently)
	float time(time) ;
		time:long_name = "time" ;
		time:units = "days since 1995-01-01 00:00:00" ;
		time:calendar = "noleap" ;
		time:bounds = "time_bounds" ;
	int mcdate(time) ;
	int mcsec(time) ;
	int mdcur(time) ;
	int mscur(time) ;
	int nstep(time) ;
		nstep:long_name = "time step" ;

[sserbin@modex SA-median]$ ncdump -h case.clm2.h0.1996-01-01-00000.nc | grep time
	time = UNLIMITED ; // (8760 currently)
	float time(time) ;
		time:long_name = "time" ;
		time:units = "days since 1995-01-01 00:00:00" ;
		time:calendar = "noleap" ;
		time:bounds = "time_bounds" ;
	int mcdate(time) ;
	int mcsec(time) ;
	int mdcur(time) ;
	int mscur(time) ;
	int nstep(time) ;
		nstep:long_name = "time step" ;

As such our PEcAn nc metadata does not match the FATES output. We either need to 1) replace the time since part and instead set it the same as FATES such that each successive year has "days since" of the start year OR 2) stop using nc.time <- ncin$dim$time$vals # days since "start_date" or modify such that each year correctly has days since that year

To Reproduce
Steps to reproduce the behavior:
Run PEcAn-FATES

Expected behavior
We should have consistency between the time variable definition and the time data

Screenshots
NA

Machine (please complete the following information):

  • Server [e.g. BU, NCSA, VM, etc.]
    modex but would apply to all

  • OS: [e.g.Linux]
    Linux but applies to all

  • Browser(if applicable) [e.g. chrome, safari]
    NA

  • Version [e.g. 22]
    develop
@serbinsh
Copy link
Member Author

serbinsh commented May 18, 2018 •
edited
Loading

You can see here what I mean. The current time var we use increases linearly rather than restarts each new simulation year.

[sserbin@modex SA-median]$ ncdump -v time case.clm2.h0.1996-01-01-00000.nc
...
    718.7083, 718.75, 718.7917, 718.8333, 718.875, 718.9167, 718.9583, 719,
    719.0417, 719.0833, 719.125, 719.1667, 719.2083, 719.25, 719.2917,
    719.3333, 719.375, 719.4167, 719.4583, 719.5, 719.5417, 719.5833,
    719.625, 719.6667, 719.7083, 719.75, 719.7917, 719.8333, 719.875,
    719.9167, 719.9583, 720, 720.0417, 720.0833, 720.125, 720.1667, 720.2083,
    720.25, 720.2917, 720.3333, 720.375, 720.4167, 720.4583, 720.5, 720.5417,
    720.5833, 720.625, 720.6667, 720.7083, 720.75, 720.7917, 720.8333,
    720.875, 720.9167, 720.9583, 721, 721.0417, 721.0833, 721.125, 721.1667,
    721.2083, 721.25, 721.2917, 721.3333, 721.375, 721.4167, 721.4583, 721.5,
    721.5417, 721.5833, 721.625, 721.6667, 721.7083, 721.75, 721.7917,
    721.8333, 721.875, 721.9167, 721.9583, 722, 722.0417, 722.0833, 722.125,
    722.1667, 722.2083, 722.25, 722.2917, 722.3333, 722.375, 722.4167,
    722.4583, 722.5, 722.5417, 722.5833, 722.625, 722.6667, 722.7083, 722.75,
    722.7917, 722.8333, 722.875, 722.9167, 722.9583, 723, 723.0417, 723.0833,
    723.125, 723.1667, 723.2083, 723.25, 723.2917, 723.3333, 723.375,
    723.4167, 723.4583, 723.5, 723.5417, 723.5833, 723.625, 723.6667,
    723.7083, 723.75, 723.7917, 723.8333, 723.875, 723.9167, 723.9583, 724,
    724.0417, 724.0833, 724.125, 724.1667, 724.2083, 724.25, 724.2917,
    724.3333, 724.375, 724.4167, 724.4583, 724.5, 724.5417, 724.5833,
    724.625, 724.6667, 724.7083, 724.75, 724.7917, 724.8333, 724.875,
    724.9167, 724.9583, 725, 725.0417, 725.0833, 725.125, 725.1667, 725.2083,
    725.25, 725.2917, 725.3333, 725.375, 725.4167, 725.4583, 725.5, 725.5417,
    725.5833, 725.625, 725.6667, 725.7083, 725.75, 725.7917, 725.8333,
    725.875, 725.9167, 725.9583, 726, 726.0417, 726.0833, 726.125, 726.1667,
    726.2083, 726.25, 726.2917, 726.3333, 726.375, 726.4167, 726.4583, 726.5,
    726.5417, 726.5833, 726.625, 726.6667, 726.7083, 726.75, 726.7917,
    726.8333, 726.875, 726.9167, 726.9583, 727, 727.0417, 727.0833, 727.125,
    727.1667, 727.2083, 727.25, 727.2917, 727.3333, 727.375, 727.4167,
    727.4583, 727.5, 727.5417, 727.5833, 727.625, 727.6667, 727.7083, 727.75,
    727.7917, 727.8333, 727.875, 727.9167, 727.9583, 728, 728.0417, 728.0833,
    728.125, 728.1667, 728.2083, 728.25, 728.2917, 728.3333, 728.375,
    728.4167, 728.4583, 728.5, 728.5417, 728.5833, 728.625, 728.6667,
    728.7083, 728.75, 728.7917, 728.8333, 728.875, 728.9167, 728.9583, 729,
    729.0417, 729.0833, 729.125, 729.1667, 729.2083, 729.25, 729.2917,
    729.3333, 729.375, 729.4167, 729.4583, 729.5, 729.5417, 729.5833,
    729.625, 729.6667, 729.7083, 729.75, 729.7917, 729.8333, 729.875,
    729.9167, 729.9583 ;

But in the PEcAn output we are defining as:

	double time(time) ;
		time:units = "days since 1996-01-01 00:00:00" ;
		time:long_name = "time" ;
		time:calendar = "standard" ;

@serbinsh
Copy link
Member Author

serbinsh commented May 18, 2018 •
edited
Loading

And as reminded by @infotroph

@serbinsh guessing you noticed this already, but since you didn’t mention it explicitly: You noticed that your examples in #1939 show a calendar mismatch (“standard” vs “noleap”) as well as a `days since` mismatch, yeah?

So just some general PEcAn standard output tidying up for FATES. Since FATES is no leap we need to set PEcAn output to noleap.

@infotroph infotroph mentioned this issue May 18, 2018
Open
4 tasks
serbinsh pushed a commit to serbinsh/pecan that referenced this issue May 31, 2018
Updated FATES output time variable to fix issue PecanProject#1939. Cu…
f51ef6e 
…rrent fix is to keep the same time time_since from the first year of the run (CLM default). However we could change this so it resets for each year if that is preferred
serbinsh pushed a commit that referenced this issue Jun 1, 2018
Merge pull request #1953 from serbinsh/fix_fates_output_dates
65b3809 
Updated FATES output time variable to fix issue #1939.
araiho pushed a commit to araiho/pecan that referenced this issue Jul 26, 2018
Updated FATES output time variable to fix issue PecanProject#1939. Cu…
4f8fc5c 
…rrent fix is to keep the same time time_since from the first year of the run (CLM default). However we could change this so it resets for each year if that is preferred
araiho pushed a commit to araiho/pecan that referenced this issue Jul 26, 2018
Merge pull request PecanProject#1953 from serbinsh/fix_fates_output_d…
dae7134 
…ates

Updated FATES output time variable to fix issue PecanProject#1939.
@robkooper robkooper mentioned this issue Oct 2, 2018
Merged
@github-actions
Copy link

This issue is stale because it has been open 365 days with no activity.

@infotroph
Copy link
Member

@serbinsh is this still reproducible with the current code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Status: Stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@infotroph @serbinsh