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

[Gerhard Theurich]

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
>
>