ngs333
commented
10 months ago Note that if MAXXGRID is increased significantly for fregrid serial, then the run times may be exceedingly high and therefore end user time may be wasted. It may also be beneficial to estimate and display the expected run time to the user, and possibly even recommend to the user to use fregrid_parallel (at least for weights generation). Note the information in https://github.com/NOAA-GFDL/FRE-NCtools/issues/202 may be helpful for this.
The current default value for MAXXGRID is 1e6. This precludes the running of serail fregrid under some circumstances (when a weights file is not already available) for the size of grids used today at GFDL. Since fregrid_parallel is available for extreme regridding, in has in the past been the goto solution when regridding with large grids. But one problem with fregrid_parallel is that sometimes time or manpower is required to get it to run successfully, and the frequency of this is increasing as the lab moves to larger grids. A related problem is that this issue may be the only reason to move or copy some files from Analysis, workstations, or home computers onto Gaea visible filesystems.
This feature request is for MAXXGRID to be increased for fregrid, but not necessarily for fregrid_parallel or any of the other of the NCTools tools. MAXXGRID is set to a low 1e6 probably because fregrid_parallel is run on many-core supercomputer nodes, and so the memory used per node may be large when the core count per node is high. But even if that is true, it probably can be increased somewhat for fregrid_parallel. In any case it can probably be increased for the fregrid tool by itself despite the common code.
The problems with this request are: a) Short of a clever solution, fregrid may be required to be built by itself e.g. to allow for a re-definition of MAXXGRID. b) Any changes require extensive testing, particularly If MAXXGRID is changed for fregrid_parallel. c) If the new C++ optimal fregrid becomes part of the baseline, then the issue is mute.