Keep 2 versions of pio

[esmci]

Keep 2 versions of pio

[jedwards4b]

I'm a little uncomfortable with this. I'm afraid that it will lead to
gptl1 gptl2, drv1 drv2, csm_share1, csm_share2, csm_share3 ...

On Thu, Jan 7, 2016 at 2:25 PM, Robert Jacob [email protected]
wrote:

We're not done exploring the performance between pio1 and pio2. So we'd
like to create:
cime/externals/pio1 - ACME's current version of pio1.
cime/externals/pio2 - CIME4's latest version of pio2.

—
Reply to this email directly or view it on GitHub
#20.

Jim Edwards

CESM Software Engineer
National Center for Atmospheric Research
Boulder, CO

[rljacob]

I'm not as concerned since pio1 and pio2 really are very different and that could be the "rule". Its more than a version number increase. And we promise its temporary.

[rljacob]

@jayeshkrishna can explain what he wants to do.

[jayeshkrishna]

I want to keep PIO1 around until we get a chance to thoroughly test PIO2 for all the cases that interests us (ACME). I suspect that after the cosmetic changes required in ACME to build with PIO2 we might stumble on some bugs in ACME that might need to be fixed.
Once PIO2 works for all the ACME cases, I will just use PIO2 (remove PIO1).

[jayeshkrishna]

And as Rob mentioned we really want to migrate as soon as possible to PIO2 (completely to PIO2).

[rljacob]

In that case why don't we do this instead: cime/externals/pio will be CIME4's latest and cime/externals/pio1 will only exist in ACME/cime (a subtree of ESMCI/cime). Then we just have to remember not to include it if we subtree split from ACME to ESMCI.

[ekluzek]

Hi Everyone

I'm just going to throw in here, that having both PIO1 and PIO2 in cime
would have been helpful for CLM development during the transition to PIO2.
The build in cime seamlessly figures out if you have PIO1 or PIO2 as it is
(which is nice) so having them both available for a transition time makes
sense to me.

Everyone sees the point of removing the two directories eventually. But I
think it makes a lot of sense for some period of transition. So I support
this idea of having it available for a transition, I wish we would have
done that ourselves.

Erik Kluzek, (CGD at NCAR)

National Center for Atmospheric Research

*Boulder CO, *

(off) [phone] (fax) [phone]

(skype) ekluzek (cell) [phone]

Pronouns: he/his/him

------------------ Home page ------------------------

•      http://www.cgd.ucar.edu/~erik <http://www.cgd.ucar.edu/~erik>*
  

•      https://staff.ucar.edu/users/erik
  

  https://staff.ucar.edu/users/erik*

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

On Thu, Jan 7, 2016 at 3:33 PM, jayeshkrishna [email protected]
wrote:

And as Rob mentioned we really want to migrate as soon as possible to PIO2
(completely to PIO2).

—
Reply to this email directly or view it on GitHub
#20 (comment).

[jayeshkrishna]

I am fine with having pio1 only in ACME/cime

[jayeshkrishna]

Should I go ahead and add code to support PIO1 and PIO2 into master (branch + integrate to master)?

[jgfouca]

The conflicts in share/csm_share/shr/shr_pio_mod.F90 need to be resolved.

[jedwards4b]

I'm concerned about how we are going to handle the divergence in namelist
control variables for pio.

On Thu, Jan 14, 2016 at 5:04 PM, James Foucar [email protected]
wrote:

The conflicts in share/csm_share/shr/shr_pio_mod.F90 need to be resolved.

—
Reply to this email directly or view it on GitHub
#20 (comment).

Jim Edwards

CESM Software Engineer
National Center for Atmospheric Research
Boulder, CO

[rljacob]

Aren't the namelist control variables in ACME's pio all new? Do they conflict with existing ones?

[jayeshkrishna]

The namelist control variables in ACME's pio are new. We might want to also discuss if it makes sense to provide these controls (expose controls via namelist vars) for PIO2 too.

[jedwards4b]

I think that exposing these is too confusing - I propose instead that the
system should measure and determine the correct settings at model
initialization time.

On Thu, Jan 14, 2016 at 7:25 PM, jayeshkrishna [email protected]
wrote:

The namelist control variables in ACME's pio are new. We might want to
also discuss if it makes sense to provide these controls (expose controls
via namelist vars) for PIO2 too.

—
Reply to this email directly or view it on GitHub
#20 (comment).

Jim Edwards

CESM Software Engineer
National Center for Atmospheric Research
Boulder, CO

[rljacob]

It was decided to keep 2 versions of PIO.