handle to regrid gwd file as well

[rtodling]

Regrid needs to handle GWD internal file as well.

[github-actions]

This PR is being prevented from merging because you have not added one of our required labels: 0 diff, 0 diff trivial, Non 0-diff, 0 diff structural, 0-diff trivial, Not 0-diff, 0-diff, automatic, 0-diff uncoupled. Please add one so that the PR can be merged.

[github-actions]

This PR is being prevented from merging because you have not added one of our required labels: 0 diff, 0 diff trivial, Non 0-diff, 0 diff structural, 0-diff trivial, Not 0-diff, 0-diff, automatic, 0-diff uncoupled. Please add one so that the PR can be merged.

[mathomp4]

Hmm. Interesting. I'm not sure we want to do this. I mean, we can, but we might not need to.

I'm pinging @bena-nasa and @wmputman.

At the moment, the gwd_internal_rst files I believe are "fixed" in that they never change. They are the GWD_RIDGE files that Julio made for @wmputman. Recently, @bena-nasa has been looking at the TOPO routines that make them and hopefully soon we can generate them.

Indeed, in gcm_run.j at least, it does not matter even if a user has a different gwd_internal_rst file, we replace it:

  /bin/rm gwd_internal_rst
  /bin/cp @GWDRSDIR/gwd_internal_c${AGCM_IM} gwd_internal_rst

[rtodling]

Hmm. Interesting. I'm not sure we want to do this. I mean, we can, but we might not need to.

I'm pinging @bena-nasa and @wmputman.

At the moment, the gwd_internal_rst files I believe are "fixed" in that they never change. They are the GWD_RIDGE files that Julio made for @wmputman. Recently, @bena-nasa has been looking at the TOPO routines that make them and hopefully soon we can generate them.

Indeed, in gcm_run.j at least, it does not matter even if a user has a different gwd_internal_rst file, we replace it:

  /bin/rm gwd_internal_rst
  /bin/cp @GWDRSDIR/gwd_internal_c${AGCM_IM} gwd_internal_rst

Oddly enough, my changes break the regrid.pl program ... that is, I end up not getting the upper internal files ... something is failing in gwd_internal ... The problem is that having to refer back to the fixed file that Bill has is a tremendous inconvenience to the user ... the point is that w/o a regrid of gwd, every time someone uses regrid from DAS rat tar balls they end up w/ an incomplete set of files to start a run ... why isn't regrid working on the gwd file ... I thought there were just trivial cubed nc4 files just like most of the other rsts, no?

[rtodling]

Hum ... I see why it doesn't work ... the gwd files are not 3d files they are 2d ...

[rtodling]

There is another problem w/ regrid.pl which is no longer working as a full command line, for example:

Running like this:

#!/usr/bin/csh
#===============================================================================

The following command was used to create the C90CS_x50R13rt.20230726_21z restarts

#===============================================================================
setenv REGRIDBIN /gpfsm/dnb05/projects/p61/rtodling/4OPS/g540x/GEOSadas/install-SLES12/bin
$REGRIDBIN/regrid.pl -qos advda -ymd 20230726 -hr 21 -grout C90 -levsout 72 -outdir New -d /gpfsm/dnb05/projects/p139/rtodling/archive/540/x50R13rt/rs/Y2023/M07 -expid x50R13rt -tagin GEOSadas-5_29_4 -oceanin CS -ocnmdlin data -tagout Icarus-NLv3 -rs 3 -oceanout CS -ocnmdlout data -wemin 13 -wemout 13 -np

used to work - but it now fails.

I know what the issue here is: the echoed command line does no include the grpID ... for example:

-grpID g0613

Once that's added all works.

[mathomp4]

@rtodling Yeah, it's possible that regrid.pl has started to atrophy. Once the command line version of remap_restarts.py was added, that was the death knell of regrid.pl for me.

There is one inconsistency with remap_restarts.py that @sshakoor1 is looking into, but it does work.

And, of course, regrid.pl will never support things like the v12 land bcs, etc.

[rtodling]

@rtodling Yeah, it's possible that regrid.pl has started to atrophy. Once the command line version of remap_restarts.py was added, that was the death knell of regrid.pl for me.

There is one inconsistency with remap_restarts.py that @sshakoor1 is looking into, but it does work.

And, of course, regrid.pl will never support things like the v12 land bcs, etc.

I can see the handling of gwd_internal is not clean as it stands now --- but I also think because regrid.x can handle a file that is not 3d that this is going to turn into some work ... I will close this PR, but I will open an issue to remind us that gwd_internal needs to be handled in the new regrid program associated w/ v12 ... is that's already done there, then please let me know and I will not open the issue.

[mathomp4]

@rtodling Well, my main thought is that there is no handling of gwd_internal_rst. It is just simply copied from a fixed file into the experiment. I don't even think there is date-dependence. We have a suite of files from c12 to ... high-res (c1440?), and what we do is just copy them in.

It's possible we might have new ones for GEOSgcm v12, but even then, I think the answer will be to just copy a new file in.

[bena-nasa]

@rtodling the gwd_internal_rst file is for all purposes a boundary condition file; it simply need to the copied into the experiment from the place we keep them. The file contains the orography ridge data for certain gravity wave drag schemes and should not be regridded by regrid.pl or remap_restarts.py