fix mechred exp underflows

[apcraig]

fix mechred exp underflows, add back bgc tests to travis
Developer(s): tcraig
Are the code changes bit for bit, different at roundoff level, or more substantial? bfb except ridging results might change
Is the documentation being updated with this PR? (Y/N) N
If not, does the documentation need to be updated separately? (Y/N) N
Other Relevant Details:

[apcraig]

Testing on travis now with bgc tests on, will remove if they still fail.
Also will add a fix to the excess write statements when we have a plan.
Do not merge yet.
This may changes answers in the ridging due to truncating the underflow. Do we need to validate that and if so, what should we do. CICE qc with ridging on? I will do some bfb testing first.

[ghost]

If the bgc tests fail in this PR I will look into how we can mark them as "allowed_failures". That means they are invoked with every build but never cause it to fail.

Edit: Well, that was easy.

[eclare108213]

This looks fine to me.

[apcraig]

Excellent, bgc tests pass now on travis. Have confirmed manually in the travis log.

Also, just ran "thermo1" tests on gordon vs 16f0046 (defaultsets branch) and answers have changed. It looks like it's just the icefree slab cases and changes look small, initial diff, for example in icefree case is,

< area fraction          =        0.83944043855759709
< avg ice thickness (m)  =        1.26020543781683725
---
> area fraction          =        0.83944043855759609
> avg ice thickness (m)  =        1.26020543758602588
7428c7428
< avg salinity (ppt)     =        2.30068935292551302
---
> avg salinity (ppt)     =        2.30068935292551346
7430,7438c7430,7438
< surface temperature(C) =       -0.02419380517621833
< absorbed shortwave flx =      129.10442777946335013
< outward longwave flx   =     -264.40709354451905710
< sensible heat flx      =       -1.02810177807716996
< latent heat flx        =       -4.69936413990385393
< subl/cond (m ice)      =       -0.00000672453676223
< top melt (m)           =        0.00110261317055972
< bottom melt (m)        =        0.00026661505114313
< lateral melt (m)       =        0.00015367692113498
---
> surface temperature(C) =       -0.02419380517621784
> absorbed shortwave flx =      129.10442777917401713
> outward longwave flx   =     -264.40709354451888657
> sensible heat flx      =       -1.02810177807715863
> latent heat flx        =       -4.69936413990384771
> subl/cond (m ice)      =       -0.00000672453679044
> top melt (m)           =        0.00110261323486836
> bottom melt (m)        =        0.00026661505112987
> lateral melt (m)       =        0.00015367692110758
7443,7445c7443,7445
< effective dhi (m)      =       -0.00152888871423773
< effective dhs (m)      =       -0.00000065207277346
< intnl enrgy chng(W/m^2)=     -116.57397003594371654
---
> effective dhi (m)      =       -0.00152888877853430
> effective dhs (m)      =       -0.00000065207277347
> intnl enrgy chng(W/m^2)=     -116.57405133028825617
7447c7447
< sst (C)                =       -0.42859882036203806
---
> sst (C)                =       -0.42859882035439795
7450c7450
< heat used (W/m^2)      =       25.67732175630212410
---
> heat used (W/m^2)      =       25.67732169732118308

[eclare108213]

It makes sense that this would show up in the icefree initial condition, since the ice is thin there (and so will be more susceptible to ridging). I'll do a quick gx3 run to make sure nothing unexpected happens, but this looks good to me.

[dabail10]

Looks good. A more general question is about underflows in CICE in the dynamics. Can we not add compiler options to flush underflows?

[apcraig]

We generally do flush to zero in non-debug mode. This is only with debugging turned on. Also, the compiler option to underflow to zero can sometimes be expensive, although I'm not sure if that is still true. It's also important to understand where these are coming up and decide whether they are physically reasonable or not. So I'm happy to trap them and explicitly fix them.

On a separate note, the way we handle the underflows is not consistent throughout the code. We should revisit that. In particular, the exp_argmax value varies across the code.