default finidat_interp_dest file name should have instance number

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2016-02-26 10:49:37 -0700
Bugzilla Id: 2289
Bugzilla CC: andre@ucar.edu, fischer@ucar.edu, jedwards@ucar.edu, mvertens@ucar.edu, raeder@ucar.edu, rfisher@ucar.edu,

Kevin Raeder pointed out that the default file name for finidat_interp_dest ('finidat_interp_dest.nc') leads init_interp to stomp on itself when using use_init_interp with multi-instance. We should change the default to have the instance number in the file name.

In the meantime, the workaround is to explicitly specify finidat_interp_dest in each instance's user_nl_clm.

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2017-06-05 21:07:40 -0600

One possible solution would be to give build-namelist knowledge of the instance index.

This is similar to what's done for CISM - and specifically what I'm working on right now to get multi-instance branch / hybrid runs to work right. For CISM, buildnml passes the inst_string to build-namelist as a command-line argument; then this inst_string can be used to construct file names. We could do something similar for CLM.

(Note that finidat_interp_dest is not currently invoked by CLM's build-namelist, so we just use the hard-coded default unless the user explicitly specifies it. The above solution would require putting finidat_interp_dest in the lnd_in file, which is probably a good thing anyway.)

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2017-10-17 16:10:31 -0600

Changing this to P1 because I think it's important to resolve this for the release.

[billsacks]

Fixing this will hopefully resolve #60

[ekluzek]

Turns out sending inst_string down through the namelist isn't the right way to do this. clm already has this same thing as "inst_suffix". So there's no reason to pass a new namelist item down. I also ran into the problem of needing to have inst_string set in a namelist prior to finidat_interp_dest. So it's cleaner to use inst_suffix.

[timhoar]

I am using the branches/usedataassim ... are there any sourcemods I can use to test where this is at the moment? I am a bit confused on what I can do (right now) to run. As a side note - it seems that if I use netcdf instead of pnetcdf - the single file seems useful to all 80 of my instances - however, I'm spending more than I need to for I/O. (I don't know how much more, mind you.)

[jedwards4b]

I need to bump this issue - it really needs to be addressed and shouldn't be too difficult should it?

[billsacks]

I believe @ekluzek has this on a branch that should come to master within the next few days

[ekluzek]

Yes, that's correct. I will either have it done by tomorrow, or let both of you know I didn't.

[timhoar]

I updated to the escomp/master on Wednesday 23 May and got:
commit e739c2c
Merge: 70cbfaa 6368814
Author: Bill Sacks sacks@ucar.edu
Date: Thu May 17 14:14:14 2018 -0600

Which still seems to have the instance missing from the finidat_interp_dest filename.

[ekluzek]

@timhoar, hmmm. It looks like that version should have the correct code in there. The only way I see around it is if you are overriding the finidat_interp_dest filename in your namelist. Or there has to be something screwed up in the instance numbering. Can you point me to your case?

[timhoar]

Sorry ... should have included that in the first msg:

/glade/p/work/thoar/cases/ctsm/clm5_f09_spinup80

[timhoar]

Arghhh! upon further inspection ... it is not the interpolation files, but the actual input files (somehow!)
Please disregard. (but stay tuned for the next issue!)

[ekluzek]

Yeah, it does look like there are files with instance names, but not all of them are covered. I think this might relate to #389, and the use of MULTI_DRIVER.

finidat_interp_dest_0008.nc finidat_interp_dest_0020.nc finidat_interp_dest_0039.nc finidat_interp_dest_0053.nc finidat_interp_dest_0068.nc finidat_interp_dest_0077.nc
finidat_interp_dest_0018.nc finidat_interp_dest_0025.nc finidat_interp_dest_0046.nc finidat_interp_dest_0061.nc finidat_interp_dest_0071.nc finidat_interp_dest_0078.nc
finidat_interp_dest_0019.nc finidat_interp_dest_0037.nc finidat_interp_dest_0049.nc finidat_interp_dest_0065.nc finidat_interp_dest_0075.nc finidat_interp_dest_0079.nc

[timhoar]

So ... in addition to that ... the lnd_in files are wrong in that the 'finidat' files do not have an instance number in them. I wonder if some of the interpolations did not finish before the (incorrect) 'missing' finidat files started throwing errors. more gas on the fire ... sorry. Tim Hoar Data Assimilation Research Section National Center for Atmospheric Research thoar@ucar.edu 303.497.1708

…

On Fri, May 25, 2018 at 11:36 AM, Erik Kluzek ***@***.***> wrote: Yeah, it does look like there are files with instance names, but not all of them are covered. I think this might relate to #389 <#389>, and the use of MULTI_DRIVER. finidat_interp_dest_0008.nc finidat_interp_dest_0020.nc finidat_interp_dest_0039.nc finidat_interp_dest_0053.nc finidat_interp_dest_0068.nc finidat_interp_dest_0077.nc finidat_interp_dest_0018.nc finidat_interp_dest_0025.nc finidat_interp_dest_0046.nc finidat_interp_dest_0061.nc finidat_interp_dest_0071.nc finidat_interp_dest_0078.nc finidat_interp_dest_0019.nc finidat_interp_dest_0037.nc finidat_interp_dest_0049.nc finidat_interp_dest_0065.nc finidat_interp_dest_0075.nc finidat_interp_dest_0079.nc — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOccOgl_Pmxxcyi-8ZkMO5zzxL2ikC7-ks5t2EEKgaJpZM4REcdr> .