lots of duplicated code in mksurfdata_map

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2013-02-27 11:37:02 -0700
Bugzilla Id: 1633
Bugzilla CC: erik@ucar.edu, mvertens@ucar.edu, rfisher@ucar.edu,

There is a lot of duplicated code in mksurfdata_map. There is duplication between files (fields that are regridded in a simple way have modules that duplicate nearly all code from other modules), as well as within certain files (e.g., mkfileMod).

This tool is due for a refactoring to remove some of this duplication.

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2013-02-28 08:58:39 -0700

I had been thinking about making something like a mkgenericMod, so we don't have to create a new module (with lots of duplicated code) for each new field. (And this could potentially have an array of derived types in its argument list so that it could create multiple fields at once if there are multiple fields on the same raw data file.)

But upon further reflection, I'm not sure this makes sense: this would make it easy to map a generic field that doesn't require any special handling, but then it would be less clear later what would need to be done if a field needs special handling (e.g., changing all missing values to a certain other value).

So instead, I think it makes sense to maintain the design of having a separate module for each raw data file. But I'll try to pull out some of this duplicated code (e.g., the error checking code) into a shared module.

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2013-03-04 16:14:09 -0700

In my branch for changes to clm4.5 mksurfdata_map, which should come to the trunk in a week or so, I have improved things somewhat, but there's still a lot to do.

The main thing I have done is to pull out the shared error-checking code and diagnostics that are printed to the .log file into shared subroutines. Also, for the new variables I'm adding, I'm reorganizing the routines in a way that makes more sense when there are multiple variables in a single raw data file.

However, I have NOT retrofitted old routines with calls to my new shared routines.

In addition, I have NOT made a common routine to do diagnostic output for an integer-valued field.

In addition, I have NOT done anything about the fact that adding a new variable requires changes in a number of different places throughout the code (and the namelist generation utilities).

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2013-06-27 11:30:29 -0600

See also the similar bug 1281

Edit: 1281 is now #80

[ekluzek]

Is this still an issue with mksurfdata_esmf on the ctsm5.2 branch?

[billsacks]

I'm not sure, but I think this issue could safely be closed - we can always reopen it or something else later if wanted.