[Ncep.list.nems.announce] global NEMS meeting Friday

John Michalakes john.michalakes at noaa.gov
Tue Aug 5 11:10:45 UTC 2014


Hi NEMS developers,

Following up on my earlier message, below, and based on our experience working with RRTMG in NEMS to date, I think we’ve begun to see real complications from the way RRTMG physics has been only nominally unified in the NEMS trunk.  I am writing to propose that GSM and NMMB versions of RRTMG be fully separated so that work can proceed in developing, testing, and integrating performance improvements on MIC and Xeon for NMMB without interfering with (or being interfered with by) ongoing development the GSM in NEMS.
 
The GSM and NMMB versions of RRTMG are significantly different, sharing only some of the swrad_main and lwrad_main sources. They still have different grrad driver routines, different model-level interfaces (module_RADIATION and module_RA_RRTM on the NMMB side; gloopr on the GSM side), and they have different versions of other processes such as aerosols and clouds.  GSM is also using a different routine, spcvrtm, in the shortwave radiation package for a stochastic version of clouds that is not used in NMMB and has no test cases within the NEMS regression suite that would allow development and testing of this part of the package.  As it stands, working with the RRTMG package in the phys directory of NEMS involves working with two packages in two models simultaneously, making it much harder to test and validate, and increases the likelihood of unintended damage to one or the other of the models from errors that fall through as a result.   
 
What I propose is to reestablish the *_nmm.f versions of the radsw_main and radlw_main source files.  I can do this when I commit my current set of proposed changes to the NMMB version of RRTMG.  We could then still pursue source unification if that’s desirable (I can see that it might be) but in a way that decouples the NMMB and GSM concerns and allows other work to proceed in the meantime.  Once we do have unified physics, I suggest that we will need to evaluate and strengthen the process for testing and considering approval for changes to packages that are shared by more than one model in the NEMS trunk.
 
John
 
From: John Michalakes [mailto:john.michalakes at noaa.gov] 
Sent: Friday, August 1, 2014 9:50 AM
To: 'Mark Iredell - NOAA Federal'; 'shrinivas.moorthi at noaa.gov'; 'jun.wang at noaa.gov'; 'nicole.mckee at noaa.gov'; 'sajal.kar at noaa.gov'; 'xingren.wu at noaa.gov'; 'fanglin.yang at noaa.gov'; 'michael.a.young at noaa.gov'; 'john.derber at noaa.gov'; 'sarah.lu at noaa.gov'; 'eugene.mirvis at noaa.gov'; 'mayra.oyola at noaa.gov'; 'patrick.tripp at noaa.gov'; 'yusong.wang at noaa.gov'; 'raghu.reddy at noaa.gov'; 'weiyu.yang at noaa.gov'; 'henry.juang at noaa.gov'; 'hui-ya.chuang at noaa.gov'; 'kate.howard at noaa.gov'
Subject: RE: global NEMS meeting Friday
 
Hi all,
 
Sorry, I had to break off about half-way through the call to drive my daughter this morning.  I’d like to comment on item 12 in the Google doc:
 
12. Physics in its own library
 
This is predicated on there being a single unified version of a physics package that is callable by any model in NEMS.  As far as RRTMG is concerned, we do not have that. I’m not referring to having multiple versions of the same package over time (a revision history); rather, I’m referring to the fact that currently, GFS and NEMS are not calling the same version of RRTM, even though a couple of the source files (radsw_main and radlw_main) are in common.
 
Speaking from personal experience over the last few months working to modify RRTM3 used by GFS and NMMB, I’ve come to the realization that what we have now is the worst possible situation: having to develop, maintain, and validate two significantly different packages masquerading as a single package.  
 
The situation is worse than if we simply maintained two entirely different versions of the RRTMG physics, one for GFS and one for NMMB. The changes I’ve been making affect radsw_main and radlw_main but because the changes affect the way the routines in these are called (for threading and vectorization) the changes are not limited to just those shared routines.  I also had to modify the separate respective models’ separate versions of gloopr and grrad (GFS) and module_RADIATION and grrad_nmmb (NMMB) as well as model-specific versions of some of the cloud and aerosol-related (NMMB).  All changes have to verify and validate against all models that call the package.
 
If each model had an entirely separate version of the radiation, I could work in the context of one model and not worry about what effects these might have on the other model.  Of course, that also means that we’d be back in the situation of maintaining multiple versions of the physics package and keeping them in sync with each other.   But that’s also the situation now, given that to a significant extent we’re still maintaining and validating different versions; and with the additional complexity that both versions are kept in the same container (e.g. library, if we go that direction) with effects that are inextricable from either model.   
 
Summarizing, I’m okay with keeping one version and revision history of physics used by multiple models in the same library if it really is one version, but not if what we’re really doing is taking two models’ versions of a physics packages and stuffing them into a single library/package, which is what we have now with RRTMG.
 
John 
 
 
 
From: Mark Iredell - NOAA Federal [ <mailto:mark.iredell at noaa.gov> mailto:mark.iredell at noaa.gov] 
Sent: Friday, August 1, 2014 7:54 AM
To:  <mailto:shrinivas.moorthi at noaa.gov> shrinivas.moorthi at noaa.gov;  <mailto:jun.wang at noaa.gov> jun.wang at noaa.gov;  <mailto:nicole.mckee at noaa.gov> nicole.mckee at noaa.gov;  <mailto:sajal.kar at noaa.gov> sajal.kar at noaa.gov;  <mailto:xingren.wu at noaa.gov> xingren.wu at noaa.gov;  <mailto:fanglin.yang at noaa.gov> fanglin.yang at noaa.gov;  <mailto:michael.a.young at noaa.gov> michael.a.young at noaa.gov;  <mailto:john.derber at noaa.gov> john.derber at noaa.gov;  <mailto:sarah.lu at noaa.gov> sarah.lu at noaa.gov;  <mailto:eugene.mirvis at noaa.gov> eugene.mirvis at noaa.gov;  <mailto:mayra.oyola at noaa.gov> mayra.oyola at noaa.gov;  <mailto:patrick.tripp at noaa.gov> patrick.tripp at noaa.gov;  <mailto:yusong.wang at noaa.gov> yusong.wang at noaa.gov;  <mailto:raghu.reddy at noaa.gov> raghu.reddy at noaa.gov;  <mailto:weiyu.yang at noaa.gov> weiyu.yang at noaa.gov;  <mailto:henry.juang at noaa.gov> henry.juang at noaa.gov;  <mailto:hui-ya.chuang at noaa.gov> hui-ya.chuang at noaa.gov;  <mailto:john.michalakes at noaa.gov> john.michalakes at noaa.gov;  <mailto:kate.howard at noaa.gov> kate.howard at noaa.gov;  <mailto:mark.iredell at noaa.gov> mark.iredell at noaa.gov
Subject: Re: global NEMS meeting Friday
 
google docs link that we'll review at 10 am meeting
https://docs.google.com/a/noaa.gov/document/d/1IScpBvPiyUYNCWemnRl1Xlz6ViSYyICN4_h6T76njEk/edit?usp=sharing
 
On Thu, Jul 31, 2014 at 10:52 PM, mark.iredell at noaa.gov <mailto:mark.iredell at noaa.gov>  <mark.iredell at noaa.gov <mailto:mark.iredell at noaa.gov> > wrote:
I would like to discuss requirements for the NEMS/GSM svn repositories, how to keep them as separate projects so they can both thrive but work together as well


global NEMS

telecon:  <tel:1-866-685-5896> 1-866-685-5896 8108134#

When
Fri Aug 1, 2014 10am – 11am Eastern Time

Where
NCWCP - EMC Large Conf Rm - 2890, NWS - EMC/WWB - Teleconference Line ( <http://maps.google.com/maps?q=NCWCP+-+EMC+Large+Conf+Rm+-+2890,+NWS+-+EMC/WWB+-+Teleconference+Line&hl=en> map)

Who

•
Mark Iredell - organizer

•
Raghu Reddy

•
Patrick Tripp

•
Michael A. Young

•
Nicole McKee

•
Eugene Mirvis

•
Weiyu Yang

•
Sarah Lu

•
Jun Wang

•
Hui-Ya Chuang

•
Shrinivas Moorthi

•
Henry Juang

•
Sajal Kar

•
Fanglin Yang

•
Kate Howard

•
John Derber

•
Xingren Wu

•
Yusong Wang

•
Mayra Oyola - NOAA Affiliate

•
John Michalakes - NOAA Affiliate
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lstsrv.ncep.noaa.gov/pipermail/ncep.list.nems.announce/attachments/20140805/21966645/attachment-0001.html 


More information about the Ncep.list.nems.announce mailing list