[Ncep.list.nems.announce] trying to understand a recent NEMS commit...

[Gerhard Theurich]

Hi,

Picking up this conversation again on email. We talked about it this 
morning on the UMIG/NEMS call. My concrete proposal (for NOW) is to 
_not_ start separating out ESMF versions beyond 5.2.0r in NEMS. We do 
still need the big switch between 310r-series and 520rAPI compatible, 
until the issue with GOCART is resolved, but even now I do not see a 
need to have switches between 5.2.0rAPI compatible ESMF versions in NEMS.

As it stands currently, this is what the "esmf_version" script in NEMS 
offers:

      Run ./esmf_version with one argument:

  'esmf_version 3_wcoss'            : ESMF 3.1.0rp2 library on wcoss
  'esmf_version 3_zeus'             : ESMF 3.1.0r series library (i.e. 
ESMF 3.1.0rp2, 3.1.0rp5) on zeus
  'esmf_version 3_yellowstone'      : ESMF 3.1.0rp2 library on yellowstone

  'esmf_version 5.2_wcoss'          : ESMF 5.2.0rp1 library on wcoss
  'esmf_version 6.3r_wcoss'         : ESMF 6,3.0r library on wcoss
  'esmf_version 5.2.0rAPI_zeus'     : ESMF 5.2.0r API compatible library 
(i.e. ESMF >= 5.2.0r) on zeus
  'esmf_version nuopc_zeus'         : ESMF library with reference NUOPC 
Layer (currently ESMF 6.2.0) on zeus

I am proposing to clean this up this way:

      Run ./esmf_version with one argument:

  'esmf_version 3.1.0rAPI_wcoss'    : ESMF 3.1.0r API compatible library 
on wcoss (currently 3.1.0rp2)
  'esmf_version 3.1.0rAPI_zeus'     : ESMF 3.1.0r API compatible library 
on zeus (currently ESMF 3.1.0rp5)
  'esmf_version 3.1.0r_yellowstone' : ESMF 3.1.0r API compatible library 
on yellowstone (currently ESMF 3.1.0rp5)

  'esmf_version 5.2.0rAPI_wcoss'    : ESMF 5.2.0r API compatible library 
on wcoss (currently ESMF 6.3.0r)
  'esmf_version 5.2.0rAPI_zeus'     : ESMF 5.2.0r API compatible library 
on zeus (currently ESMF 6.3.0r)

  'esmf_version nuopc_zeus'         : ESMF with reference NUOPC Layer on 
zeus (currently ESMF 7.0.0bs01)

With that, any future release of ESMF can be tested by simply changing 
which ESMF library is pointed to by the 
modules.nems.Machine_ESMF_520rAPI file (Machine=Wcoss|Zeus|Yellowstone). 
Once testing is clean, and the decision was made to move to that ESMF 
version, the change is committed, including changing the comment in the 
"esmf_version" script, indicating which specific ESMF version is loaded 
under the 5.2.0rAPI setting for the specific machine.

Along the same line I suggest _not_ splitting regression testing like 
this (which is now in the regression script):

  SKIP_ESMF520rAPI=YES
  SKIP_ESMF630rAPI=NO

but instead only have one set of regression tests for ESMF520rAPI, which 
then loads what every 5.2.0rAPI compatible ESMF library was set in the 
machine specific configuration file.

Bottom line is that I would like us to reign in the number of options 
wrt ESMF version and not add to them, specifically beyond the 5.2.0rAPI.

Thanks,
-Gerhard



On 02/28/2014 01:45 PM, Gerhard Theurich wrote:
> Hi Weiyu,
>
> Thanks for the explanation, this information helps to understand. I will
> take another look and hope to respond with a more concrete proposal wrt
> ESMF 6.3.0r in NEMS soon.
>
> Have a great weekend, too!
>
> -Gerhard
>
> On 02/28/2014 01:37 PM, Weiyu Yang - NOAA Affiliate wrote:
>> Hi, Gerhard,
>>
>> By the way,  My change for using the ESMF 6.3.0r library only apply to
>> wcoss machine.  No influence on the ZEUS machine.  Thus for your ZEUS
>> NUOPC work you may still work as before, I think no difference.
>>
>> One more thing, I do not put something special in the fortran code for
>> ESMF 6.3.0r, everything is exactly as before, i.e., using the lines
>> special for the ESMF 5.2.0rpX to run the ESMF 6.3.0r.  The only change,
>> add 6.3.0r .h file to point to the ESMF 6.3.0r library I installed on
>> wcoss machine, add two 6.3.0r regression tests for nmm and GSM, for the
>> full wcoss test run.  By the way, the regression tests for ESMF 5.2.0X
>> already skipped (stopped) for a long long time, as mean while the NEMS
>> committed again and again lots of times, right now the tests
>> broken, cannot to run anymore.
>>
>> Have a great weekend.
>> Best regards
>> Weiyu
>>
>>
>>
>>
>> On Thu, Feb 27, 2014 at 7:47 PM, Gerhard Theurich
>> <theurich at sourcespring.net <mailto:theurich at sourcespring.net>> wrote:
>>
>>      Hi,
>>
>>      I am a bit puzzled how I missed the commit announcement to the NEMS
>>      trunk that went in 19h ago as revision 37397. There are two issues:
>>
>>      1) It's hard to merge to the trunk when there are changes coming like
>>      that are not being announced. Yesterday I had merged branches/NUOPC
>>      changes to a trunk sandbox, resolved issues and started testing. I will
>>      repeat now...
>>
>>      2) The changes in question, updating to ESMF v6.3.0r in NEMS, I would
>>      have advised to approach the issue differently. Starting with v5.2.0r,
>>      ESMF guarantees a large degree of backward compatibility of the API. The
>>      idea behind added the "520rAPI" setting in NEMS was to use it on all
>>      520rAPI compatible ESMF releases, which should be pretty much any future
>>      release. The same internal macros would be used in NEMS, and eventually,
>>      when the use of prior ESMF versions (like v3.1.0rpX) dies out in NEMS,
>>      all of that ESMF version specific macro jungle could be cut down. I
>>      think we should revisit the changes.
>>
>>      Thanks,
>>      -Gerhard
>>      _______________________________________________
>>      Ncep.list.nems.announce mailing list
>>      Ncep.list.nems.announce at lstsrv.ncep.noaa.gov
>>      <mailto:Ncep.list.nems.announce at lstsrv.ncep.noaa.gov>
>>      https://lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce
>>
>>
> _______________________________________________
> Ncep.list.nems.announce mailing list
> Ncep.list.nems.announce at lstsrv.ncep.noaa.gov
> https://lstsrv.ncep.noaa.gov/mailman/listinfo/ncep.list.nems.announce
>