single_column logic in buildnml is incorrect

[billsacks]

I noticed that the test SMS_Ln9_P1.T42_T42.2000_DATM%QIA_SLND_SICE_DOCN%DOM_SROF_SGLC_SWAV.derecho_intel.datm-scam is incorrectly (I think) keeping ATM_NX and ATM_NY set to their global (full domain) values rather than setting them to 1. I noticed this in implementing a fix for #418. Prior to that, it's possible that the incorrect settings of ATM_NX and ATM_NY didn't cause any critical issues - though it looks like they lead to variable sizes being incorrect on cpl history and restart files (dimensioned by the global size rather than size 1), and there may be other problems, too.

I think the cause of this issue is the logic for determining single_column here:

CDEPS/datm/cime_config/buildnml

Lines 168 to 180 in f13cffb

	if case.get_value('PTS_LON'):
	scol_lon = float(case.get_value('PTS_LON'))
	else:
	scol_lon = -999.
	if case.get_value('PTS_LAT'):
	scol_lat = float(case.get_value('PTS_LAT'))
	else:
	scol_lat = -999.
	if case.get_value('ATM_DOMAIN_FILE'):
	if scol_lon > -999. and scol_lat > -999. and case.get_value("ATM_DOMAIN_FILE") != "UNSET":
	config['single_column'] = 'true'
	else:
	config['single_column'] = 'false'

Note that there is similar logic in some other data components' buildnml files.

Specifically: there is no ATM_DOMAIN_FILE variable. Based on ESCOMP/CMEPS#164, I have a feeling this is supposed to refer to PTS_DOMAINFILE, but I'm not sure about this. @mvertens agrees that it looks like this is an issue.

I don't have enough familiarity with the subtleties of single-column mode to know what's right here, so I'm hoping that someone with more familiarity can look at this. This should include:

• Checking whether single-column mode is currently working correctly despite this issue
• Coming up with a fix that correctly determines single_column mode and differentiates it from a single point run (see notes in new CESM single/column single/point functionality CMEPS#164)
• Confirming that the fixed code works correctly

[billsacks]

See also ESCOMP/CMEPS#676

[billsacks]

Once this issue is resolved I think we can revert the changes in billsacks@3d76601