Changes to cosp error checking routine

[dustinswales]

I propose to merge some improvements onto the COSP2 master branch.

1) Expanded error checking routine. Background: Currently all inputs provided to COSP2 are passed to an error checking routine, where they undergo a basic sanity check before the simulators are called. If erroneous input values are encountered, the simulators which are dependent on those inputs are turned off, the requested diagnostics are set to fill values, and an error message is provided. In CESM2, where RTTOV is not used, I had to comment out the checking of the RTTOV inputs, as they are not provided. This is less than ideal, as this requires a special installation of COSP2 in CESM2. Solution: Expand the error checking routine to ensure that the correct inputs are provided for the requested diagnostics. This solution is general and extends to other COSP2 configurations.

2) Cleaned up initialization routine. Removed unused arguments from subroutine cosp_init.

[klein21]

Although this does seem OK to me, I defer to Alejandro to express an opinion on these changes.

I do have a question. Does the statement "Removed RTTOV fields from cosp_init" mean that users must edit to the code now to use RTTOV if they wish?

I guess I am a bit curious about the status of RTTOV within COSP. It's always been half in - half out. Do we want to keep it that way? Or would it be better to move to fully in, or fully out?

[dustinswales]

Steve,

I scoped out updating to a more recent version of RTTOV for COSP2 (currently up to RTTOV12.2), but it turns out that the more recent versions of RTTOV are not backwards compatible with older versions. In a nutshell, it was quite a bit of work to bring COSP2 up-to-date with new versions of RTTOV, so we didn't. COSP2 is distributed using a stub for RTTOV, so the infrastructure is in place for someone to pick this up, but would require some work on their part. I'd say RTTOV is more out than in... The arguments I removed from cosp_init were all for RTTOV9.3, which we decided awhile back to drop support for in COSP2.

Dustin

[klein21]

Dustin,

Thanks for explaining the current situation.

Steve

[RobertPincus]

Does anyone on the PMC know who the constituency for RTTOV is? Should we poll the user group? It sounds like the best course of action might be to nudge RTTOV all the way out the door…

• Robert

On Apr 23, 2018, at 10:08 AM, klein21 notifications@github.com wrote:

Dustin,

Thanks for explaining the current situation.

Steve

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[klein21]

If no one on the PMC makes a strong case for it, I would then favor asking the cosp-user group as the next step.

Maybe RTTOV need not be fully pushed out the door, but perhaps put in a closet that it is rarely opened (i.e. out of the way and not in need of any active attention).

From: Robert Pincus notifications@github.com Reply-To: "CFMIP/COSPv2.0" reply@reply.github.com Date: Tuesday, April 24, 2018 at 6:34 AM To: "CFMIP/COSPv2.0" COSPv2.0@noreply.github.com Cc: "Klein, Stephen A." klein21@llnl.gov, Comment comment@noreply.github.com Subject: Re: [CFMIP/COSPv2.0] Changes to cosp error checking routine (#10)

Does anyone on the PMC know who the constituency for RTTOV is? Should we poll the user group? It sounds like the best course of action might be to nudge RTTOV all the way out the door…

• Robert

On Apr 23, 2018, at 10:08 AM, klein21 notifications@github.com wrote:

Dustin,

Thanks for explaining the current situation.

Steve

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/CFMIP/COSPv2.0/pull/10#issuecomment-383932170, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AfO_cCNSbTHhG8nvtHn-5YIDCa11wn4bks5trynYgaJpZM4Tcl4N.

[dustinswales]

@alejandrobodas Do you have any objections to this update on the master branch?

[alejandrobodas]

Hi @dustinswales I have no objections to these changes. However, I think the driver should also be updated and check the error messages. At the moment, if one implements COSP as it is done in the driver, the model won't stop if an error occurs, and since the error messages are not printed out as warnings, the user won't know why the diagnostics contain missing data.

Regarding RTTOV, I think we are pretty much in the position that @klein21 favours (once this change is merged).

[klein21]

I wasn’t favouring any position yet, but I am guessing Alejandro that you favour putting RTTOV “in the closet”?

From: alejandrobodas notifications@github.com Reply-To: "CFMIP/COSPv2.0" reply@reply.github.com Date: Wednesday, April 25, 2018 at 5:55 AM To: "CFMIP/COSPv2.0" COSPv2.0@noreply.github.com Cc: "Klein, Stephen A." klein21@llnl.gov, Mention mention@noreply.github.com Subject: Re: [CFMIP/COSPv2.0] Changes to cosp error checking routine (#10)

Hi @dustinswaleshttps://github.com/dustinswales I have no objections to these changes. However, I think the driver should also be updated and check the error messages. At the moment, if one implements COSP as it is done in the driver, the model won't stop if an error occurs, and since the error messages are not printed out as warnings, the user won't know why the diagnostics contain missing data.

Regarding RTTOV, I think we are pretty much in the position that @klein21https://github.com/klein21 favours (once this change is merged).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/CFMIP/COSPv2.0/pull/10#issuecomment-384276305, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AfO_cNRBnFDiBi_2VoRU_aaf7wHBpZBtks5tsHI5gaJpZM4Tcl4N.

[alejandrobodas]

Yes, for the moment, I think it makes sense to put it in a closet. That is how it's always been in COSP1, and it hasn't created any problems.

[dustinswales]

@alejandrobodas I've added a few lines to the driver to print error messages when errors occur.