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.

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

need to support nctiles variant used in ECCO v4 r4 #9

Open
gaelforget opened this issue Sep 26, 2019 · 5 comments
Open

need to support nctiles variant used in ECCO v4 r4 #9

gaelforget opened this issue Sep 26, 2019 · 5 comments

Comments

@gaelforget
Copy link
Member

For ECCO v4 r4, a slightly different version of nctiles was used, which is not yet supported by gcmfaces read_nctiles.m.

New format looks like this:

	float UVELMASS(time, k, tile, j, i_g) ;
		UVELMASS:units = "m/s" ;
		UVELMASS:long_name = "X-Comp of Geometry-Weighted Velocity (m/s)" ;
		UVELMASS:coordinates = "timestep Z" ;

@owang1 , do you think that read_nctiles.m could easily be modified to support both the newer and older nctiles files?

@gaelforget
Copy link
Member Author

gaelforget commented Dec 17, 2019

Hi @owang1

Thanks for https://github.com/gaelforget/gcmfaces/pull/10 which I just merged.

When I tried the now-merged version with v4r4 output (3 years of oceQnet) I got an error.

Maybe something like the patch below is needed?

@@ -193,11 +193,12 @@
   else;
     t0 = 1;
     t1 = lff;
+    nt=t1-t0+1;
   end;
   for fft=t0:t1;

     %read one tile
-    fileIn=flist{fft+1};
+    fileIn=flist{fft};

(But maybe I am missing something obvious)

@gaelforget
Copy link
Member Author

Hi @owang01

Could you please confirm that we are all set with changes needed to handled the latest ECCOv4r4 output from https://ecco.jpl.nasa.gov/drive/files/Version4/Release4/ ?

Specifically can you please make sure that :

All of the above need to be true for ECCO users' experience to be smooth when they go back and forth between ECCOv4r2 to ECCOv4r4 imho. We know that at least one user has already experienced disruptions to their workflow in relation to the format change ( see http://mailman.mit.edu/pipermail/ecco-support/2020-May/000415.html ). What I am particularly concerned with are users that might not report their frustration and instead just switch to using something else than ECCO I guess.

@gaelforget
Copy link
Member Author

@gaelforget
Copy link
Member Author

gaelforget commented May 12, 2020

Hi @hongandyan

Thanks for your post @ http://mailman.mit.edu/pipermail/ecco-support/2020-May/000424.html which included this suggestion for modifying gcmfaces :

"read_nctiles.m" needs two minor fixes
1) https://github.com/MITgcm/gcmfaces/blob/master/gcmfaces_IO/read_nctiles.m#L64
basedir = './'; ==> basedir = '.';
2) https://github.com/MITgcm/gcmfaces/blob/master/gcmfaces_IO/read_nctiles.m#L190
    t0=tt(1)-1; ==>     t0=tt(1);

While I dont have a sense whether that's the right approach, and might not have time to think about this more in the near future, I repost your suggestion from the other public forum to this thread so we dont lose track of your suggestion.

@owang01
Copy link
Contributor

owang01 commented May 13, 2020

Just copy the post about the updated read_nctiles.m @ ECCO-GROUP/ECCO-v4-Configurations#48. The updated read_nctiles.m should perform similarly when reading either V4r3 or V4r4 files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants